From 4a8c824869b6017beef816bcc7caed1e79458015 Mon Sep 17 00:00:00 2001 From: Konrad Date: Tue, 26 Dec 2023 18:54:53 +0100 Subject: [PATCH 1/2] Update ERC-4337: Fix typos Merged by EIP-Bot. --- ERCS/erc-4337.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-4337.md b/ERCS/erc-4337.md index 8ea4afe97b2..d5aea7dc64d 100644 --- a/ERCS/erc-4337.md +++ b/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 From 82ee377caa7f75e28886f39ba5b0ed3bcfd6fa7d Mon Sep 17 00:00:00 2001 From: Zergity <37166829+Zergity@users.noreply.github.com> Date: Wed, 27 Dec 2023 11:30:57 +0700 Subject: [PATCH 2/2] Update ERC-6120: update ERC-6120 Merged by EIP-Bot. --- ERCS/erc-6120.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-6120.md b/ERCS/erc-6120.md index be248da2265..7161c151c90 100644 --- a/ERCS/erc-6120.md +++ b/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.