Skip to content

Commit

Permalink
Merge 8a11a87 into 94c2c89
Browse files Browse the repository at this point in the history
  • Loading branch information
byshape authored Jul 15, 2024
2 parents 94c2c89 + 8a11a87 commit e167942
Showing 1 changed file with 58 additions and 0 deletions.
58 changes: 58 additions & 0 deletions ERCS/erc-7674.md
Original file line number Diff line number Diff line change
@@ -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](./erc-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](./erc-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](./erc-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](https://github.com/ethereum/EIPs/blob/master/EIPS/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](./erc-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).

0 comments on commit e167942

Please sign in to comment.