It seems that the standard integer type for a Coin object’s balance value is u64, i.e. from 0 to around 1.84e+19 (code reference in sui::coin module and code reference in sui::balance module).
However, this includes precision/decimals. Given that the standard precision/decision of a ERC20 token is 18, it leaves very little room. That is, balance can potentially only vary from 0 to around 184, which clearly can not serve any coin well. Even if we reduce decimal to 9, the maximal balance, without overflow, is only about 18.4 billion. For reference, today’s USDT total supply is about 79.02 billion.
Is there any rationale behind the choice of u64 in sui::coin and sui::balance? Or maybe it simply would be better if the Sui team can raise the standard integer type from u64 to u256 like in Solidity?
6 Likes
That seems a kind of question whether this needs to be followed. ERC20 is not directly applicable to coins in SUI, as I understand. So it is a matter of weighing - whether there exist real practical necessity to have currency which stretches, say, 18 digits in both directions from decimal point. While definitely it will be convenient to have larger type, or even unlimited “big-decimal”, I suspect it is trade-off to keep computational resources as low as is reasonable (which seems to be important goal of SUI).
And since the balance in SUI can exist in form of multiple separate coin objects, it is not necessarily blocking issue. Though dealing with coin fragmentation seems yet curious and somewhat clumsy to me.
Disclaimer: I’m not related to SUI development team, just sharing personal opinion!
3 Likes