EIP-7701 is a proposed Ethereum core protocol upgrade that adds native account abstraction at the protocol layer using the EVM Object Format (EOF). Authored by Vitalik Buterin, Yoav Weiss, Alex Forshtat, Dror Tirosh, and Shahaf Nacson and first posted to Ethereum Magicians in May 2024, it introduces a dedicated transaction type (AA_TX_TYPE) and a fixed entry-point address at 0x7701 that the protocol itself enforces. Unlike ERC-4337, which implements account abstraction as a userspace layer on top of the existing protocol, EIP-7701 bakes validation logic, nonce management, and paymaster support directly into Ethereum's consensus rules, removing the need for a separately deployed EntryPoint contract.
​

EIP-7701 is an Ethereum Improvement Proposal that adds native account abstraction to the protocol using EOF-formatted contract code. It introduces a new transaction type, five structured execution phases, two new opcodes (CURRENT_ROLE and ACCEPT_ROLE), and a fixed on-protocol entry point at address(0x7701), enabling smart accounts to define custom validation without any separate singleton contract.
​

The EIP was created on May 1, 2024 and currently holds "Stagnant" status under Ethereum's EIP process, meaning it has not been assigned to an upcoming hard fork but remains in active technical discussion. The proposal builds on the EVM Object Format (EIP-3540), which introduces versioned, structured bytecode containers with separate type sections, code sections, and data sections validated at deploy time rather than at execution time. EIP-7701 adds a new EOF section type specifically for account validation logic, called the "validator section," which the protocol reads during the AA transaction lifecycle.
​

The core motivation is direct. ERC-4337 achieves account abstraction without protocol changes, but at a cost. Every ERC-4337 UserOperation pays overhead for the EntryPoint contract's verification and execution loops, and bundlers must operate separate mempool infrastructure outside the standard transaction flow. EIP-7701 moves those mechanics into the protocol itself, eliminating the bundler as a distinct actor and making smart account validation a first-class transaction property, as native as signatures and nonces. The name of the entry point address, 0x7701, is a deliberate reference to the EIP number itself, a mnemonic for the protocol-level constant.
​

From a developer perspective, EIP-7701 changes the mental model for account abstraction. In ERC-4337, a developer must understand the EntryPoint contract's ABI, the UserOperation struct, bundler policies, and paymaster deposit flows before writing a single line of wallet validation logic. In EIP-7701, validation is a code section in an EOF contract, and gas sponsorship is a phase with its own opcode. The infrastructure collapses into the protocol layer, and the developer interface becomes the EVM itself.
​

EIP-7701 works by splitting an AA transaction into five sequential phases, each with its own gas budget and role identifier. The protocol runs sender deployment, sender validation, optional paymaster validation, sender execution, and optional paymaster post-operation cleanup in order. Two new opcodes let validator code confirm its role and accept or reject the transaction at the protocol level.
​

The five roles are assigned fixed hex identifiers: sender deployment (0xA0), sender validation (0xA1), paymaster validation (0xA2), sender execution (0xA3), and paymaster post-operation (0xA4). Each phase runs inside the protocol's AA entry point at address(0x7701) with separate gas limits drawn from the transaction's total pre-deducted gas budget. Gas is pre-deducted in full at submission, computed across all phase maxima multiplied by max_fee_per_gas, and refunded after execution based on actual consumption per phase. The cold-address access costs for paymasters and deployers are 2,400 gas each if non-zero and previously unaccessed, matching the standard EIP-2929 cold-read cost.
​

The EIP-7701 specification introduces two opcodes that gate validation logic. CURRENT_ROLE returns the active phase identifier (0xA0 through 0xA4) so that validator code can confirm it is executing in the correct context. ACCEPT_ROLE functions like RETURN but additionally verifies that the current frame's role matches the expected role for that phase. If a validation frame completes without executing the correct ACCEPT_ROLE, the transaction fails at the protocol level rather than reverting on a revert opcode.
​

This design prevents a class of bugs where validator code accidentally authorizes transactions outside its intended phase. CURRENT_ROLE remains constant during a DELEGATECALL but resets to sender execution mode on a CALL, STATICCALL, or CALLCODE. This means validators implemented via DELEGATECALL inherit the calling frame's role, which matters when factories or shared validation libraries are deployed using delegation patterns. The EIP-7701 specification flags that block explorers should annotate accounts and paymasters that expose ACCEPT_ROLE in their bytecode, because "correct and secure implementation of this code is critical" given the opcode's broad authorization scope.
​

