We are currently having discussions in the ICRC Ledger and Tokenization Technical Working Group about ICRC-2 approval expiration and came to the conclusion that we need the opinion of the community to move forward as you are the ones who will build use cases on top of the token ledgers on the IC.
To summarize, the discussion is about the support of expirations for ICRC-2 approvals. ICRC-2 introduces the approve / transfer_from idea of ERC-20 to the IC’s token standard. We had intensive technical discussions on this topic and we came to the conclusion that we need to ask the community, among other things, about the following:
Do you want to have expirations for approvals or do you prefer the simplified semantics of approvals without expirations (as on ERC-20)?
If (1) is answered with a “yes,” how would you like to see expiration semantics implemented?
See @roman’s GitHub comment for the details on which community input is requested.
If you have an opinion on this, eg., based on use cases you have in mind, please provide your comment here on the forum or on GitHub! Many thanks
Having expiration dates has the additional complexity as the only downside, functionality wise it is strictly better. Regarding the different semantics of expiration dates, see the discussion in the above-linked GitHub discussion on the minutes of the Ledger WG discussions.
A TLDR is exactly in @roman-kashitsyn’s GitHub comment referred to above. We are still looking for community opinions on whether expiration is needed and, if so, how to implement it.
Instead of using approvals, we are using authorizations with our Volt smart contract wallet. Authorizations give us much more flexibility than the approve/transferFrom model from ETH.
Based on my experience so far, I would definitely include expiration. I know it adds complexity, but there are TONS of problems on ETH with NFTs and fungible tokens because of never expire approvals. I think all approvals should have a reasonable expiration date.