Abstract

EIP-7702, finalized and activated on Ethereum mainnet as part of the Pectra hard fork in early 2025, introduced a new transaction type that allows an externally owned account (EOA) to temporarily delegate its code execution to a smart contract for the duration of a transaction. Unlike EIP-4337, which routes transactions through an off-chain bundler network and an on-chain EntryPoint contract, EIP-7702 works at the protocol layer: the EOA’s address appears to execute contract logic without being converted to a contract account permanently. This has significant implications for key management, session key architectures, and the interaction between on-chain authorization and cryptographic key hierarchy design. This post examines what EIP-7702 makes possible, the security considerations specific to delegation, and how wallet developers are building on it.

How the Delegation Mechanism Works

EIP-7702 defines transaction type 0x04. In the transaction, the sender signs an authorization list containing one or more tuples of (chain_id, address, nonce). Each tuple designates a contract whose code should be loaded into the sender’s address for that transaction. The EVM loads the bytecode from the designated contract and executes it as if it resided at the EOA’s address. Storage reads and writes operate on the EOA’s storage namespace, not the contract’s. At the end of the transaction, the delegation is reset unless the contract itself writes a persistent delegation pointer to a well-known storage slot. This last detail is important: most EIP-7702 wallet implementations set a persistent delegation by writing during the first transaction, so subsequent transactions automatically execute through the delegated contract without re-sending the authorization list.

Session Keys and Bounded Capability Grants

The primary cryptographic use case enabled by EIP-7702 is session key authorization. A user can sign an EIP-7702 authorization that delegates execution to a contract implementing a session key policy: the policy specifies which additional signing keys are authorized, for which target contracts, with what value limits, and for what time window. Applications like games, DeFi position managers, and trading bots can then submit transactions signed by the session key without involving the root EOA private key. The session key signs transactions using the same ECDSA signing scheme as the EOA, but the on-chain contract validates that the session key signature matches an authorized key registered in the delegation contract’s storage. From a key hierarchy perspective, this is a form of capability delegation where the root key’s authority is scoped and time-limited, similar to X.509 certificate path constraints but enforced by smart contract logic rather than a PKI chain.

Security Considerations Specific to EIP-7702

Several security properties of EIP-7702 require careful attention. First, the authorization signature in the transaction type is over a tuple that includes the chain ID and nonce, preventing replay across chains and transactions. However, if a user signs an authorization for a malicious or buggy contract, the contract gains full control of the EOA’s assets for the transaction scope. Wallet UI that allows blind signing of type-0x04 transactions is a significant phishing vector. Second, the persistent delegation model means that a delegated address remains the effective code for the EOA until explicitly cleared. An attacker who induces a user to set a delegation to a backdoored contract retains persistent access. Third, EIP-7702 interacts non-obviously with EIP-4337’s EntryPoint: a 7702-delegated EOA can also function as a 4337 smart account, but the gas payment paths interact in ways that require explicit testing to avoid revert conditions.

Wallet Implementations as of April 2026

Coinbase Wallet, MetaMask’s smart wallet extension, and Safe’s native account product all added EIP-7702 support following Pectra activation. The dominant pattern is a “base account” contract per wallet vendor, audited and published, that EOA users delegate to on first use. Session key registration, guardian recovery, and gas sponsorship modules are built as composable layers on top of the base account. Ambire Wallet and Braavos (on Starknet’s analogous native account abstraction) have open-sourced their delegation contract implementations, providing reference material for teams building custom session key policies. The ERC-7715 standard (permissions API for session keys) is in draft and aims to define a common interface so dApps can request session key grants in a chain-agnostic way.