We’re in the process of defining ICRC-107, a new standard to formalize fee collection mechanisms on ICRC-compliant ledgers. This standard aims to provide a clear and consistent approach to fee collection while maintaining backward compatibility with current implementations, such as ckBTC.
The goals of ICRC-107 are:
To ensure fee collection information can be set and managed without requiring lengthy migrations for already deployed ledgers.
To provide flexibility for ledger controllers to specify whether fees are collected or burned for specific transaction types (e.g., transfers, approvals).
Key Features Under Consideration
The current draft proposal includes:
Backward Compatibility: Maintaining the behavior of existing ledgers while introducing new capabilities.
Flexibility: Allowing ledger controllers to set fee collection policies for both transfer and approve operations.
Unset Capability: Providing the ability to revert from fee collection to fee burning for specific transaction types.
Questions for the Community
To ensure the standard meets the needs of diverse stakeholders, we’re seeking your input on the following points:
Multiple Fee Collectors:
Should the standard allow for distinct fee collectors for different types of operations (e.g., one for transfer transactions and another for approve transactions)?
Would a single fee collector suffice for all transaction types?
Should we consider a scenario where the fee collector changes?
Reverting to Fee Burning:
Once fee collection is enabled for a transaction type, should it be possible to revert to fee burning by unsetting the fee collector?
Are there specific scenarios where this flexibility would be critical?
Additional Considerations:
Are there any other requirements or use cases that the standard should address to better serve the community?
How You Can Help
We encourage you to share your thoughts, concerns, and ideas regarding the above questions. Your feedback will help shape the ICRC-107 standard to be as robust and inclusive as possible.
i would fix it to just single fee collector and if a team of multiple people want to divide the collected fees, then they should just divide it behind the scene – like explore the transaction history of fee collector account/address, sum/replay the balance of fee collector account from block n to block n+m, then divide it among themselves until they’re all satisfied. again, just my opinion… perhaps there’s a scenario i didnt take into account yet…
and if “icrc107:fee_collector” is not set, the fees will be burned (to minter/canister).
Along with what @kayicp says, every time I try to look at multiple recipients things start to get complicated. It is worth the one extra fee to move the funds to an address that can automate distribution. It also lets the community build different and bespoke distribution schemes.
Should the standard allow for distinct fee collectors for different types of operations (e.g., one for transfer transactions and another for approve transactions)?
A. Yes, this allows variations that we currently see in WEB2 industries. For example: Peer to Peer (Zelle) fees are different than (Bank) wire transactions. Options are better for decentralized entities.
Would a single fee collector suffice for all transaction types?
B. No, this limits the ability for different industries coming aboard.
Should we consider a scenario where the fee collector changes?
C. Absolutely, adaptation is the key to a prolonged approach.
Reverting to Fee Burning:
Once fee collection is enabled for a transaction type, should it be possible to revert to fee burning by unsetting the fee collector?
A. Yes, this allows for burning or fee collection. I see this being great option when developing an AI model for different business scenarios.
Are there specific scenarios where this flexibility would be critical?
B. Yes, to keep the cycles burning creating a deflationary model for the protocol wen experiencing a bear market or low activity.
Additional Considerations:
Are there any other requirements or use cases that the standard should address to better serve the community?
Good to see progress on this is being made now. I was thinking of other scenarios and want to test the waters with an idea.
If you have a fee collector account set on a ledger and someone tries to burn their tokens it would be nice if we could send the burnt amount to the fee collection account. I understand that not everyone would want this feature though so making it a optional configuration would be good. Also, you might want it so that only the minting account has the power to burn tokens whilst burns from all other accounts go to the fee collection account. I think this is probably out of scope.
I’m not sure I follow the specific use case you have in mind in 1.A,B. My question is specifically about ICRC ledgers where there are two types of transactions, transfer and approve, which require paying fees. Does it make sense to collect fees for transfers by one fee collector and fees for approvals by another. What would be the use case? NB: one can set different fee collectors (and fee amounts) in different instances of ICRC ledgers and I think that may satisfy the scenario you have in mind. Can you confirm or clarify what is my misunderstanding? Also, we are not trying to be fully general of designing fee collection for arbitrary ledgers but rather for the specific case of ICRC ledgers.
For 2.A,B the fee collector can always decide to burn the accumulated tokens. That should satisfy the use case you have in mind at B, right?
Yes, that would be a nice separation of concerns but it may be too late. The problem is that ICRC-1 already formalizes that sending tokens to the minting account would result in burning the said tokens and deviating from this behaviour would deviate from the ICRC-1 standard.
Ok, thank you for the clarification. In that case, your suggestion of allowing fee collectors and amounts to apply in different instance would be in alignment with decentralized optionality. Although I cant think of an instance, I believe having variation to build is more attractive.
Correct, the fee collector having option to burn is a degree more satisfying.
Imo having options is always best. btw, thanks for replying as I am trying to educate myself by indulging in conversations with more experienced technical peeps.
I do not think this is needed. we should keep it as simple as possible. agree with @kayicp and @skilesare that this can be done behind the scenes.
I think that would be good to have.
+1, personally I would even debate if a fee is really needed (but I learned it can be set to zero). however, if a fee is “needed”, as a user of such token I would ask to remove (at least) the fees for the approve operation.
I don’t think that a different mechanism (collection vs. burn) is needed for this though. I would expect this decision to be applied for all fees.
however, I would like to be able to define different amount of fees for specific tx types. it is interesting to know that the fee behavior (collection vs. burn) is currently implemented differently for transfers and approvals according to this slide.
Does this also apply for ckBTC (and other ck-tokens) right now? Does that mean that approve fee is currently burned there?! Don’t we need to “recover” this fee then somehow to match the BTC amount secured in through the minter canister? (cc @THLO)
I have no strong opinion on this, but in case the community behind the token votes for that for whatever reason, that would make sense.
maybe we should consider an implicit removal of the fee collector if the fee amount is set to 0 / None for each tx type?
or the other way round, if a fee collector is removed → change the fee to 0 / None for all tx types (I would not expect a switch to the burn mechanism in this case)
@bogwar just told me that this is indeed the case.
Note that it is relatively easy to “recover” the fees: The ckBTC minter can mint the difference between the amount of bitcoin that it holds and the total supply of ckBTC (taking on-going operations into account) into its fee collector account.
