Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…

…ve-erc1363-to-eip1-recommendation-1step

ERCS/erc-4337.md

@@ -379,9 +379,9 @@ While simulating `userOp` validation, the client should make sure that:
    1. must not use value (except from account to the entrypoint)
    2. must not revert with out-of-gas
    3. destination address must have code (EXTCODESIZE>0) or be a standard Ethereum precompile defined at addresses from `0x01` to `0x09`
-   4. cannot call EntryPoint's methods, except `depositFor` (to avoid recursion)
+   4. cannot call EntryPoint's methods, except `depositTo` (to avoid recursion)
 5. `EXTCODEHASH` of every address accessed (by any opcode) does not change between first and second simulations of the op.
-6. `EXTCODEHASH`, `EXTCODELENGTH`, `EXTCODECOPY` may not access address with no code.
+6. `EXTCODEHASH`, `EXTCODESIZE`, `EXTCODECOPY` may not access address with no code.
 7. If `op.initcode.length != 0` , allow only one `CREATE2` opcode call (in the first (deployment) block), otherwise forbid `CREATE2`.
 
 Transient Storage slots defined in [EIP-1153](./eip-1153.md) and accessed using `TLOAD` (`0x5c`) and `TSTORE` (`0x5d`) opcodes

ERCS/erc-6120.md

@@ -21,7 +21,7 @@ The Universal Token Router (UTR) separates the token allowance from the applicat
 
 Tokens approved to the Universal Token Router can only be spent in transactions directly signed by their owner, and they have clearly visible token transfer behavior, including token types (ETH, [ERC-20](./eip-20.md), [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md)), `amountIn`, `amountOutMin`, and `recipient`.
 
-The Universal Token Router contract is deployed using the [EIP-1014](./eip-1014.md) SingletonFactory contract at a single address across all EVM-compatible networks. This enables new token contracts to pre-configure it as a trusted spender, eliminating the need for approval transactions during their interactive usage.
+The Universal Token Router contract is deployed using the [EIP-1014](./eip-1014.md) SingletonFactory contract at `0x8Bd6072372189A12A2889a56b6ec982fD02b0B87` across all EVM-compatible networks. This enables new token contracts to pre-configure it as a trusted spender, eliminating the need for approval transactions during their interactive usage.
 
 ## Motivation
 
@@ -92,6 +92,7 @@ struct Action {
     bytes data;         // contract input data
 }
 ```
+
 The action code contract MUST implement the [ERC-165](./eip-165.md) interface with the ID `0x61206120` in order to be called by the UTR. This interface check prevents direct invocation of token *allowance-spending* functions (e.g., `transferFrom`) by the UTR. Therefore, new token contracts MUST NOT implement this interface ID.
 
 ```solidity
@@ -403,6 +404,49 @@ Old token contracts (ERC-20, ERC-721 and ERC-1155) require approval for the Univ
 
 New token contracts can pre-configure the Universal Token Router as a trusted spender, and no approval transaction is required for interactive usage.
 
+```solidity
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+
+/**
+ * @dev Implementation of the {ERC20} token standard that support a trusted ERC6120 contract as an unlimited spender.
+ */
+contract ERC20WithUTR is ERC20 {
+    address immutable UTR;
+
+    /**
+     * @dev Sets the values for {name}, {symbol} and ERC6120's {utr} address.
+     *
+     * All three of these values are immutable: they can only be set once during
+     * construction.
+     *
+     * @param utr can be zero to disable trusted ERC6120 support.
+     */
+    constructor(string memory name, string memory symbol, address utr) ERC20(name, symbol) {
+        UTR = utr;
+    }
+
+    /**
+     * @dev See {IERC20-allowance}.
+     */
+    function allowance(address owner, address spender) public view virtual override returns (uint256) {
+        if (spender == UTR && spender != address(0)) {
+            return type(uint256).max;
+        }
+        return super.allowance(owner, spender);
+    }
+
+    /**
+     * Does not check or update the allowance if `spender` is the UTR.
+     */
+    function _spendAllowance(address owner, address spender, uint256 amount) internal virtual override {
+        if (spender == UTR && spender != address(0)) {
+            return;
+        }
+        super._spendAllowance(owner, spender, amount);
+    }
+}
+```
+
 ### Applications
 
 The only application contracts **INCOMPATIBLE** with the UTR are contracts that use `msg.sender` as the beneficiary address in their internal storage without any function for ownership transfer.
@@ -425,7 +469,7 @@ Additional helper and adapter contracts might be needed, but they're mostly peri
 
 ## Reference Implementation
 
-A reference implementation by Derivable Labs, verified by Hacken.
+A reference implementation by Derivable Labs and audited by Hacken.
 
 ```solidity
 /// @title The implemetation of the EIP-6120.