Protocol

Validation pipeline

Every native EIP-8130 transaction runs the same gate before wallet execution. Mempool admission and block execution share this mental model; only the surrounding checks (pending limits, lock, gas debit) differ.

The four steps

Concept	Meaning
1. Resolve	Determine sender (explicit sender, or recover from sender_auth) and the effective authenticator from the auth blob shape.
2. Authenticate	authenticator.authenticate(hash, data) → actorId. The authenticator checks the auth data (typically a signature) against the signed hash and returns the actor’s identity.
3. Authorize	SLOAD actor_config. Require authenticator match, implicit-EOA empty-slot rule, and unexpired actor. Authorize scope against the action (SENDER/POLICY, SELF_PAYER/SPONSOR_PAYER, admin, operational).
4. Execute	Only after validation: apply account_changes, then run call phases. Auth failures never reach wallet logic.

Auth blob shapes

Implicit EOA path: sender empty; sender_auth is a bare 65-byte ECDSA (r || s || v). Cheapest path; the protocol ecrecovers the sender and resolves the inline default-EOA config.
Configured actor: authenticator(20) || data; authenticator must be canonical on the native path. The default EOA path works here too when named explicitly (native secp256k1 authenticator + ECDSA data), with the same self-actor resolution as the bare signature form.

Sender and payer use separate signing domains so a payer signature cannot authorize sender execution. Details in Scopes, payers & phases.

Account changes during validation

Mempool validation must reason about the actor set after in-tx config changes (create / authorize / revoke / delegate), because those entries apply before calls:

At most one create (first) and at most one delegation per tx.
Config / delegation rejected if the account is locked.
Simulate applying config entries in sequence; skip already-applied.
Validate sender_auth against the resulting actor state; require SENDER or POLICY (and admin EOA-actor authority for delegation).

Policy actors at validation vs execution

Unlike some other AA proposals, 8130 evaluates policies at execution, never at validation. This keeps validation known, bounded, and predictable: a fixed set of cheap checks, no interpreting app-defined policy logic in the mempool.

Other AA proposals run authentication, unstandardized authorization lookups, and an optional complex policy check all inside unpaid validation. EIP-8130 keeps validation to cryptographic authentication and known account-config authorization; the complex policy check is optional and happens at execution, where an actor gated by the policy system can only reach its policy target. — Other AA proposals push policy checks into unpaid validation. 8130 keeps validation to authentication plus known account-config authorization, and defers the policy gate to execution.

Validation

Nodes check that the actor is authorized, in-scope, and unexpired. If the actor has POLICY set, the protocol only needs to know that all calls will be gated to the actor's policy_manager: it does not interpret the policy parameters, and that gate is applied at execution time.

Execution

The account enforces call.to == policy_manager: The manager enforces the committed policy. That split is intentional. See Policies and session keys.

Native authenticator implementations

Nodes MAY implement well-known authenticators natively if results match the onchain contract bit-for-bit. Benefits: deterministic gas, no interpreter overhead, no external state deps. This is a major throughput lever for mempool workers.