4 of 5

ICRC-2: Recurring payments

Main question:

Do we need expiration of approvals and, if so, with which semantics?

→ The community response was not sufficient to make a decision.

Questions to answer

The "best" practice for ERC-20 to make large blanket approvals is seen as a big weakness of ERC-20 approve/transfer_from. This can be solved (at least partially) with expiration dates. Do we want to forego this opportunity and take over one of the main critiques from Ethereum's ERC-20 by not having an expiration date?
Expiration dates can (partially) solve the recurring subscription use case.
Expirations provide functionality for the end user. Are our projects the right parties to decide or does the group need to make a decision?

Now: Additive semantics, new approvals add/subtract from the running total and make the expiration date the new one for the total approved amount.
Levi's proposal: Each approval is handled separately, including its expiration date.

5 of 5

ICRC-2: Recurring payments

See meeting minutes for the discussion, some points below:

Expiration dates make the approach more different to ERC-20; this is not seen as a drawback.
Expirations (either approach) provide extra value, but also add substantial complexity to the specification and implementation.
Current additive semantics is not what one naturally expects.
Levi's Proposal is not substantially more complex than current approach.
We need to decide whether the added functionality of expirations is worth the complexity.