It succeeded and the parameter has been successfully updated.
Why do you think it didn’t work?
My understanding is that the change first passes to the ledger which updates the fee, and the governance canister then observes the successful change and updates the recorded service nervous system parameters. I’ve just checked those parameters direclty via the governance canister and it features the value you proposed in your proposal.
If you’re using a frontend to observe this and it still shows the old value it’s no doubt a caching issue on that frontend. E.g. if you’re seeing the old fee in a DEX you may want to contact the DEX dev team
Hi @Lorimer ! Thanks for responding! Where did you see that it changed? Regardless of where you’re looking, it wasn’t applied. I’ve run several tests and it burned 0.001 GOLDAO instead of 10 GOLDAO per transaction.
I queried the governance caniser for the network nervous system parameters, which shows the value you declared in your proposal.
I think @Phasma is probably right, that rings a bell. Although it’s a confusing flow. It should work the way you did it. The ledger should ideally update based on changes to the SNS params rather than the other way around.
@bjoernek, this is the sort of nuance that needs to be added to documentation and/or IC skills (if it’s intended to work this way)
Thank you very much for your responses! @Phasma@Lorimer To create the proposal, I used https://ic-toolkit.app/, and I specifically made the proposal for the transaction_fee_e8s field.
It seems there is no way to create a proposal to “update the ledger” directly. I was under the impression that executing that proposal would update the ledger.
What is the correct way to update the ledger through an SNS proposal? Thx!!
You can update the SNS ledger transfer fee using the ManageLedgerParameters proposal type. This lets you change the transfer_fee (in e8s) without affecting other ledger parameters (set unused fields to null).
Here’s the command using quill:
quill sns \
make-proposal $PROPOSAL_NEURON_ID \
--proposal '(
record {
title = "Reduce transfer fee to 314_159 e8s";
url = "https://forum.dfinity.org/t/fee-reduction/77777";
summary = "Reduces the transfer fee to 314_159 e8s (~0.00314159 tokens) to lower transaction costs.";
action = opt variant {
ManageLedgerParameters = record {
token_symbol = null;
transfer_fee = opt 314_159;
token_logo = null;
token_name = null;
}
};
}
)' \
--canister-ids-file ./sns_canister_ids.json > message.json
quill send message.json
Key points
transfer_fee is specified in e8s (1 token = 100,000,000 e8s).
Set any fields you don’t want to change to null (e.g., token_symbol, token_logo, token_name).
The proposal must be submitted by an eligible neuron and approved by token holder vote before the change takes effect.
After the fee is updated, always pass the fee explicitly in transfer calls — if the fee doesn’t match the ledger’s current fee, the call returns a BadFee error.
Thanks! That’s exactly what I did: I only modified that parameter, and the rest that shouldn’t be changed is set to null. I’m going to do a little more research now to see if there’s anything else that needs to be changed besides that parameter.
If there’s something else that needs to be done, the functionality of modifying transaction_fee_e8s isn’t very clear; if it doesn’t have any impact, it’s strange.
I cannot disburse an unlocked golddao neuron. This is the complete description of the “circumstance,” so do whatever you want with that info, or don’t. This SNS has turned to trash just like all the others, so I can’t say that I care much!
If the param was changed in the sns and not on the ledger then that may be what has broken the neuron behavior, if it is sending the wrong fee to the ledger it may trap. I think you may have to set up a custom sns function to call the admin fee change on the ledger as the governance canister is the controller of the ledger and the only principal that can change it.
Thanks for the reply! Proposals with DAO parameters should be precisely for that… that automatically, upon voting for a change to any DAO parameter, the ledger updates if necessary. It’s strange that an extra function would have to be created… What is the point of changing parameters in the DAO then, if it doesn’t have a real-world application?
Thanks again for the information! I will speak with the team to see how complex it is to make the change.
I looked into this and can confirm the analysis above: changing
transaction_fee_e8s via ManageNervousSystemParameters only updates the Governance
canister’s stored parameters. It does not update the SNS ledger’s actual transfer
fee.
The intended path is to submit a native ManageLedgerParameters proposal with
transfer_fee set to the desired value. When that proposal executes successfully, it
updates the ledger fee and also syncs Governance’s transaction_fee_e8s to the same
value.
So the recommendation is: use ManageLedgerParameters.transfer_fee for changing the
SNS token transfer fee.
The current behavior/documentation is clearly confusing, so I will update the
docs to make this distinction explicit.
Perfect! I will carry out that process. Is it necessary to do anything about the transaction_fee_e8s parameter that was modified in the DAO, or do I just submit another proposal to change the ManageLedgerParameters value? Thanks for the reply!
Thanks @bjoernek. I suggest also validating the payload and failing the proposal if an attempt is made to alter the fee via the wrong route. The shape of the payload should really be changed.
It is far better to fail loudly rather than silently, or even worse - succeeding but only doing half the update and leaving the SNS in an invalid state.