I would like to deploy an icrc2 token with fixed total supply.
I noticed the current default icrc2 tokens deducts all the transaction fees from the total supply.
One way to stop this is to make the transaction fees zero, but would that be a good practice? What are the problem associated with this?
Another way would be to deploy my own modified version of the token.
What’s the best way to achieve this? If there are some implementation already of icrc2 with fixed supply total logic may I have the links to the implementations please!
The Pan Industrial token suite GitHub - PanIndustrial-Org/ICRC_fungible: A full implementation of an ICRC 1,2,3 compatible fungible token has a number of overrides and hooks you could use to either set the fee to 0 or add it back into total supply if you really want to do that. Why do you not want it removed from supply? Is it going to a fee collector. My understanding is that there is some remaining work to fix something with fee colletors.
Thank you, the reason is just that I wan the total supply to be fixed and not decrease overtime, And yes for this particular case if the fee can go to a fee collector that would be great.
So I just noticed that the icrc2 implementation already supports what I am looking for , it wasn’t so obvious but after really looking at the InitArgs I saw there is fee_collector_account, which is just what I wanted because the fee is basically returned to the supply but I thought it didn’t have this, most documentation ignore this field, I just needed to really look at the actual type.
Just one note of caution: the ICRC ledger does have a fee collector but unfortunately the expected behaviour is not fully implemented: the fee for transfers is collected but the fee for approvals is still burned.
This is something that we want to fix early next year via a standard for fee collection.
, it wasn’t so obvious but after really looking at the InitArgs I saw there is fee_collector_account, which is just what I wanted because the fee is basically returned to the supply but I thought it didn’t have this, most documentation ignore this field, I just needed to really look at the actual type.