The ICPSwap team has pointed out that the ICRC-1 Ledger package limits the max supply of new tokens to 184467440737.00000000. Can someone provide an explanation for this particular number? Is this likely to be changed/updated in the future?

The number you mentioned, 184467440737, doesnâ€™t seem to have any particular significance on its own. However, if we add a few more digits at the end to make it 18446744073709551615, it becomes a special number because it is the maximum value that can be represented by an unsigned 64-bit binary number. This value is equal to 2^64 - 1.

The significance of this value comes up often in computer science and programming because 64-bit computing is the norm in modern computer architectures. This number represents the maximum amount of unique addresses available in a 64-bit system, or the maximum value that can be stored in an unsigned 64-bit integer.

In binary form, this value is represented as 64 consecutive 1â€™s (11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 in binary), and itâ€™s often used in programming to represent a â€śmaxâ€ť value or a placeholder for a value thatâ€™s supposed to be impossibly high.

Thank you a lot for taking the time to answer.

This number represents the maximum amount of unique addresses available in a 64-bit system

So you believe this limit will not be updated in the future due to the limitation of 64-bit systems?

Not if you want 8 decimal places.

Why isnt 184 billion tokens with 8dp enough?

Not sure why they said that.

Icrc1 works with Nat, not Nat64. From spec:

Nat = Natural numbers with infinite precision.

Maybe their LPs are using Nat64 or the example implementation uses Nat64

Itâ€™s simply a tradeoff between storage space required and reasonable defaults. Thereâ€™s nothing stopping anyone from using infinite-precision ints, but itâ€™ll make memory management more complex (read: more can go wrong) and it takes more space (read: youâ€™ll run into problems much earlier)

This is not a limitation of ICRC-1, but rather a limitation of the specific implementation. You can modify the implementation to use u128 or u256.

Would you be willing to help us out on launching a token under the ICRC-1 Ledger package but modifying the implementation to use NAT, or something like u256?