Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add ERC: Temporary Approval Extension for ERC-20 #358

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Add ERC: Temporary Approval Extension for ERC-20 #358

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
a7dffe7
Add Transient Approval Extension for ERC-20
byshape Apr 2, 2024
d7eefe8
Fixed EIP requirements
byshape Apr 2, 2024
3eacea2
Update ERCS/eip-draft-tae-erc20.md
byshape Apr 3, 2024
11e2cce
Renamed file and added link to the discussion
byshape Apr 3, 2024
85f7d71
Fixed description
byshape Apr 3, 2024
a0d173e
Updated authors
byshape Apr 3, 2024
87ac36d
Apply suggestions from code review
byshape Apr 4, 2024
5146bb9
Merge branch 'master' into transient-approve
byshape Apr 4, 2024
fba3948
Replaced transient => temporary
byshape Apr 4, 2024
c5e98c2
Refined the Specification, Rationale and Backwards Compatibility sect…
byshape Apr 4, 2024
17a2741
Generalise the temporary storage description
byshape Apr 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
58 changes: 58 additions & 0 deletions ERCS/erc-7674.md
View file
Open in desktop
@@ -0,0 +1,58 @@
---
eip: 7674
title: Temporary Approval Extension for ERC-20
description: An interface for ERC-20 approvals via transient storage
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: An interface for ERC-20 approvals via transient storage
description: An interface for single-block approvals for ERC-20

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transient is not single-block though, its single-transaction. I like the idea, but we would need the wording to accuratly describe what transient does.

Maybe

Suggested change
description: An interface for ERC-20 approvals via transient storage
description: An interface for ephemeral ERC-20 approvals

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, 100% agree wth your suggestion 👍🏻

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.
Copy link
Contributor

@ernestognw ernestognw Apr 4, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This specification defines the minimum interface required to temporarily approve `ERC-20` tokens for spending within a single transaction.
This specification defines the minimum interface required to temporarily approve `ERC-20` tokens for spending within a single transaction (i.e. approval lasts for a single transaction).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment: "single block" is incorrect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Updated accordingly

Copy link

@ZumZoom ZumZoom Apr 10, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually find this wording to be cleaner instead of adding extra text in parens:

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


## Motivation

`EIP-1153` allows to use a cheaper way to temporarily store allowances.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`EIP-1153` allows to use a cheaper way to temporarily store allowances.
Multiple smart contracts often require approval for a single transaction, however, it is common to leave unexpected approvals after interacting with those contracts. Similarly, `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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.
Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value + allowance(owner, spender)` amount.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be updated regardless.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're talking about the same transaction, I think it's better to mention only value since allowance(owner, spender) can be spent (or not) later too.

Copy link
Contributor

@ernestognw ernestognw Apr 8, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind of making the wording more clear about the subject?

Suggested change
Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.
Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount before consuming the permanent allowance.

As ERC implementer, making this clear removes ambiguity of whether the the ephemeral allowance should start reverting after exceeded value or just start consuming the permanent one.

Also note that the following wording doesn't require this behavior, otherwise it'd be a MUST.

The permanent allowance SHOULD only be spent after the temporary allowance has been exhausted.

Not a big deal, but hey, we don't want to end up writing more SafeERC20 utils 😆

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Call to `temporaryApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.
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) ERC20 allowance, the total value than spender is able to spend during the transaction is thus capped by the sum of the temporary and the normal (pensistent) allowances.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo in the end — "(persistent)"


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).