Add ERC: Temporary Approval Extension for ERC-20

ERCS/erc-7674.md

@@ -0,0 +1,58 @@
+---
+eip: 7674
+title: Temporary Approval Extension for ERC-20
+description: An interface for ERC-20 approvals via transient storage
+author: Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom), Hadrien Croubois (@Amxx)
+discussions-to: https://ethereum-magicians.org/t/add-erc-7674-transient-approval-extension-for-erc-20/19521
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-04-02
+requires: 20, 1153
+---
+
+## Abstract
+
+This specification defines the minimum interface required to temporarily approve `ERC-20` tokens for spending within a single transaction.
+
+## Motivation
+
+`EIP-1153` allows to use a cheaper way to temporarily store allowances.
+
+## Specification
+
+The key words "MUST", "SHOULD", "MAY" 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`:
+```solidity
+function temporaryApprove(address spender, uint256 value) public returns (bool success)
+```
+Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.
+
+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.
+
+Compliant contracts MUST add a temporary allowance check to the `transferFrom` function. The permanent allowance SHOULD only be spent after the temporary allowance has been exhausted.
+
+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.
+
+No event is required when setting a temporary allowance, but compliant contracts MAY implement it.
+
+## Rationale
+
+The main goal of this standard is to make it cheaper to approve `ERC-20` tokens for a single transaction with minimal interface extension to allow easier integration of a compliant contract into 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
+
+TBD
+
+## 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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).