EIP-7701 requires that smart accounts participating in AA transactions be deployed as EOF-formatted contracts. EOF containers structure bytecode into typed sections: type metadata describing stack requirements and input/output counts, one or more code sections (up to 1,024), optional container sections for nested EOF, and a data section. The EIP-7701 validator section is an additional section type the protocol reads during the sender validation phase and invokes directly, without a function selector.
​

This differs meaningfully from ERC-4337's validation model. In ERC-4337, the EntryPoint calls the account's validateUserOp function by ABI selector. The account returns a packed integer the EntryPoint interprets for signature validity and time range. In EIP-7701, the EOF validator section is a structured bytecode segment with a defined role, and ACCEPT_ROLE signals acceptance directly to the protocol. There is no return value to decode, no function selector to match, and no EntryPoint contract to call. The protocol and the account bytecode communicate through opcodes, not ABI encoding.
​

EIP-7701 introduces TXPARAMDLOAD, TXPARAMSIZE, and TXPARAMCOPY opcodes, which give validator sections access to 19 defined transaction parameters indexed 0x00 through 0x12, plus two execution-state fields and a signature hash at 0xFF. These opcodes work like their CALLDATA equivalents but read AA transaction fields rather than calldata. During the sender validation phase (0xA1), CALLDATA is empty. Sender execution data is passed only in phase 0xA3. Validators must therefore use TXPARAM opcodes, not CALLDATALOAD, to inspect fields such as nonce, sender, paymaster address, or gas limits. The 19 accessible parameters cover the complete AA transaction payload, giving validators full read access to transaction context without any encoding workarounds.
​

EIP-7701 moves account abstraction into the Ethereum protocol itself, while ERC-4337 implements it in userspace via a singleton EntryPoint contract. The practical differences span architecture, gas cost, mempool requirements, tooling dependencies, and bundler economics. The table below compares all three major AA primitives across seven dimensions.
​

The most significant practical difference is the bundler requirement. ERC-4337 UserOperations travel through a separate alt mempool and are assembled into standard Ethereum transactions by bundlers, which submit them via handleOps on the EntryPoint contract. As of April 2026, BundleBear reports over 1.07 billion UserOperations processed and 56.8 million accounts active across 12 chains including Base, Polygon, Arbitrum, Optimism, and Ethereum mainnet. EIP-7701 transactions enter the standard mempool directly and are included by validators like any other Ethereum transaction type, removing the bundler layer and its associated costs.
​

A second distinction is upgradeability and auditability. ERC-4337 v0.7 uses the EntryPoint at 0x0000000071727De22E5E9d8BAf0edAc6f37da032; v0.9 uses 0x433709009B8330FDa32311DF1C2AFA402eD8D009. Both are deployed smart contracts with their own audit histories and potential upgrade paths. In EIP-7701, address(0x7701) is not a deployed contract but a protocol-native constant. There is nothing to upgrade, re-audit, or redeploy at the infrastructure layer; correctness is enforced by the consensus rules of the node software, not a contract's logic.
​

A third distinction is mempool censorship resistance. Because ERC-4337 UserOperations require bundlers to include them, accounts can be censored at the bundler layer even if the underlying Ethereum mempool is permissionless. EIP-7701 AA transactions compete in the standard mempool alongside regular transactions. Any validator that includes a block can include an EIP-7701 AA transaction, which aligns inclusion economics with the same dynamics as standard Ethereum transactions.
​

EIP-7702 and EIP-7701 solve adjacent problems on different timelines. EIP-7702, activated in the Pectra hard fork in 2025, lets EOAs set their code field to a delegation pointer, enabling smart account behavior without deploying a new contract. EIP-7701 goes further by adding protocol-level validation phases that work for newly deployed smart accounts and, eventually, EIP-7702-delegated EOAs using EOF bytecode.
​

The EIP-7701 specification explicitly notes compatibility with EIP-7702. Existing ERC-4337 wallet code that is compatible with EIP-7702 delegations can serve as a migration target. An EOA that delegates to a validated EOF contract via EIP-7702 today can, in theory, transition to a native EIP-7701 AA account once the standard activates, without changing its address or losing its transaction history. The address stays the same; the underlying validation mechanics change from delegation to protocol-native phases.
​

The sequencing matters for production decisions. EIP-7702 is live and deployable now. EIP-7701 requires a hard fork that has not yet been scheduled. Developers building smart account infrastructure in 2025 and 2026 can design for EIP-7702 compatibility first and add EOF validator section support when EIP-7701 activates, because the two are explicitly forward-compatible. Yoav Weiss, one of EIP-7701's five co-authors, has outlined this as the intended migration path in public forum discussions, describing EIP-7702 as the bridge between legacy EOA behavior and native account abstraction.
​

One nuance is that EIP-7702 delegations point to existing contract code, which can be legacy bytecode or EOF. EIP-7701 validator sections require EOF. An EOA delegating via EIP-7702 to a legacy contract cannot directly participate in EIP-7701's validation model. The path forward for those accounts requires redeployment of the delegated contract as an EOF binary with a validator section, then a new EIP-7702 delegation update pointing to the EOF version.
​

EIP-7701 reduces gas overhead, removes the alt-mempool requirement, and eliminates EntryPoint contract dependencies for account abstraction. The tradeoffs are real: it requires the EOF upgrade, a hard fork, and new tooling across compilers, block explorers, and security auditing pipelines. The Stagnant status means the benefits are not yet realizable in production.
​

Gas reduction comes from eliminating the EntryPoint contract's execution overhead. In ERC-4337, every UserOperation pays for the EntryPoint's verification loop, bundling computation, and the handleOps call, on top of the account's own validation logic. EIP-7701 phases run directly in the protocol without an intermediary contract layer. The base gas cost for an AA transaction type is specified as 15,000 gas in the EIP-7701 draft, comparable to a standard Ethereum transaction's 21,000 gas base, rather than the higher floor of ERC-4337 UserOperations which incur EntryPoint overhead before any validation logic runs.
​

Security also improves in one important dimension. The protocol enforces phase boundaries mechanically. A validator that fails to execute the correct ACCEPT_ROLE fails the transaction at the consensus level. This removes a category of EntryPoint misuse where malformed calls to the EntryPoint can drain account deposits or bypass validation in edge cases. The EIP-7701 specification acknowledges the risk from the other direction, noting that ACCEPT_ROLE's broad authorization scope means "correct and secure implementation of this code is critical" and that compiler support for the new opcodes is essential before validator sections can be written safely.
​

Inclusion competition broadens with native AA. Any Ethereum validator that builds a block can include EIP-7701 AA transactions. This eliminates the structural dependence on a small set of active bundler operators, which in ERC-4337 creates a latent centralization point even though the design is permissionless. Native AA transactions compete on gas price like all other transactions, removing a layer of discretionary filtering.
​

Deployment status is the primary constraint. EIP-7701 is Stagnant as of April 2026. The EOF upgrade spanning EIP-3540, EIP-3670, and related proposals has faced repeated scheduling delays and also holds Stagnant status. EIP-7701's validator section cannot ship without EOF, making EIP-7701 contingent on a prerequisite that has not cleared the Ethereum governance process. Any developer building AA infrastructure for production use should plan around ERC-4337 and EIP-7702, not EIP-7701.
​

Tooling requirements are substantial. Solidity and Vyper compilers, Hardhat and Foundry debuggers, block explorers like Etherscan, and audit frameworks all need to support EOF containers and the ACCEPT_ROLE and CURRENT_ROLE opcodes before smart account developers can write and audit validator sections with confidence. These tools exist in prototype form but are not production-ready at the time of writing. The EIP-7701 specification explicitly notes that block explorers should annotate accounts and paymasters that expose ACCEPT_ROLE to help auditors identify validator sections in deployed code.
​

Storage access during validation is also more restricted than in ERC-4337. During phases 0xA1 (sender validation) and 0xA2 (paymaster validation), storage access is constrained to prevent front-running and denial-of-service attacks against the mempool, since validators cannot know in advance whether a transaction's validation will succeed under changing state. Accounts that rely on external storage reads during validation, such as oracle-based signature validators or social-recovery contracts that check guardian votes onchain, need to restructure their logic to work within the EIP-7701 access rules.
​

