From a7dffe7a532e0739b3a61768708ec153a12a8c1c Mon Sep 17 00:00:00 2001 From: byshape Date: Tue, 2 Apr 2024 22:27:47 +0100 Subject: [PATCH 01/16] Add Transient Approval Extension for ERC-20 --- ERCS/eip-draft_tae_erc20.md | 55 +++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 ERCS/eip-draft_tae_erc20.md diff --git a/ERCS/eip-draft_tae_erc20.md b/ERCS/eip-draft_tae_erc20.md new file mode 100644 index 0000000000..7ae99d3c81 --- /dev/null +++ b/ERCS/eip-draft_tae_erc20.md @@ -0,0 +1,55 @@ +--- +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 +status: Draft +type: Standards Track +category: ERC +created: 2024-04-02 +requires: ERC-20, EIP-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). \ No newline at end of file From d7eefe82abab661ce31f89f5234e46afbabe20fc Mon Sep 17 00:00:00 2001 From: byshape Date: Tue, 2 Apr 2024 22:43:46 +0100 Subject: [PATCH 02/16] Fixed EIP requirements --- ERCS/{eip-draft_tae_erc20.md => eip-draft-tae-erc20.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename ERCS/{eip-draft_tae_erc20.md => eip-draft-tae-erc20.md} (99%) diff --git a/ERCS/eip-draft_tae_erc20.md b/ERCS/eip-draft-tae-erc20.md similarity index 99% rename from ERCS/eip-draft_tae_erc20.md rename to ERCS/eip-draft-tae-erc20.md index 7ae99d3c81..8561e72ad2 100644 --- a/ERCS/eip-draft_tae_erc20.md +++ b/ERCS/eip-draft-tae-erc20.md @@ -7,7 +7,7 @@ status: Draft type: Standards Track category: ERC created: 2024-04-02 -requires: ERC-20, EIP-1153 +requires: 20, 1153 --- ## Abstract From 3eacea2344d0b26fbbe851ce2627d3ffe53bdf84 Mon Sep 17 00:00:00 2001 From: Xenia <94478708+byshape@users.noreply.github.com> Date: Wed, 3 Apr 2024 10:37:59 +0100 Subject: [PATCH 03/16] Update ERCS/eip-draft-tae-erc20.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/eip-draft-tae-erc20.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ERCS/eip-draft-tae-erc20.md b/ERCS/eip-draft-tae-erc20.md index 8561e72ad2..aa9d3c54aa 100644 --- a/ERCS/eip-draft-tae-erc20.md +++ b/ERCS/eip-draft-tae-erc20.md @@ -1,4 +1,5 @@ --- +eip: 7674 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) From 11e2cce131641033d4c85c13cd722bf9fbe3a21b Mon Sep 17 00:00:00 2001 From: byshape Date: Wed, 3 Apr 2024 10:45:36 +0100 Subject: [PATCH 04/16] Renamed file and added link to the discussion --- ERCS/{eip-draft-tae-erc20.md => erc-7674.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename ERCS/{eip-draft-tae-erc20.md => erc-7674.md} (96%) diff --git a/ERCS/eip-draft-tae-erc20.md b/ERCS/erc-7674.md similarity index 96% rename from ERCS/eip-draft-tae-erc20.md rename to ERCS/erc-7674.md index aa9d3c54aa..15e23b249c 100644 --- a/ERCS/eip-draft-tae-erc20.md +++ b/ERCS/erc-7674.md @@ -3,7 +3,7 @@ eip: 7674 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 +discussions-to: https://ethereum-magicians.org/t/add-erc-7674-transient-approval-extension-for-erc-20/19521 status: Draft type: Standards Track category: ERC From 85f7d71c1f3bb212bacd0568f80f0076f59ba593 Mon Sep 17 00:00:00 2001 From: byshape Date: Wed, 3 Apr 2024 11:20:03 +0100 Subject: [PATCH 05/16] Fixed description --- ERCS/erc-7674.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 15e23b249c..f97660609e 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -1,7 +1,7 @@ --- eip: 7674 title: Transient Approval Extension for ERC-20 -description: An interface for ERC-20 approvals via EIP-1153 transient storage +description: An interface for ERC-20 approvals via transient storage author: Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom) discussions-to: https://ethereum-magicians.org/t/add-erc-7674-transient-approval-extension-for-erc-20/19521 status: Draft @@ -45,7 +45,7 @@ All functionality of the `ERC-20` standard is backward compatible except for the ## Reference Implementation -The reference implementation can be found [here](https://github.com/byshape/transient-token/blob/main/contracts/TransientToken.sol). +TBD ## Security Considerations From a0d173e0e54443661c94b648115e1eee06e269fd Mon Sep 17 00:00:00 2001 From: byshape Date: Wed, 3 Apr 2024 15:57:48 +0100 Subject: [PATCH 06/16] Updated authors --- ERCS/erc-7674.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index f97660609e..206d5db98e 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -2,7 +2,7 @@ eip: 7674 title: Transient Approval Extension for ERC-20 description: An interface for ERC-20 approvals via transient storage -author: Xenia Shape (@byshape), Mikhail Melnik (@ZumZoom) +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 From 87ac36d8f942e5eef152848dd43fb4efca4465fe Mon Sep 17 00:00:00 2001 From: Xenia <94478708+byshape@users.noreply.github.com> Date: Thu, 4 Apr 2024 18:28:20 +0100 Subject: [PATCH 07/16] Apply suggestions from code review Co-authored-by: Hadrien Croubois --- ERCS/erc-7674.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 206d5db98e..d9efe9da07 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -31,9 +31,9 @@ Call to `transientApprove(spender, value)` allows `spender` to withdraw within t 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 check to the `transferFrom` function. The permanent allowance SHOULD 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. +Compliant contracts MUST add a transient allowance to the permanent one when returning the allowed amount to spend in the `allowance` function. In case the sum of the transient and permanent allowance overflow, `type(uint256).max` MUST be returned. ## Rationale From fba39482ab69fa6971219ef04145254bbab0ccb1 Mon Sep 17 00:00:00 2001 From: byshape Date: Thu, 4 Apr 2024 18:51:56 +0100 Subject: [PATCH 08/16] Replaced transient => temporary --- ERCS/erc-7674.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index d9efe9da07..fcbeb74237 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -1,6 +1,6 @@ --- eip: 7674 -title: Transient Approval Extension for ERC-20 +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 @@ -13,11 +13,11 @@ requires: 20, 1153 ## Abstract -This specification defines the minimum interface required to transiently 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. ## Motivation -`EIP-1153` allows to use a cheaper way to transiently store allowances. +`EIP-1153` allows to use a cheaper way to temporarily store allowances. ## Specification @@ -25,15 +25,15 @@ The key words "MUST", "SHOULD", "MAY" in this document are to be interpreted as Compliant contracts MUST implement 1 new function in addition to `ERC-20`: ```solidity -function transientApprove(address spender, uint256 value) public returns (bool success) +function temporaryApprove(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. +Call to `temporaryApprove(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 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 transient 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 check to the `transferFrom` function. The permanent allowance SHOULD 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. In case the sum of the transient and permanent allowance overflow, `type(uint256).max` MUST be returned. +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. ## Rationale From c5e98c27793e426ea39ca6c629a12c6cbbf5d18b Mon Sep 17 00:00:00 2001 From: byshape Date: Thu, 4 Apr 2024 19:24:30 +0100 Subject: [PATCH 09/16] Refined the Specification, Rationale and Backwards Compatibility sections --- ERCS/erc-7674.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index fcbeb74237..030fed2ec7 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -35,13 +35,15 @@ Compliant contracts MUST add a temporary allowance check to the `transferFrom` f 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` and `transferFrom` functions. +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` and `transferFrom` functions. +All functionality of the `ERC-20` standard is backward compatible except for the `allowance` function. ## Reference Implementation From 17a27410cf8441db2992b3b27363245ca9b21ef6 Mon Sep 17 00:00:00 2001 From: Xenia <94478708+byshape@users.noreply.github.com> Date: Sat, 6 Apr 2024 20:13:26 +0100 Subject: [PATCH 10/16] Generalise the temporary storage description MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ernesto García --- ERCS/erc-7674.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 030fed2ec7..9f705cbc37 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -29,7 +29,7 @@ function temporaryApprove(address spender, uint256 value) public returns (bool s ``` Call to `temporaryApprove(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 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. +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. @@ -51,7 +51,7 @@ TBD ## Security Considerations -The method of deriving slot identifiers to store temporary allowances must avoid collision with other transient storage slots. +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 From d70eb46f4f3880ceac07ad33f01ce6abf8e6f85c Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 6 Jun 2024 16:35:06 +0200 Subject: [PATCH 11/16] update based on PR comments --- ERCS/erc-7674.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 9f705cbc37..44330225d5 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -1,7 +1,7 @@ --- eip: 7674 title: Temporary Approval Extension for ERC-20 -description: An interface for ERC-20 approvals via transient storage +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 @@ -13,11 +13,11 @@ requires: 20, 1153 ## Abstract -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. +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 @@ -27,7 +27,7 @@ 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. +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 (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` 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. @@ -35,7 +35,7 @@ Compliant contracts MUST add a temporary allowance check to the `transferFrom` f 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. +No event is required when setting a temporary allowance, but compliant contracts MAY emit a specific event. ## Rationale @@ -47,7 +47,7 @@ All functionality of the `ERC-20` standard is backward compatible except for the ## Reference Implementation -TBD +TBD ## Security Considerations From fe0967763e75cee3ac17f275aad6f105d17800c8 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Mon, 10 Jun 2024 15:40:13 +0200 Subject: [PATCH 12/16] Update ERCS/erc-7674.md Co-authored-by: Mikhail Melnik --- ERCS/erc-7674.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 44330225d5..12313abd26 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -27,7 +27,7 @@ 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. 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 (persistent) allowances. +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 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` 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. From 3c10621486d401040e187e56c31e570f292926c4 Mon Sep 17 00:00:00 2001 From: byshape Date: Mon, 10 Jun 2024 17:56:57 +0100 Subject: [PATCH 13/16] Update based on PR comments --- ERCS/erc-7674.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 12313abd26..678b76464c 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -13,7 +13,7 @@ requires: 20, 1153 ## Abstract -This specification defines the minimum interface required to temporarily approve `ERC-20` tokens for spending within the same transaction. +This specification defines the minimum interface required to temporarily approve [ERC-20](./eip-20.md) tokens for spending within the same transaction. ## Motivation @@ -23,13 +23,13 @@ User are often require to set token approval that will only be used once. It is 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`: +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) ERC20 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. +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` 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. +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. @@ -39,11 +39,11 @@ No event is required when setting a temporary allowance, but compliant contracts ## 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. +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` standard is backward compatible except for the `allowance` function. +All functionality of the [ERC-20](./eip-20.md) standard is backward compatible except for the `allowance` function. ## Reference Implementation From 1ce1aae08c52f9a9e26f22cfb8710f00ad925f68 Mon Sep 17 00:00:00 2001 From: Mikhail Melnik Date: Mon, 15 Jul 2024 12:52:04 +0200 Subject: [PATCH 14/16] fix erc/eip links --- ERCS/erc-7674.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 678b76464c..b4b7424e43 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -13,7 +13,7 @@ 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. +This specification defines the minimum interface required to temporarily approve [ERC-20](./erc-20.md) tokens for spending within the same transaction. ## Motivation @@ -23,13 +23,13 @@ User are often require to set token approval that will only be used once. It is 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): +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](./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. +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](./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. +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. @@ -43,7 +43,7 @@ It was decided to make minimal interface extension to allow easier integration o ## Backwards Compatibility -All functionality of the [ERC-20](./eip-20.md) standard is backward compatible except for the `allowance` function. +All functionality of the [ERC-20](./erc-20.md) standard is backward compatible except for the `allowance` function. ## Reference Implementation From 51b7148df43687c98810cde0508673a7367ae6cf Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Thu, 8 Aug 2024 15:35:47 -0400 Subject: [PATCH 15/16] Update erc-7674.md: fix eip links --- ERCS/erc-7674.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index b4b7424e43..4dc5a36c85 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -13,7 +13,7 @@ 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. +This specification defines the minimum interface required to temporarily approve [ERC-20](./eip-20.md) tokens for spending within the same transaction. ## Motivation @@ -23,11 +23,11 @@ User are often require to set token approval that will only be used once. It is 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): +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](./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. +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](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. @@ -43,7 +43,7 @@ It was decided to make minimal interface extension to allow easier integration o ## Backwards Compatibility -All functionality of the [ERC-20](./erc-20.md) standard is backward compatible except for the `allowance` function. +All functionality of the [ERC-20](./eip-20.md) standard is backward compatible except for the `allowance` function. ## Reference Implementation @@ -55,4 +55,4 @@ The method of deriving slot identifiers to store temporary allowances must avoid ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). \ No newline at end of file +Copyright and related rights waived via [CC0](../LICENSE.md). From b7978f82e13c8f944bb5aae4adc4bdabe6478a79 Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Thu, 8 Aug 2024 15:38:31 -0400 Subject: [PATCH 16/16] Update erc-7674.md --- ERCS/erc-7674.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7674.md b/ERCS/erc-7674.md index 4dc5a36c85..c4cc9d0072 100644 --- a/ERCS/erc-7674.md +++ b/ERCS/erc-7674.md @@ -29,7 +29,7 @@ function temporaryApprove(address spender, uint256 value) public returns (bool s ``` 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](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. +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.