主页EIPs周刊
EIPsERC-7674
ERC-7674

Temporary Approval Extension for ERC-20

Ephemeral ERC-20 approvals lasting a single transaction
DraftStandards Track: ERC
创建时间: 2024-04-02
关联 EIP: EIP-20, EIP-1153
Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom), Hadrien Croubois (@Amxx)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Abstract

This specification defines the minimum interface required to temporarily approve ERC-20 tokens for spending within the same transaction.

Motivation

User are often required to set a token approval that will only be used once. It is common to leave unexpected approvals after these interactions. EIP-1153 introduces TSTORE, which can be used to efficiently handle temporarily allowances.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Compliant contracts MUST implement 1 new function in addition to ERC-20:

function temporaryApprove(address spender, uint256 value) public returns (bool success)

A call to temporaryApprove(spender, value) allows spender to withdraw within the same transaction on behalf of msg.sender multiple times, such that the total withdrawn is less than or equal to the value amount. This temporary allowance is to be considered in addition to the normal (persistent) ERC-20 allowance. The total value that spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (persistent) allowances. While it SHOULD be possible for a transferFrom operation to consume both types of allowance, the consumption of the temporary allowance SHOULD take priority over the consumption of the persistent allowance. Therefore, if the temporary allowance is sufficient for executing a transferFrom operation, the persistent allowance SHOULD not be loaded/updated from the storage. Consumption of persistent allowance, which implies storage accesses, SHOULD be performed only if the temporary allowance is not sufficient for the operation being executed.

Each temporary allowance MUST persist until the end of the transaction that created it (unless overwritten by another call to temporaryApprove or consumed by a call to transferFrom). Each temporary allowance MUST be cleared at the end of the transaction that created it. See Using Transient Storage for an example.

Compliant contracts MUST add a temporary allowance to the permanent one when returning the allowed amount to spend in the allowance function. In case the sum of the temporary and permanent allowance overflow, type(uint256).max MUST be returned.

Rationale

It was decided to make minimal interface extension to allow easier integration of a compliant contract into the existing infrastructure. This affects the backward compatibility of the allowance function. However, the required changes to the transferFrom function implementation satisfy the requirement to explicitly authorize the spender to transfer tokens.

Backwards Compatibility

All functionality of the ERC-20 standard is backward compatible except for the allowance function.

Reference Implementation

Using Transient Storage

The storage for the temporary allowances MUST be different to that of the regular allowance. Compliant contracts MAY use the transient storage EIP-1153 to keep the temporary allowance. For each owner and spender, the slot MUST be uniquely selected to avoid slot collision. Each slot index SHOULD be derived from the base slot index for temporary allowances, owner and spender addresses. Slot MAY be derived as keccak256(spender . keccak256(owner . p)) where . is concatenation and p is keccak256 from the string uniquely defining temporary allowances in the namespace of the implementing contract.

Events

Even though no event is required when setting a temporary allowance, compliant contracts MAY emit TransientApproval(address indexed owner, address indexed spender, uint256 value) event.

Security Considerations

The method of deriving slot identifiers to store temporary allowances must avoid collision with other slots in the same space (e.g. transient storage).

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub