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.

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

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

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions ERCS/eip-draft-tae-erc20.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
byshape marked this conversation as resolved.
Show resolved Hide resolved
title: Transient Approval Extension for ERC-20
description: An interface for ERC-20 approvals via EIP-1153 transient storage
author: Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom)
discussions-to: # TODO: update
byshape marked this conversation as resolved.
Show resolved Hide resolved
status: Draft
type: Standards Track
category: ERC
created: 2024-04-02
requires: 20, 1153
---

## Abstract

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

## Motivation

`EIP-1153` allows to use a cheaper way to transiently 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 transientApprove(address spender, uint256 value) public returns (bool success)
```
Call to `transientApprove(spender, value)` allows `spender` to withdraw within the same transaction from `msg.sender` multiple times, up to the `value` amount.

Compliant contracts MUST 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 transient 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 transient allowances in the namespace of the implementing contract.

Compliant contracts MUST add a transient allowance check to the `transferFrom` function. The permanent allowance can only be spent after the temporary allowance has been exhausted.

Compliant contracts MUST add a transient allowance to the permanent one when returning the allowed amount to spend in the `allowance` function.

## 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` and `transferFrom` functions.

## Backwards Compatibility

All functionality of the `ERC-20` standard is backward compatible except for the `allowance` and `transferFrom` functions.

## Reference Implementation

The reference implementation can be found [here](https://github.com/byshape/transient-token/blob/main/contracts/TransientToken.sol).

## Security Considerations

The method of deriving slot identifiers to store temporary allowances must avoid collision with other transient storage slots.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading