Skip to content

EIP-7701

Native Account Abstraction on Ethereum Layer 1 using role-based validation and AA transaction types.

EIP-7701 proposes native Account Abstraction (AA) on Ethereum Layer 1. It introduces a new role-based validation model and a new transaction type (AA_TX_TYPE) that allows EOAs to delegate validation to smart contracts. This enables smart account behavior directly at the protocol level, without relying on external EntryPoints or simulation frameworks.

This proposal is Ethereum L1’s counterpart to RIP-7560, which enables native AA on rollups. EIP-7701 aims to make smart accounts a first-class protocol feature on Ethereum mainnet.

🧠 Core Idea

Instead of every transaction being tied to a fixed ECDSA signature, EIP-7701 introduces role-based validation:

  • Transactions of a new type (AA_TX_TYPE, per EIP-2718) specify which contract(s) are responsible for validation
  • EOAs can delegate their validation logic to a validator contract, enabling features like multisig, passkeys, and recovery
  • A new opcode, ACCEPTROLE, allows validators to declare approval of a transaction’s role

🧩 Key Mechanics

  • New Transaction Type (AA_TX_TYPE)
    AA transactions are EIP-2718 typed transactions. They declare roles and delegate validation.

  • Role-Based Access
    The transaction includes a new roles field (distinct from EIP-2930’s accessList), mapping roles to validator contracts.

  • Validator Contracts
    Can implement arbitrary logic (e.g., passkey verification, guardian schemes) and must explicitly accept roles via ACCEPTROLE.

  • EVM-Level Changes
    Ethereum adds a new opcode and protocol-level changes to process these transactions without an external EntryPoint.

🧱 Mempool Architecture

EIP-7701 assumes the need for a separate mempool for typed AA transactions:

  • Traditional mempool: contains legacy Ethereum transactions
  • AA mempool: contains AA transactions (typed as AA_TX_TYPE)

Both transaction types are valid and can coexist in the same block. Over time, block builders are expected to adopt support for both pipelines.

Builders that incorporate AA validation logic (which previously required bundlers in ERC-4337) will have access to a broader range of transactions and may gain competitive advantage in block space markets.

🚀 Benefits

  • Native AA Support on L1
    Makes smart accounts protocol-native, removing reliance on EntryPoint contracts and reducing overhead.

  • Better UX & Flexibility
    Enables wallets to support recovery, multisig, biometrics, etc., directly in protocol-compatible ways.

  • Efficient and Future-Proof
    Unifies AA logic under one opcode and transaction format, aligning with EIP-2718 extensibility.

  • Encourages Bundler–Builder Unification
    Over time, block builders are expected to handle both AA and traditional transaction validation.

🔄 Relationship to Other Standards

  • RIP-7560 - EIP-7701 shares the same role-based validation model, but applies it to Ethereum L1 instead of L2 rollups.

  • ERC-4337 - Removes the need for external EntryPoints and UserOperations. However, the AA mempool persists and bundler-style logic is now run by block builders. Concepts from 4337 like Paymasters, session keys, and plugin-based accounts remain highly relevant.

  • ERC-6900 / ERC-7579 - Can be used to define modular validator contracts and authorization schemes compatible with this standard.

📚 Further Reading

✅ Summary

EIP-7701 brings Account Abstraction to Ethereum Layer 1 with a native, role-based transaction model. It introduces AA transactions (via AA_TX_TYPE) that let EOAs delegate signature validation to smart contracts. These AA transactions are stored in a dedicated mempool and validated natively by block builders. Over time, this allows Ethereum to support smart wallets and new UX primitives directly at the protocol level — efficiently, securely, and without requiring simulation or coordination across custom infrastructure.