EIP-8130 Account Configuration

Appearance

EIP-8130Account Configuration

Research and implementation tracking for a draft native account-abstraction proposal. Canonical authenticators, portable account configuration, and bounded validation.

Read the Overview
Try the Demo

Declarative Validation

Nodes select known authenticators by address instead of running the sender account's code

Cross-Chain Accounts

One chain_id 0 signature can be relayed to each deployment; synchronization is not automatic

Predictable Mempool Safety

Canonical authenticator identity narrows the code and state a node must validate

Scheme Agility

Contracts deploy freely; direct AA use requires coordinated canonical-set adoption

Account Lock

Freeze actor configuration to unlock higher mempool rate limits for stable accounts

Gas Sponsorship

payer and payer_auth fields cover third-party gas. No bundlers or relayers needed

What to read first? ​

Pick the route that matches why you're here.

How does it work? ​

Every EIP-8130 account is governed by the Keystore at KEYSTORE_ADDRESS, which stores actor and account state and delegates credential checks to an authenticator contract:

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

A node accepts a transaction by checking the declared authenticator against a canonical allowlist and calling it via STATICCALL, rather than executing sender-account code. K1_AUTHENTICATOR runs native ecrecover. Account-aware validateSignature then uses typed local or multichain envelopes and an account- and chain-scoped digest.

Each actor carries a uint16 scope grant mask rather than one all-or-nothing permission:

GrantValueMeaning
SENDER0x01Ungated call initiation
POLICY0x02Call initiation gated to a designated policy manager
NONCE0x04Permission to use non-nonceless nonce channels
SELF_PAYER0x08Pay gas for the account's own transactions
SPONSOR_PAYER0x10Pay gas on behalf of a different sender

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,
  valid_after, valid_before,
  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 ​

payerpayer_authWho paysRequired grant
emptyemptysenderAdmin or SELF_PAYER on the sender's resolved actor
sender's own addresssetsenderAdmin or SELF_PAYER on a dedicated gas key funding a sibling key
a different addresssetthe payer fieldAdmin or SPONSOR_PAYER on the payer's resolved actor

No bundler or EntryPoint contract is required on the native path. See Current Spec for validity windows, local epochs, multichain changes, nonces, Account Lock, and account creation.