and return the #TemporarilyUnavailable error when caller is calling the ledger too much in a short time?
also what is that error for, actually?
I’m not a fan of ledgers without any fees because any rate limiting you put in is most likely trivially circumventable by sybil attacks.
The TemporarilyUnavailable error can be used for anything you feel it’s appropriate for. If you need to do some maintenance I think it would be appropriate, or when you disable functionality for some reason. One example we have in the cycles ledger is that we plan to return TemporarilyUnavailable if we start to run low on available memory in order to not hit the limit because that would make the ledger fail in unexpected ways
1 Like
I see, I was trying to stay true to the Reverse Gas Model idea. I guess no-fee ledger is a fool’s errand to achieve that. Alright, I will implement a fee.
We have an example here: ICRC_fungible/src/examples/Allowlist.mo at 9a19d6ddfa23afe8fcb99f40435526186e3c4ec4 · PanIndustrial-Org/ICRC_fungible · GitHub
In this example we have an allow list token…it assumes that you know who is using your ledger, so if someone spams, you could remove them. You could modify this example to use other system, like checking if a user has a certain number of staked tokens and thus gets a 0 feel.
There has also been a discussion of a “merchant pays” ICRC that would take the fee from the receiver. Something like this that also integrates @timo 's idea of having to have both parties accepting a transaction is being considered for future ICRC types that are more retail and business friendly.