-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[migration] Resolve possible inconsistencies when scaling large native token supplies #440
Comments
To resolve this, we could add checks in the executor.rs if native token amount is 0. Then don't create the Coin object. |
Maybe the beste approach would be to print package ids here of the foundries that had the total supply changed. Then check them manually in the explorer. |
IOTA:
SHIMMER:
MAX SUP AFTER: 18446744073709551614 for all cases
For clarifying:
|
The verification implemented in #2126 shows that in the 12th of Dec 2024 there were no native tokens affected by the issue indicated here (this comment explains why). TODO:
|
Description
This follows #359 and the adopted scaling approach of large (>
u64::MAX
) native token supply configurations.The scaling would be trivial if it weren't for the fact that we deal with integers. And one issue remains with both the direct scaling of all values, and this scaling by equation between circulating and maximum supply:
Any
token_amount < 1 / ratio
held by basic outputs will reduce to zero. This will lead to an effective0 <= actual_circulating_amount <= circulating_amount
. Can we consider such a ledger state consistent?See original discussion thread here.
The text was updated successfully, but these errors were encountered: