Update ERC-3009: Move to Draft

Merged by EIP-Bot.

Author: petejkim

ERCS/erc-3009.md

@@ -1,49 +1,55 @@
 ---
 eip: 3009
 title: Transfer With Authorization
+description: Transfer fungible assets via a signed authorization
 author: Peter Jihoon Kim (@petejkim), Kevin Britz (@kbrizzle), David Knott (@DavidLKnott)
-discussions-to: https://github.com/ethereum/EIPs/issues/3010
-status: Stagnant
+discussions-to: https://ethereum-magicians.org/t/erc-3009-transfer-with-authorization/25698
+status: Draft
 type: Standards Track
 category: ERC
 created: 2020-09-28
 requires: 20, 712
 ---
 
-## Simple Summary
-
-A contract interface that enables transferring of fungible assets via a signed authorization.
-
 ## Abstract
 
 A set of functions to enable meta-transactions and atomic interactions with [ERC-20](./eip-20.md) token contracts via signatures conforming to the [EIP-712](./eip-712.md) typed message signing specification.
 
 This enables the user to:
 
 - delegate the gas payment to someone else,
-- pay for gas in the token itself rather than in ETH,
+- pay gas in the token itself rather than in ETH,
 - perform one or more token transfers and other operations in a single atomic transaction,
 - transfer ERC-20 tokens to another address, and have the recipient submit the transaction,
 - batch multiple transactions with minimal overhead, and
 - create and perform multiple transactions without having to worry about them failing due to accidental nonce-reuse or improper ordering by the miner.
 
+Please note that this ERC does not apply to smart contract accounts, as the `transfer` and `approve`/`transferFrom` functions from the ERC-20 standards can directly be used.
+
+<!-- TODO (Editor's note): we don't permit links outside of the EIP/ERC repositories, with some exceptions noted in EIP-1
+
+This ERC has been live in production within the USDC smart contract since 2020, and serves as a critical component of the [x402](https://www.x402.org/) standard.
+
+-->
+
 ## Motivation
 
-There is an existing spec, [EIP-2612](./eip-2612), that also allows meta-transactions, and it is encouraged that a contract implements both for maximum compatibility. The two primary differences between this spec and EIP-2612 are that:
+There is an existing spec, [ERC-2612](./eip-2612.md), that also allows meta-transactions, and it is encouraged that a contract implements both for maximum compatibility. The two primary differences between this spec and ERC-2612 are that:
 
-- EIP-2612 uses sequential nonces, but this uses random 32-byte nonces, and that
-- EIP-2612 relies on the ERC-20 `approve`/`transferFrom` ("ERC-20 allowance") pattern.
+- ERC-2612 uses sequential nonces, but this uses random 32-byte nonces, and that
+- ERC-2612 relies on the ERC-20 `approve`/`transferFrom` ("ERC-20 allowance") pattern.
 
-The biggest issue with the use of sequential nonces is that it does not allow users to perform more than one transaction at time without risking their transactions failing, because:
+The biggest issue with the use of sequential nonces is that it does not allow users to perform more than one transaction at a time without risking their transactions failing, because:
 
 - DApps may unintentionally reuse nonces that have not yet been processed in the blockchain.
 - Miners may process the transactions in the incorrect order.
 
 This can be especially problematic if the gas prices are very high and transactions often get queued up and remain unconfirmed for a long time. Non-sequential nonces allow users to create as many transactions as they want at the same time.
 
-The ERC-20 allowance mechanism is susceptible to the [multiple withdrawal attack](https://blockchain-projects.readthedocs.io/multiple_withdrawal.html)/[SWC-114](https://swcregistry.io/docs/SWC-114), and encourages antipatterns such as the use of the "infinite" allowance. The wide-prevalence of upgradeable contracts have made the conditions favorable for these attacks to happen in the wild.
+The ERC-20 allowance mechanism is susceptible to the <!-- TODO (Editor's note): same note as above.
+[multiple withdrawal attack](https://blockchain-projects.readthedocs.io/multiple_withdrawal.html) -->/<!-- TODO (Editor's note): you can copy the SWC into your assets directory because it's MIT licensed. [SWC-114](https://swcregistry.io/docs/SWC-114) -->, and encourages antipatterns such as the use of the "infinite" allowance. The wide prevalence of upgradeable contracts has made the conditions favorable for these attacks to happen in the wild.
 
-The deficiencies of the ERC-20 allowance pattern brought about the development of alternative token standards such as the [ERC-777](./eip-777) and [ERC-677](https://github.com/ethereum/EIPs/issues/677). However, they haven't been able to gain much adoption due to compatibility and potential security issues.
+The deficiencies of the ERC-20 allowance pattern brought about the development of alternative token standards such as the [ERC-777](./eip-777.md) and <!-- TODO (Editor's note): if you'd like to link to ERC-677, you'll need to pull request it into the repository (i.e. upgrade it) [ERC-677](https://github.com/ethereum/EIPs/issues/677) -->. However, they haven't been able to gain much adoption due to compatibility and potential security issues.
 
 ## Specification
 
@@ -197,7 +203,7 @@ Params := { Authorizer, Nonce }
 
 ```
 // "‖" denotes concatenation.
-Digest := Keecak256(
+Digest := Keccak256(
   0x1901 ‖ DomainSeparator ‖ Keccak256(ABIEncode(TypeHash, Params...))
 )
 
@@ -294,7 +300,7 @@ One might say transaction ordering is one reason why sequential nonces are prefe
 - For native Ethereum transactions, when a transaction with a nonce value that is too-high is submitted to the network, it will stay pending until the transactions consuming the lower unused nonces are confirmed.
 - However, for meta-transactions, when a transaction containing a sequential nonce value that is too high is submitted, instead of staying pending, it will revert and fail immediately, resulting in wasted gas.
 - The fact that miners can also reorder transactions and include them in the block in the order they want (assuming each transaction was submitted to the network by different meta-transaction relayers) also makes it possible for the meta-transactions to fail even if the nonces used were correct. (e.g. User submits nonces 3, 4 and 5, but miner ends up including them in the block as 4,5,3, resulting in only 3 succeeding)
-- Lastly, when using different applications simultaneously, in absence of some sort of an off-chain nonce-tracker, it is not possible to determine what the correct next nonce value is if there exists nonces that are used but haven't been submitted and confirmed by the network.
+- Lastly, when using different applications simultaneously, in the absence of some sort of an off-chain nonce tracker, it is not possible to determine what the correct next nonce value is if there exists nonces that are used but haven't been submitted and confirmed by the network.
 - Under high gas price conditions, transactions can often "get stuck" in the pool for a long time. Under such a situation, it is much more likely for the same nonce to be unintentionally reused twice. For example, if you make a meta-transaction that uses a sequential nonce from one app, and switch to another app to make another meta-transaction before the previous one confirms, the same nonce will be used if the app relies purely on the data available on-chain, resulting in one of the transactions failing.
 - In conclusion, the only way to guarantee transaction ordering is for relayers to submit transactions one at a time, waiting for confirmation between each submission (and the order in which they should be submitted can be part of some off-chain metadata), rendering sequential nonce irrelevant.
 
@@ -310,9 +316,9 @@ One might say transaction ordering is one reason why sequential nonces are prefe
 
 ## Backwards Compatibility
 
-New contracts benefit from being able to directly utilize EIP-3009 in order to create atomic transactions, but existing contracts may still rely on the conventional ERC-20 allowance pattern (`approve`/`transferFrom`).
+New contracts benefit from being able to directly utilize [ERC-3009](./eip-3009.md) in order to create atomic transactions, but existing contracts may still rely on the conventional ERC-20 allowance pattern (`approve`/`transferFrom`).
 
-In order to add support for EIP-3009 to existing contracts ("parent contract") that use the ERC-20 allowance pattern, a forwarding contract ("forwarder") can be constructed that takes an authorization and does the following:
+In order to add support for ERC-3009 to existing contracts ("parent contract") that use the ERC-20 allowance pattern, a forwarding contract ("forwarder") can be constructed that takes an authorization and does the following:
 
 1. Extract the user and deposit amount from the authorization
 2. Call `receiveWithAuthorization` to transfer specified funds from the user to the forwarder
@@ -372,7 +378,7 @@ contract DepositForwarder {
             "Failed to transfer the minted tokens"
         );
 
-        uint256 remainder = _token.balanceOf(address(this);
+        uint256 remainder = _token.balanceOf(address(this));
         if (remainder > 0) {
             require(
                 _token.transfer(from, remainder),
@@ -385,13 +391,16 @@ contract DepositForwarder {
 }
 ```
 
+<!-- TODO (Editor's note): please move your test cases into your assets directory (assuming they're under a permissive license)
 ## Test Cases
 
 See [EIP3009.test.ts](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/test/EIP3009.test.ts).
+-->
+
+## Reference Implementation
 
-## Implementation
+### `EIP3009.sol`
 
-**EIP3009.sol**
 ```solidity
 abstract contract EIP3009 is IERC20Transfer, EIP712Domain {
     // keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
@@ -454,7 +463,8 @@ abstract contract EIP3009 is IERC20Transfer, EIP712Domain {
 }
 ```
 
-**IERC20Transfer.sol**
+### `IERC20Transfer.sol`
+
 ```solidity
 abstract contract IERC20Transfer {
     function _transfer(
@@ -465,14 +475,16 @@ abstract contract IERC20Transfer {
 }
 ```
 
-**EIP712Domain.sol**
+### `EIP712Domain.sol`
+
 ```solidity
 abstract contract EIP712Domain {
     bytes32 public DOMAIN_SEPARATOR;
 }
 ```
 
-**EIP712.sol**
+### `EIP712.sol`
+
 ```solidity
 library EIP712 {
     // keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)")
@@ -494,8 +506,8 @@ library EIP712 {
                     EIP712_DOMAIN_TYPEHASH,
                     keccak256(bytes(name)),
                     keccak256(bytes(version)),
-                    address(this),
-                    bytes32(chainId)
+                    chainId,
+                    address(this)
                 )
             );
     }
@@ -521,15 +533,15 @@ library EIP712 {
 }
 ```
 
-A fully working implementation of EIP-3009 can be found in [this repository](../assets/eip-3009/EIP3009.sol). The repository also includes [an implementation of EIP-2612](../assets/eip-3009/EIP2612.sol) that uses the EIP-712 library code presented above.
+A fully working implementation of ERC-3009 can be found in [this repository](../assets/eip-3009/ERC3009.sol). The repository also includes [an implementation of ERC-2612](../assets/eip-3009/ERC2612.sol) that uses the EIP-712 library code presented above.
 
 ## Security Considerations
 
-Use `receiveWithAuthorization` instead of `transferWithAuthorization` when calling from other smart contracts. It is possible for an attacker watching the transaction pool to extract the transfer authorization and front-run the `transferWithAuthorization` call to execute the transfer without invoking the wrapper function. This could potentially result in unprocessed, locked up deposits. `receiveWithAuthorization` prevents this by performing an additional check that ensures that the caller is the payee. Additionally, if there are multiple contract functions accepting receive authorizations, the app developer could dedicate some leading bytes of the nonce could as the identifier to prevent cross-use.
+Use `receiveWithAuthorization` instead of `transferWithAuthorization` when calling from other smart contracts. It is possible for an attacker watching the transaction pool to extract the transfer authorization and front-run the `transferWithAuthorization` call to execute the transfer without invoking the wrapper function. This could potentially result in unprocessed, locked up deposits. `receiveWithAuthorization` prevents this by performing an additional check that ensures that the caller is the payee. Additionally, if there are multiple contract functions accepting receive authorizations, the app developer could dedicate some leading bytes of the nonce as an identifier to prevent cross-use.
 
 When submitting multiple transfers simultaneously, be mindful of the fact that relayers and miners will decide the order in which they are processed. This is generally not a problem if the transactions are not dependent on each other, but for transactions that are highly dependent on each other, it is recommended that the signed authorizations are submitted one at a time.
 
-The zero address must be rejected when using `ecrecover` to prevent unauthorized transfers and approvals of funds from the zero address. The built-in `ecrecover` returns the zero address when a malformed signature is provided.
+The zero address must be rejected when `ecrecover` is used to prevent unauthorized transfers and approvals of funds from the zero address. The built-in `ecrecover` returns the zero address when a malformed signature is provided.
 
 ## Copyright
 

assets/erc-3009/EIP712.sol

@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+
+pragma solidity 0.6.12;
+
+import { ECRecover } from "./ECRecover.sol";
+
+/**
+ * @title EIP712
+ * @notice A library that provides EIP712 helper functions
+ */
+library EIP712 {
+    // keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)")
+    bytes32
+        public constant EIP712_DOMAIN_TYPEHASH = 0x8b73c3c69bb8fe3d512ecc4cf759cc79239f7b179b0ffacaa9a75d522b39400f;
+
+    /**
+     * @notice Make EIP712 domain separator
+     * @param name      Contract name
+     * @param version   Contract version
+     * @return Domain separator
+     */
+    function makeDomainSeparator(string memory name, string memory version)
+        internal
+        view
+        returns (bytes32)
+    {
+        uint256 chainId;
+        assembly {
+            chainId := chainid()
+        }
+
+        return
+            keccak256(
+                abi.encode(
+                    EIP712_DOMAIN_TYPEHASH,
+                    keccak256(bytes(name)),
+                    keccak256(bytes(version)),
+                    chainId,
+                    address(this)
+                )
+            );
+    }
+
+    /**
+     * @notice Recover signer's address from a EIP712 signature
+     * @param domainSeparator   Domain separator
+     * @param v                 v of the signature
+     * @param r                 r of the signature
+     * @param s                 s of the signature
+     * @param typeHashAndData   Type hash concatenated with data
+     * @return Signer's address
+     */
+    function recover(
+        bytes32 domainSeparator,
+        uint8 v,
+        bytes32 r,
+        bytes32 s,
+        bytes memory typeHashAndData
+    ) internal pure returns (address) {
+        bytes32 digest = keccak256(
+            abi.encodePacked(
+                "\x19\x01",
+                domainSeparator,
+                keccak256(typeHashAndData)
+            )
+        );
+        return ECRecover.recover(digest, v, r, s);
+    }
+}

assets/erc-3009/EIP712Domain.sol

@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: MIT
+
+pragma solidity 0.6.12;
+
+abstract contract EIP712Domain {
+    /**
+     * @dev EIP712 Domain Separator
+     */
+    bytes32 public DOMAIN_SEPARATOR;
+}

assets/erc-3009/EIP2612.sol renamed to assets/erc-3009/ERC2612.sol

@@ -1,34 +1,12 @@
-/**
- * SPDX-License-Identifier: MIT
- *
- * Copyright (c) 2020 CENTRE SECZ
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- */
+// SPDX-License-Identifier: MIT
 
 pragma solidity 0.6.12;
 
 import { IERC20Internal } from "./IERC20Internal.sol";
 import { EIP712Domain } from "./EIP712Domain.sol";
 import { EIP712 } from "./EIP712.sol";
 
-abstract contract EIP2612 is IERC20Internal, EIP712Domain {
+abstract contract ERC2612 is IERC20Internal, EIP712Domain {
     // keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)")
     bytes32
         public constant PERMIT_TYPEHASH = 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9;
@@ -63,7 +41,7 @@ abstract contract EIP2612 is IERC20Internal, EIP712Domain {
         bytes32 r,
         bytes32 s
     ) external {
-        require(deadline >= now, "EIP2612: permit is expired");
+        require(deadline >= now, "ERC2612: permit is expired");
 
         bytes memory data = abi.encode(
             PERMIT_TYPEHASH,
@@ -75,7 +53,7 @@ abstract contract EIP2612 is IERC20Internal, EIP712Domain {
         );
         require(
             EIP712.recover(DOMAIN_SEPARATOR, v, r, s, data) == owner,
-            "EIP2612: invalid signature"
+            "ERC2612: invalid signature"
         );
 
         _approve(owner, spender, value);