EIP-8130Account Configuration

What to read first? ​

Pick the route that matches why you're here.

• Just want the overview → Current Spec for the mechanism, then FAQ for common questions.
• Building a wallet or app → Developer Tooling for the adoption calculus, then Authenticator Model for how validation actually works.
• Following the discussion → Feedback Evolution for the phase-by-phase debate, Merged Changes for PR history, Original vs Latest for the diff.
• Comparing alternatives → Competing Standards for the comparative analysis, or jump straight to EIP-8141, EIP-8130's most direct competitor.
• Cross-chain wallets → Cross-Chain Accounts for how config changes replay across chains via chain_id 0.
• Mempool safety and statelessness → Mempool Safety for why validation never executes wallet code.
• Post-quantum readiness → PQ Scheme Agility for how new signature schemes join the canonical authenticator set.

How does it work? ​

Every EIP-8130 account is governed by a single system contract, the Account Configuration Contract, which stores one actor_config slot per registered actor and delegates signature checking to an authenticator contract:

interface IAuthenticator {
    function authenticate(bytes32 hash, bytes calldata data) external view returns (bytes32 actorId);
}

A node accepts a transaction into its mempool by checking the identity of the declared authenticator against a small canonical allowlist and calling it via STATICCALL, not by executing the account's own code to figure out whether the transaction is valid. K1_AUTHENTICATOR is the native secp256k1 case: the protocol runs ecrecover directly instead of a contract call, which is what lets any existing EOA send AA transactions immediately with zero prior registration.

Each actor carries a scope byte of grants rather than a single all-or-nothing permission:

scope == 0x00 is the admin predicate: unrestricted authority over config changes and delegation. There is no separate "config" grant, since any actor able to rewrite actor_config can already grant itself full access.

Transaction format (AA_TX_TYPE = 0x79) ​

AA_TX_TYPE || rlp([
  chain_id, sender, nonce_key, nonce_sequence, expiry,
  max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
  account_changes, calls, metadata,
  payer, sender_auth, payer_auth
])

calls is a two-level structure, phases of atomic calls that commit independently in sequence: if a call in a phase reverts, that phase rolls back and later phases are skipped, but already-completed phases persist. A common pattern is [[sponsor_payment], [user_action_a, user_action_b]], where the sponsor's payment phase survives even if the user's action phase later reverts.

Gas sponsorship ​

No bundler, no EntryPoint contract, no off-chain relayer. Validation, gas payment, and execution are all native protocol behavior. See Current Spec for the full mechanism, including nonces, Account Lock, and account creation and import.