ERC-7674 ERC-20 temporary approval extension (Temporary Approval Extension for ERC-20)
Review · Tokens · created 2024-04-02
An extension that adds a temporary approval to ERC-20 tokens, valid only for the duration of a single transaction. Temporary approvals are automatically cleared once the transaction ends, leaving no residual approval.
Why it is needed
To let another address transfer ERC-20 tokens on one's behalf, a limit must first be set via approve. In practice, however, many approvals are meant to be used only once. It is common for unexpected approvals to remain after such an interaction has ended. Because a remaining approval does not disappear when the transaction ends, the approved address can still withdraw tokens up to the remaining limit afterward. Meanwhile, Ethereum introduced the TSTORE opcode via EIP-1153, a form of temporary storage that is cleared once the transaction ends, which can be used to handle temporary limits efficiently. This standard defines a minimal interface for ERC-20 approvals usable only within the same transaction.
What to implement
function temporaryApprove(address spender, uint256 value) public returns (bool success): Sets a temporary limit allowing spender to withdraw tokens multiple times on behalf of msg.sender within the same transaction, up to a total of value.TransientApproval(address indexed owner, address indexed spender, uint256 value): An optional event that can be emitted when setting a temporary approval. It is not required.
In depth
The new function temporaryApprove
A compliant contract must implement one additional function beyond ERC-20. Calling temporaryApprove(spender, value) allows spender to make multiple withdrawals on behalf of msg.sender within the same transaction, with the total withdrawn not exceeding value. This temporary limit is a separate limit added on top of the existing ERC-20 permanent approval. Therefore, the total amount spender can spend during that transaction is limited by the sum of the temporary limit and the permanent limit.
transferFrom's spending priority
A single transferFrom call SHOULD be able to consume both the temporary limit and the permanent limit together, but the order of consumption SHOULD prioritize the temporary limit. If the temporary limit alone is sufficient, the permanent limit should not be read from or updated in storage. Consuming the permanent limit implies a storage access, so it should only be performed when the temporary limit falls short of covering the operation in progress. This avoids costly permanent storage access in one-time approval flows.
Lifetime of a temporary approval
A temporary approval MUST persist until the end of the transaction that created it, except when it is overwritten by another temporaryApprove call or consumed by transferFrom. Each temporary approval MUST also be cleared by the end of that transaction. The original text notes that EIP-1153's transient storage can be used to implement this. Transient storage contents disappear once the transaction ends, so it naturally satisfies this lifetime requirement.
Allowance return value and backward compatibility
The allowance function MUST return the sum of the temporary limit and the permanent limit. If the sum of the two values overflows, it must return type(uint256).max. Because of this, the allowance function is the only piece of ERC-20 functionality whose backward compatibility is broken. The original text explains that it kept interface extensions to a minimum for easy integration with existing infrastructure, accepting a change in the meaning of allowance as the tradeoff. It also adds that the required changes to the transferFrom implementation satisfy the requirement that the spender be explicitly granted permission to transfer tokens.
Deriving the transient storage slot
The storage space holding a temporary approval must differ from the storage space used for a regular approval. Compliant contracts can use EIP-1153's transient storage. A unique, non-overlapping slot must be chosen for each owner and spender combination, with the slot index derived from a base slot index for temporary approvals together with the owner and spender addresses. The original text gives the example of keccak256(spender . keccak256(owner . p)), where . denotes concatenation and p is the keccak256 hash of a string that uniquely defines temporary approvals within that contract's namespace.
Optional TransientApproval event
There is no requirement to emit an event when setting a temporary approval. However, a compliant contract may optionally emit a TransientApproval(address indexed owner, address indexed spender, uint256 value) event. This event is described in the reference implementation section rather than the specification body, and since it is not mandatory, implementations may or may not include it.
Proposal status
This proposal was created on April 2, 2024, and requires ERC-20 and EIP-1153 (requires: 20, 1153). Its current status is Review, meaning it is still under review and its specification may change before final confirmation. In particular, parts written as SHOULD, such as the priority of consuming the temporary limit first, may vary by implementation, so when actually implementing or integrating it, it is advisable to check the latest state of the original text.
Things to watch out for
- Avoiding slot collisions: The method used to derive the slot identifier for storing a temporary approval must not collide with other slots in the same space (e.g. transient storage).