From f30c7b696ae735fa437cb2297236ba10838d87f3 Mon Sep 17 00:00:00 2001 From: Nicolas Consigny <101647594+nconsigny@users.noreply.github.com> Date: Sat, 12 Jul 2025 17:32:04 +0200 Subject: [PATCH 1/3] add addresses and Calibur Added uniswap and addresses --- public/content/roadmap/pectra/7702/index.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/public/content/roadmap/pectra/7702/index.md b/public/content/roadmap/pectra/7702/index.md index f6d04c7601e9..ff2187920bb1 100644 --- a/public/content/roadmap/pectra/7702/index.md +++ b/public/content/roadmap/pectra/7702/index.md @@ -114,11 +114,14 @@ When users perform delegated signatures, the target contract receiving the deleg Due to the nature of EIP 7702, it is recommended wallets use caution when helping users delegate to a 3rd party contract. Listed below is a collection of known implementations that have been audited: -- address TBD [[alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)] / [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) -- address TBD [[AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol)] / [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) -- address TBD [[MetaMask/delegation-framework]](https://github.com/MetaMask/delegation-framework) / [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) +- 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 [[Uniswap/calibur](https://github.com/Uniswap/calibur)] / [audits](https://github.com/Uniswap/calibur/tree/main/audits) +- 0x69007702764179f14F51cdce752f4f775d74E139 [[alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)] / [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) +- 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d [[AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol)] / [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) +- 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b [[MetaMask/delegation-framework]](https://github.com/MetaMask/delegation-framework) / [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) - 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 [[Ethereum Foundation AA team]](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) / [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) + + ## Hardware wallet guidelines {#hardware-wallet-guidelines} Hardware wallets shouldn't expose arbitrary delegation. The consensus in the Hardware wallet space is to use a list of trusted delegator contracts. We suggest to allow known implementations listed above and to consider others on a case by case basis. As delegating your EOA to a contract gives control over all the assets, hardware wallets should be cautious with the way they implement 7702. From d7b3f6922e4defecaa82006084d359bf35d8d5db Mon Sep 17 00:00:00 2001 From: wackerow <54227730+wackerow@users.noreply.github.com> Date: Tue, 15 Jul 2025 16:26:55 -0700 Subject: [PATCH 2/3] chore: remove whitespace --- public/content/roadmap/pectra/7702/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/public/content/roadmap/pectra/7702/index.md b/public/content/roadmap/pectra/7702/index.md index ff2187920bb1..70f4a39268d2 100644 --- a/public/content/roadmap/pectra/7702/index.md +++ b/public/content/roadmap/pectra/7702/index.md @@ -120,8 +120,6 @@ Due to the nature of EIP 7702, it is recommended wallets use caution when helpin - 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b [[MetaMask/delegation-framework]](https://github.com/MetaMask/delegation-framework) / [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) - 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 [[Ethereum Foundation AA team]](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) / [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) - - ## Hardware wallet guidelines {#hardware-wallet-guidelines} Hardware wallets shouldn't expose arbitrary delegation. The consensus in the Hardware wallet space is to use a list of trusted delegator contracts. We suggest to allow known implementations listed above and to consider others on a case by case basis. As delegating your EOA to a contract gives control over all the assets, hardware wallets should be cautious with the way they implement 7702. From c371c066cbfbe60d988090c562241697049e6b41 Mon Sep 17 00:00:00 2001 From: Paul Wackerow <54227730+wackerow@users.noreply.github.com> Date: Tue, 15 Jul 2025 16:34:22 -0700 Subject: [PATCH 3/3] refactor: use markdown table --- public/content/roadmap/pectra/7702/index.md | 40 ++++++++++----------- 1 file changed, 18 insertions(+), 22 deletions(-) diff --git a/public/content/roadmap/pectra/7702/index.md b/public/content/roadmap/pectra/7702/index.md index 70f4a39268d2..d2da80649c87 100644 --- a/public/content/roadmap/pectra/7702/index.md +++ b/public/content/roadmap/pectra/7702/index.md @@ -4,7 +4,7 @@ description: Learn more about 7702 in the Pectra release lang: en --- -# Pectra 7702 +# Pectra 7702 ## Abstract {#abstract} @@ -16,7 +16,7 @@ This new transaction type introduces an authorization list. Each authorization t [ chain_id, address, nonce, y_parity, r, s ] ``` -**address** is the delegation (already deployed bytecode that'll be used by the EOA) +**address** is the delegation (already deployed bytecode that'll be used by the EOA) **chain_id** locks the authorization to a specific chain (or 0 for all chains) **nonce** locks the authorization to a specific account nonce (**y_parity, r, s**) is the signature of the authorization tuple, defined as keccak(0x05 || rlp ([chain_id ,address, nonce])) by the private key of EOA to which the authorization applies (also called the authority) @@ -29,7 +29,8 @@ The private key of the EOA retains full control over the account after the deleg **Account Abstraction**: A delegation contract should align with Ethereum’s broader account abstraction (AA) standards to maximize compatibility. In particular, it should ideally be ERC-4337 compliant or compatible. -**Permissionless and Censorship-Resistant Design**: Ethereum values permissionless participation. A delegation contract MUST NOT hard-code or rely on any single “trusted” relayer or service. This would brick the account if the relayer goes offline. Features like batching (e.g. approve+transferFrom) can by used by the EOA itself without a relayer. For application developers that want to use advanced features enabled by 7702 (Gas Abstraction, Privacy-Preserving Withdrawals) you’ll need a relayer. While there are different relayer architectures, our recommendation is to use [4337 bundlers](https://www.erc4337.io/bundlers) pointing at least [entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) because: +**Permissionless and Censorship-Resistant Design**: Ethereum values permissionless participation. A delegation contract MUST NOT hard-code or rely on any single “trusted” relayer or service. This would brick the account if the relayer goes offline. Features like batching (e.g. approve+transferFrom) can by used by the EOA itself without a relayer. For application developers that want to use advanced features enabled by 7702 (Gas Abstraction, Privacy-Preserving Withdrawals) you’ll need a relayer. While there are different relayer architectures, our recommendation is to use [4337 bundlers](https://www.erc4337.io/bundlers) pointing at least [entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) because: + - They provide standardized interfaces for relaying - Include built-in paymaster systems - Ensure forward compatibility @@ -51,11 +52,11 @@ By utilizing these interfaces, dApps can access smart account functionalities pr > Note: There is no standardized method for dApps to request 7702 authorization signatures directly. DApps must rely on specific wallet interfaces like ERC-6900 to take advantage of EIP-7702 features. For more information: + - [ERC-5792 specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) - [ERC-6900 specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) - -**Avoiding Vendor Lock-In**: In line with the above, a good implementation is vendor-neutral and interoperable. This often means adhering to emerging standards for smart accounts. For instance, [Alchemy’s Modular Account](https://github.com/alchemyplatform/modular-account) uses the ERC-6900 standard for modular smart accounts and is designed with “permissionless interoperable usage” in mind. +**Avoiding Vendor Lock-In**: In line with the above, a good implementation is vendor-neutral and interoperable. This often means adhering to emerging standards for smart accounts. For instance, [Alchemy’s Modular Account](https://github.com/alchemyplatform/modular-account) uses the ERC-6900 standard for modular smart accounts and is designed with “permissionless interoperable usage” in mind. **Privacy Preservation**: While onchain privacy is limited, a delegation contract should strive to minimize data exposure and linkability. This can be achieved by supporting features like gas payments in ERC-20 tokens (so users need not maintain a public ETH balance, which improves privacy and UX) and one-time session keys (which reduce reliance on a single long-term key). For example, EIP-7702 enables paying gas in tokens via sponsored transactions, and a good implementation will make it easy to integrate such paymasters without leaking more information than necessary. Additionally, off-chain delegation of certain approvals (using signatures that are verified onchain) means fewer onchain transactions with the user’s primary key, aiding privacy. Accounts that require using a relayer force users to reveal their IP addresses. PublicMempools improves this, when a transaction/UserOp propagates through the mempool you can't tell whether it originated from the IP that sent it, or just relayed through it via the p2p protocol. @@ -69,19 +70,17 @@ Benefits of the Proxy Pattern: For instance, the [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) demonstrates how a proxy can be utilized to securely initialize and manage delegations in EIP-7702-compatible accounts. -Cons of the Proxy Pattern: - -- **Reliance on external actors**: You have to rely on an external team to not upgrade to an unsafe contract. +Cons of the Proxy Pattern: +- **Reliance on external actors**: You have to rely on an external team to not upgrade to an unsafe contract. ## Security Considerations {#security-considerations} - **Reentrancy guard**: With the introduction of EIP-7702 delegation, a user’s account can dynamically switch between an Externally Owned Account (EOA) and a Smart Contract (SC). This flexibility enables the account to both initiate transactions and be the target of calls. As a result, scenarios where an account calls itself and makes external calls will have `msg.sender` equal to `tx.origin`, which undermines certain security assumptions that previously relied on `tx.origin` always being an EOA. For smart contract developers, it's no longer safe to assume that `tx.origin` refers to an EOA. Likewise, using `msg.sender == tx.origin` as a safeguard against reentrancy attacks is no longer a reliable strategy. -Going forward, developers should design with the assumption that any participant in the system could be a smart contract. Alternatively they could implement explicit reentrancy protection using reentrancy guards with a `nonReentrant` modifier patterns. We recommend following an audited modifier e.g [Open Zeppelin's Reentrancy Guard](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). They could also use a [transient storage variable](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). +Going forward, developers should design with the assumption that any participant in the system could be a smart contract. Alternatively they could implement explicit reentrancy protection using reentrancy guards with a `nonReentrant` modifier patterns. We recommend following an audited modifier e.g [Open Zeppelin's Reentrancy Guard](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). They could also use a [transient storage variable](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). **Initialization Security Considerations** @@ -100,30 +99,29 @@ This risk is especially pertinent when attempting to use existing Smart Contract By adopting these solutions, developers can enhance the security of EIP-7702 delegation contracts, safeguarding against potential frontrunning attacks during the initialization phase. - **Storage Collisions** Delegating code does not clear existing storage. When migrating from one delegation contract to another, the residual data from the previous contract remains. If the new contract utilizes the same storage slots but interprets them differently, it can cause unintended behavior. For instance, if the initial delegation was to a contract where a storage slot represents a `bool`, and the subsequent delegation is to a contract where the same slot represents a `uint`, the mismatch can lead to unpredictable outcomes. - **Phishing risks** With the implementation of EIP-7702 delegation, the assets in a user's account may be entirely controlled by smart contracts. If a user unknowingly delegates their account to a malicious contract, an attacker could easily gain control and steal funds. When using `chain_id=0` the delegation is applied to all chain ids. Only delegate to an immutable contract (never delegate to a proxy), and only to contracts that were deployed using CREATE2 (with standard initcode - no metamorphic contracts) so the deployer can't deploy something different to the same address elsewhere. Otherwise your delegation puts your account at risk on all other EVM chains. When users perform delegated signatures, the target contract receiving the delegation should be clearly and prominently displayed to help mitigate phishing risks. -**Minimal Trusted Surface & Security**: While offering flexibility, a delegation contract should keep its core logic minimal and auditable. The contract is effectively an extension of the user’s EOA, so any flaw can be catastrophic. Implementations should follow best practices from the smart contract security community. For instance, constructor or initializer functions must be carefully secured – as highlighted by Alchemy, if using a proxy pattern under 7702, an unprotected initializer could let an attacker take over the account. Teams should aim to keep the onchain code simple: Ambire’s 7702 contract is only ~200 lines of Solidity, deliberately minimizing complexity to reduce bugs. A balance must be struck between feature-rich logic and the simplicity that eases auditing. +**Minimal Trusted Surface & Security**: While offering flexibility, a delegation contract should keep its core logic minimal and auditable. The contract is effectively an extension of the user’s EOA, so any flaw can be catastrophic. Implementations should follow best practices from the smart contract security community. For instance, constructor or initializer functions must be carefully secured – as highlighted by Alchemy, if using a proxy pattern under 7702, an unprotected initializer could let an attacker take over the account. Teams should aim to keep the onchain code simple: Ambire’s 7702 contract is only ~200 lines of Solidity, deliberately minimizing complexity to reduce bugs. A balance must be struck between feature-rich logic and the simplicity that eases auditing. ### Known implementations {#known-implementations} Due to the nature of EIP 7702, it is recommended wallets use caution when helping users delegate to a 3rd party contract. Listed below is a collection of known implementations that have been audited: -- 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 [[Uniswap/calibur](https://github.com/Uniswap/calibur)] / [audits](https://github.com/Uniswap/calibur/tree/main/audits) -- 0x69007702764179f14F51cdce752f4f775d74E139 [[alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)] / [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) -- 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d [[AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol)] / [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) -- 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b [[MetaMask/delegation-framework]](https://github.com/MetaMask/delegation-framework) / [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) -- 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 [[Ethereum Foundation AA team]](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) / [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) +| Contract address | Source | Audits | +| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [audits](https://github.com/Uniswap/calibur/tree/main/audits) | +| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | +| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | +| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) | +| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Ethereum Foundation AA team](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | ## Hardware wallet guidelines {#hardware-wallet-guidelines} -Hardware wallets shouldn't expose arbitrary delegation. The consensus in the Hardware wallet space is to use a list of trusted delegator contracts. We suggest to allow known implementations listed above and to consider others on a case by case basis. As delegating your EOA to a contract gives control over all the assets, hardware wallets should be cautious with the way they implement 7702. - +Hardware wallets shouldn't expose arbitrary delegation. The consensus in the Hardware wallet space is to use a list of trusted delegator contracts. We suggest to allow known implementations listed above and to consider others on a case by case basis. As delegating your EOA to a contract gives control over all the assets, hardware wallets should be cautious with the way they implement 7702. ### Integration scenarios for companion apps {#integration-scenarios-for-companion-apps} @@ -148,5 +146,3 @@ EOAs delegated to a different one will be handled as standard EOAs. Hardware provider implements its own delegation contract and adds it to the lists implements its support in softaware companion. It is recommended to build a contract with full ERC 4337 support. EOAs delegated to a different one will be handled as standard EOAs. - -