EIP-7701 represents the intended long-term destination for Ethereum account abstraction: a model where validation logic, nonce handling, and gas sponsorship are protocol primitives rather than application-layer workarounds. The current roadmap operates ERC-4337 and EIP-7702 as production solutions, with EIP-7701 as the eventual convergence point once EOF activates.
​

The Ethereum community describes this as a three-phase progression. ERC-4337 is phase one: live, widely deployed, handling 1.07 billion UserOperations across 56.8 million accounts on 12 chains as of April 2026. EIP-7702 is phase two: activated in the Pectra hard fork, it lets EOAs delegate to contract code without changing their address, giving smart account behavior to existing wallets. EIP-7701 is phase three: it rewrites the validation model at the protocol level, removing all application-layer AA infrastructure in favor of consensus-enforced phase execution and EOF validator sections.
​

The forward-compatibility design means that building for ERC-4337 and EIP-7702 today does not create dead-end code. The EIP-7701 specification is constructed so that ERC-4337 accounts compatible with EIP-7702 delegations can serve as migration targets for EIP-7701 once it activates. Wallet infrastructure, paymaster contracts, and bundler tooling written to current standards can migrate incrementally. The address an account holds across ERC-4337, EIP-7702, and EIP-7701 stays the same. The underlying validation path changes as each upgrade activates.
​

For developers tracking the timeline: as of April 2026, the Ethereum core dev community has not published a roadmap that schedules EOF or EIP-7701 for a specific upcoming hard fork. The Pectra upgrade (March 2025) shipped EIP-7702 but not EOF. The next major upgrade being discussed publicly, tentatively labeled Osaka/Fusaka, may include some EOF components, but no final scope has been confirmed. Developers should monitor the Ethereum Magicians forum and the execution-specs repository for scheduling updates.
​

Eco supports smart account infrastructure across 15 chains including Ethereum, Base, Arbitrum, Optimism, Polygon, and Solana. As Ethereum's account abstraction primitives evolve from ERC-4337 through EIP-7702 toward EIP-7701, Eco Routes handles cross-chain routing and settlement so that developers building on these standards do not need to rewrite routing logic for each protocol upgrade.
​

EIP-7701 uses address(0x7701) as its protocol-native entry point. This is not a deployed smart contract but a consensus-level handler enforced by Ethereum node software. It differs from ERC-4337's EntryPoint, which is a deployable singleton contract at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (v0.7) or 0x433709009B8330FDa32311DF1C2AFA402eD8D009 (v0.9).
​

Yes. EIP-7701 validator sections are an EOF-specific construct. Accounts that participate in AA transactions under EIP-7701 must deploy as EOF-formatted contracts with a validator section. Legacy bytecode contracts cannot include validator sections, meaning EIP-7701 is unavailable until both the EOF upgrade and the EIP-7701 hard fork activate on the target network.
​

EIP-7701 is designed with forward compatibility for ERC-4337 accounts. The specification notes that existing ERC-4337 wallet code compatible with EIP-7702 delegations can serve as migration targets. Developers building ERC-4337 accounts today do not need to scrap their work; the migration path is incremental once EIP-7701 activates.
​

The EIP-7701 specification defines a base gas cost of 15,000 gas for the new AA transaction type. The total gas consumed across all five execution phases (sender deployment, sender validation, paymaster validation, sender execution, paymaster post-op) is pre-deducted at submission and refunded per phase based on actual usage, with a 2,400 gas cold-access charge for non-zero paymaster and deployer addresses.
​

No. EIP-7701 holds Stagnant status as of April 2026 and has not been assigned to a scheduled Ethereum hard fork. The EOF upgrade it depends on is also Stagnant. For production smart account deployments, use ERC-4337 and EIP-7702. Monitor EIP-7701 progress via the Ethereum Magicians forum and the execution-specs repository.
​

Sources and methodology. EIP-7701 specification pulled from eips.ethereum.org on April 30, 2026. ERC-4337 adoption figures (1.07B UserOperations, 56.8M accounts) from BundleBear, April 2026. EIP-7702 activation status verified against Ethereum Pectra hard fork records. EOF specification pulled from EIP-3540. ERC-4337 EntryPoint addresses verified against the eth-infinitism account-abstraction repository release notes. Figures reflect state as of April 30, 2026.
​