Protocol

Overview

The moving parts of EIP-8130 at a high level: authentication (authenticators), authorization (Account Configuration), and stateful checks deferred to execution.

Big picture

EIP-8130 splits two jobs that other AA designs often fuse together:

Authentication (authn): proving who signed. That is the job of authenticators. The transaction names the authenticator; the node runs it and recovers an actorId.
Authorization (authz): deciding whether that actor may act, and in what role. That is the job of Account Configuration: one storage slot per actor (authenticator binding, scope, expiry, optional policy metadata).

There is usually a third kind of work mixed into validation as well: stateful conditional checks (balances against app rules, allowlists, spend limits, and so on). EIP-8130 moves those to execution, often behind policies. Clear separation of authentication, authorization, and stateful checks is what keeps validation fast, optimisable, and portable.

Accounts manage actor configs in the Account Configuration contract, which references canonical authenticators such as K1, P-256, Passkey, Delegate, and PQ. — Accounts manage actor configs in a shared Account Configuration contract. Each actor config references an authenticator used for authentication. On the native 8130 path, only the canonical set is admitted for transaction validation.

Transaction flow

An 8130 transaction names the authenticator in the auth blob. Nodes run that authenticator, load the actor config from Account Configuration (a single slot), and check authorization. Account Configuration is the shared authz layer: who may act for an account, and in what role. For each account and actorId it stores a compact slot: authenticator, scope, expiry, and (when used) policy metadata.

EIP-8130 validation flow: transaction names an authenticator, authenticator returns an actorId, Account Configuration loads the actor config, then the node checks authenticator binding, permissions, and expiry. — Validation flow: authenticate with the named authenticator, load one actor-config slot, then authorize (binding, scope, expiry).

Existing EOAs work immediately via an implicit EOA actor when the slot is empty.
Smart accounts register or import actors without redeploying wallet code.
The same actor state is reused for transaction auth, payers, signature checks, and config changes.

Authenticators (authn)

An authenticator recovers an actorId from signature data. That is authentication only: it does not decide what the actor is allowed to do. Authenticators typically return a hash of the public key as the actorId.

The canonical set is what the native 8130 hot path admits for transaction validation (today: K1, P-256, passkey / WebAuthn, and delegate). That set grows through a companion ERC, not by letting each wallet invent a mempool authenticator.

Non-canonical authenticators can still be installed in Account Configuration and used in ordinary EVM execution, for example account recovery flows, or sentinels that reuse the signed actor changes system.

Concept	Meaning
K1	Returns the Ethereum address (the familiar secp256k1 identity), not a generic pubkey hash.
P-256	Returns a 32-byte hash of the public key.
Passkey	WebAuthn / passkey path; also returns a 32-byte hash of the public key.
Delegate	For sub-accounts: lets another account’s keys sign for this one. Nested signing on the 8130 path must still use canonical authenticators.

Public keys are not stored in Account Configuration. Key material rides in the auth blob at sign time, which keeps state small and leaves room for larger schemes later.

Authenticator interface: authenticate(hash, data) returns actorId. Example for secp256k1: authenticate(txHash, 65-byte ECDSA signature) yields an Ethereum address via ecrecover. — Authenticators implement `authenticate(hash, data) → actorId`. For K1, that is typically ecrecover over a 65-byte ECDSA signature.

Actors and scopes

An actor is an authorized key on an account. The authenticator answers “who signed?”; the scope answers “what may they do?”

Concept	Meaning
SENDER · 0x01	Originate transactions (ungated). Operational unless combined with POLICY; also covers ERC-1271.
POLICY · 0x02	Originate transactions gated to a single policy_manager.
NONCE · 0x04	Use sequenced nonce_keys (restricted actors; otherwise nonceless only).
SELF_PAYER · 0x08	Pay the account’s own gas (self-pay).
SPONSOR_PAYER · 0x10	Sponsor gas for a different sender.
Admin · 0x00	Unrestricted root: config changes, lock/unlock, and delegation.

One account can hold several actors with different roles: a full owner (admin), a session key (POLICY), a self-pay session key, a sponsor key. That is how 8130 stays capable without putting arbitrary validation in the mempool. See Scopes, payers & phases.

Policies (session keys)

The POLICY scope bit turns an actor into a policy-gated session key. The protocol stays intentionally dumb about the policy contents:

It stores an opaque policy_commitment (hash of parameters).
It binds the actor to a single policy_manager target.
Scope carries POLICY (never admin 0x00). Optional actor expiry.

At execution time the account forces calls to that manager; the manager enforces spend limits, allowlists, and other app rules. Rich stateful checks happen after cheap validation. More detail in Policies and session keys.

Session key flow: authorize an actor with a policy commitment and policy manager, then run a first transaction that installs the policy and executes through the manager, which calls execute on the account. — Session key flow: authorize + install → sign → PolicyManager → account execute. The signed actor change can ride in the first session-key transaction.

Account changes and signed config updates

Accounts evolve through account changes carried in the transaction (or applied via a portable signed path):

Create: deploy a counterfactual account with initial actors (CREATE2 identity known up front).
Config: authorize or revoke actors (signed owner / actor changes), including policy-gated keys.
Delegation: install or update EIP-7702-style code delegation for EOAs moving onto smart account behavior.

Signed actor / owner changes

Config updates are signed state transitions: account, chain id (0 for multichain / replayable updates, or a specific chain id for local ones), sequence, and the list of authorize / revoke operations. An admin actor (scope == 0x00) must sign. Sequences keep updates ordered whether they ride inside an 8130 transaction or are submitted through applySignedActorChanges on a portable path. Depth on chain_id 0, lock locality, and delegation vs 7702: Multichain & portability.

They can also be applied just in time inside an 8130 transaction: put create / rotate / authorize entries in account_changes, then run calls in the same tx. Deploy, sync keys, and act in one shot.

Chain-local vs multichain actor configs, and an 8130 transaction that applies create, rotate key, and authorize session key in account_changes before executing calls. — Chain-local actors use a concrete chain id; multichain actors use chain id 0. Just-in-time account changes ride in the same 8130 tx as the calls that need them.

Transactions in brief

A native 8130 transaction carries sender identity, 2D nonce (or nonce-free + expiry), optional payer, account changes, call phases, and separate sender / payer auth blobs. Nodes validate auth first, then execute. Click a field below for what it does and whether it feeds validation, execution, or both.

AA_TX_TYPE enveloperlp

Click a field

AA_TX_TYPE || rlp([
])

chain_idValidation

Which chain this tx is for (EIP-155).

Checked at admission so the envelope cannot be replayed on another chain.

Where next

From here, go deeper on how nodes admit and drop transactions (Validation, Mempool, Invalidation), or stay on the “why” track with policies and related design notes.