Hello everyone!
I’ve been tinkering with one idea for a while, but for it to work it is best if the token for the project would have percentage fees instead of flat fees, like its currently done.
Does anybody knows a way for enabling this feature for ICRC-1 tokens? Without breaking the standard.
ICRC-2
ICPEx has option to make token with % fee. Use plug wallet to make token, im not sure how long platform will stay open.
Hmm…
First of all, thank you for your answer, but it only increased the number of questions I have 
I can see, that ICPex have this feature and they say it is the ICRC-2 standard feature.
But ICRC-2 standard has nothing to do with additional fee options - it is about allowances.
I checked the standard spec once again and couldn’t find any information about “icrc1:transfer_fee_rate”
Could you guys please explain, how did you implement that? And what is the status of that feature in terms of ecosystem support? Does ICPSwap support it?
I have not tested it myself, but go make 1 token, i think its like 0.1 ICP (says 0.9, but takes low, might be bug) to make it and 1 ICP to make pool on ICPSwap.
Oh, I see. There is a repo for their standard. It is called ICRC Plus - GitHub - ICPExchange/icrc_plus_ledger: The ICRC-2+ protocol is an enhanced version of the ICRC-2 protocol developed by the ICPEx team. It aims to make the ICRC-2 protocol more competitive with the token standards of other public chains. Users can import ICRC-2+ protocol tokens just like ICRC-2/ICRC-1 protocol tokens without any additional operations. · GitHub
The repo says that The ICRC-2+ protocol is compatible with both the ICRC-2 and ICRC-1 protocols., but that can’t be true.
Most dapps don’t know about that special fee handing for those tokens. They just assume the fee is flat. So, for example, when they move tokens around their own accounts, they just subtract the flat fee from the amount they send and then might just store the result in their memory for future use. If the actual fee was different it means that the actual amount of tokens and their stored amount might not match.
You are able do whatever you want in your code. This is one of the best things in IC. Your canister, your ledger, your rules.
But…
This definitelly could be standarized in some ICRC-XYZ extension.
The latest IC devs ICRC, one tokens, support custom fees. I believe that both percentage based and a custom function are supported. I think the whitelist example shows where you can manually set a fee down to zero if the user is a member of a whitelist. not on my computer or I would post a board descriptive link.
The one issue you’ll have is that there’s no way to tell someone with the fee is, But if they just always said it to Noel and trust the canister, then it should charge the right amount if you code it that way.
Yeah,
icrcX_fee: (amount: nat) → (nat) query
could be cool as a new extension, otherwise wallets or other applications may be accused of fraud.
Hmmm, so you made it in such a way so there is a default fee, which corresponds to ICRC-1 fee, but if it is not provided, the canister could actually charge percentage fee. Which makes it compatible with existing dapps, if they set the expected fee as the standard says.
Cool! Thank you!
I’d actually trap if they provide an expected fee and it is less than required. If it is more you can consider it an authorized fee…if null then let the canister decide.
But you certainly want it in the icrc3 block…which could get sticky because the fee is in tx if user provided and outer block if the canister adds it. We may have to ask @bogwar what happens to Rosetta and index-ng if there is an inner fee and an outer fee and they don’t match. 
ICRC-3 wise you might be better off manually adding a seperate burn tx for the variable fee(you can still do this by just calling the icrc1().burn(details)…each trx wil get two blocks