This change creates a new sns governance proposal action: ManageLedgerParameters.
This proposal action lets an sns set the ledger parameters: transfer_fee, and fee_collector. Whereas before this change there was no way for an sns to update these parameters.
If the reviews and testing goes good, I plan on making a proposal on the nns to upgrade the sns governance, and root canisters with the code for this feature.
Technical specifics:
The proposal action ManageLedgerParameters tells the root canister to upgrade the ledger to it’s same current wasm module with an upgrade arg that contains the new values for the parameters that are being set. The ledger in the post_upgrade hook, updates its own values with those parameters that are set in the post_upgrade hook.
Edit: This update to this proposal removes some ledger parameters that were in the original draft proposal.
@levi Thanks for implementing this. This is a really clever solution to the problem of how to change parameters in the ledger, even though ledger doesn’t expose an API directly.
We (DFINITY engineers) are discussing this, but I wanted to give a quick thought.
The risk in making these changes is not so much internal to the ledger or SNS as it is the ecosystems outside of the SNS. Token symbols, decimals, and names are often widely distributed. What happens everywhere else in the ecosystem when those values are changed? There are liquidity pools, exchanges, and a variety of other dependencies on those values. And what exactly does it mean to change the decimals after a ledger has started collecting transactions? This is uncharted territory at this point.
So there are some relatively big risks there, and not just to the SNS that makes those changes, but to the broader IC and even crypto ecosystems.
What are the use cases that you’re targeting with this change? I’m wondering if we can find a way to accomplish those things that requires less risk analysis.
The icrc1_decimals value, sets the visual-format of the amount of token-quantums (smallest possible piece of a token) of the transaction/balance. This specific value is used by a frontend when showing a token-balance to a user. Changing this value does not change any token-balances or transaction-amounts in the ledger in the past or future. Changing this value does change the visual-format of how frontends show the token-quantums of the balance/transaction.
My view is that a sns that uses the ManageLedgerParameters proposal type, takes on the consequences of the change.
For example,current SNS1 Total Supply is 9997
If i own 9997 SNS1, the frontend shows that i own 9997000 SNS1, the real SNS1 Total Supply is still 9997?
Is my understanding correct？
@File The icrc1-ledgers keep track of token amounts using the number of smallest-pieces. So lets say there is an icrc1-ledger for U.S.-dollars, the ledger keeps track of token amounts using pennies/cents, and icrc1_decimals = 2. So lets say an account has 5000 pennies, the ledger says that there is 5000 pennies but the frontend shows 50 dollars, because icrc1_decimals = 2.
If the icrc1_decimals changes to = 1, that same account still has 5000 pennies, but the frontend now shows 500 dollars.
Current SNS-1 total supply is 999671422000 token-quantums. Canister: Dragginz Ledger - ICP Dashboard click icrc1_total_supply and click call. Current SNS-1 icrc1_decimals = 8, so the frontend shows 9996.71422000 (rounded to 9997) total supply.
If the SNS-1 icrc1_decimals changes to = 3, then the total supply will still be 999671422000 token-quantums, but the frontend will show 999671422.000 (rounded to 999671422) total supply.
Thank you very much for your patient and detailed explanation!
If your code does not change token-quantums(Real SNS1 Total Supply), so I think parameter icrc1_decimals is feasible for SNS1’s one of problems(As @Thyassa said,you will not be dealing with tiny fractions.) After all,Many facts indicate that after chage the Real Total Supply, will have a negative impact on coin price, project, community, and more.
As for the other parameters in your code, as @msumme said,
Other stakeholder and other parties in the ecosystem(SNSes, DEX, DEFI,and more) may need to prepare accordingly , after reviewing, discussing,testing and more. Looking forward to adopting Risk-Minimizing Risk-Controllable Feasibility changes(For example, if the code contains fewer parameters and only changes icrc1_decimals and other necessary code, voted through, and then gradually adding with other parameters and more code after small-scale use) while solving problems without compromising innovation, inspiration, your creativity!
So being able to rally consensus, seek common ground, and get your code and prorosal through the vote
100%. For changing the token_decimals parameter, every frontend out there that accepts a user’s input for an amount of the sns-tokens will need to prepare and then switch to the new decimals parameter at the same time. Being negligent with the token_decimals setting can lead to chaos.
@File That sounds like a great plan and path forward. Thank you sir.
Thank you @msumme and @File for your feedback on this proposal. Taking both your feedbacks into account, I am now updating this proposal to only contain the settings transfer_fee and set_fee_collector, We will leave the other parameters for a different day.
We should treat this proposal positively, this kind of code contribution from the community is very important(and in the future when facing with increasingly complex situations,collaborations and more, it will become more and more important), we need to learn, try to reduce the dependence on DFINITY( This is what DFINITY should expect to some extent)，so I expect that this proposal will be one of the good start or demonstration of the community contributing code and more which is not only good for decentralization, but also good for long-term sustainable application, development, innovation, and more!
There may be some difficulties in adopting this proposal, and I hope to pass the proposal after a series of collaborations, preparations, improvements, and more!
Thanks @levi. To me, that sounds like a better plan for the time being, and I will do my best to get the right people looking at this to give more feedback on that.
Great job! Thanks a lot! Is there a deadline for proposal submissions? We are currently in the process of upgrading the Info feature to accommodate the new parameters for the SNS tokens or other tokens that require modifications, such as decimals, symbols, and more.
Hey @levi, since you are talking about a proposal that must be submitted to the NNS instead of just a specific SNS, can you change the category of this post from General to Governance? This is an important governance topic and I think it’s great that you are leading the effort. Hopefully it won’t be missed by people who are actively engaged in governance participation. Posting in the Governance category helps ensure it is in front of those people.
Hi @ICPSwap, Glad you are here. We are taking one step at a time and making sure we move with caution and care. This proposal now creates the ability for an sns to only change one ledger parameter (relevant for this conversation): transfer_fee.
Lets focus now on making sure that a change in a sns’s ledger-transfer-fee works smooth with every platform.
The ICRC-1 specification specifies a mechanism for ‘fee-negotiation’ when performing a ledger transfer. A client can call the icrc1_fee method to get a starting point for the current fee. When making a transfer the client must set the fee field in the transfer-args. If the fee set in the transfer-args is not a valid current fee for the ledger, the ledger returns an error BadFee with the expected_fee. Then if the client is ok with the new fee, the client can make a new transfer with the fee field value as the expected_fee.
@ICPSwap What does the timeline look like for your system’s compatibility with a change of a sns’s ledger-transfer-fee?
Hello, Levi! We appreciate your valuable input and dedication to ensuring a seamless user experience. Your insight is truly valuable to us. Rest assured, we are actively working on and will do an upgrade for the Info feature recently to address the compatibility concerns you’ve raised. Thank you so much!
