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 ephemeral ERC-20 approvals
+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](./eip-20.md) tokens for spending within the same transaction.
+
+## Motivation
+
+User are often require to set token approval that will only be used once. It is common to leave unexpected approvals after these interactions. [EIP-1153](./eip-1153.md) introduces a cheap way to handle temporarily 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](./eip-20.md):
+```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.  This temporary allowance is to be considered in addition to the normal (persistent) [ERC-20](./eip-20.md) 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.
+
+The storage for the temporary allowances MUST be different to that of the regular allowance. Compliant contracts MAY use the transient storage [EIP-1153](./eip-1153.md) 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 emit a specific event.
+
+## 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](./eip-20.md) standard is backward compatible except for the `allowance` function.
+
+## Reference Implementation
+
+TBD <!-- TODO -->
+
+## 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).