Why EIP-8130

Pragmatic, opinionated, capable

EIP-8130 puts account abstraction in the protocol itself. You submit transactions directly to the network. No bundlers, no EntryPoint on the happy path. Moving past ERC-4337-style relay infrastructure is a real win for users and operators.

Among native AA designs, 8130 is deliberately opinionated. It can do everything wallets and apps need (multi-key accounts, session keys, payers, sub-accounts, phases, portable identity) and do it well. The one thing it leaves out, arbitrary validation logic defined by the wallet, is a feature, not a bug.

The chain problem with AA today

Most AA designs push validation into wallet bytecode (or an EntryPoint that simulates it). That is flexible for wallets, expensive for chains. And the flexibility is often over-flexibility: wallets fight for competing standards and fragment. Something that works on one chain may be considered invalid on another, or rejected by certain mempools, so “works here” does not mean “works everywhere.”

• Mempool admission: often needs simulation or a trusted relay path, which makes DoS, state dependencies, and revalidation hard to reason about.
• Builders: have to re-simulate as chain state moves, because crypto validity and account policy are tangled up with arbitrary EVM.
• Fragmented acceptance: different factories, salts, auth models, and mempool policies per ecosystem, so accounts and signatures do not travel cleanly.

Shared auth, programmable wallets

Put who may act and in what role into a shared Account Configuration contract. Keep what the wallet does in programmable account code. Nodes validate along a fixed pipeline before wallet execution:

1. Resolve: read the account's actor config for the named authenticator (one SLOAD).
2. Authenticate: run the named authenticator (native or STATICCALL) to recover the actor.
3. Authorize: check scope, expiry, and (if any) policy target gates for that actor.
4. Execute: only then apply account changes and run the call phases.

Wallets know exactly what the node accepts. Accounts become universal across the EVM: using one signature type on one chain means it will also be accepted on another. Native chains speak AA_TX_TYPE (0x79). Portable contracts still exist for non-native chains via ERC-4337 providers, though that path does not give you the native mempool benefits. It helps to be clear with stakeholders about which path they are enabling.

Validation is boring; execution is unlimited

Validation should be boring: bounded, predictable, and cheap. Execution is unlimited once it's paid for. Builders should be able to tell that a transaction is valid quickly, so extra logic belongs after validation, in execution. That is a better home for stateful conditions, and policies make it easy: the protocol gates the actor to a single manager, and the manager runs the rich checks.

Want a transaction that depends on stateful conditions for "validity"? Pay for those checks in execution. The transaction can still be included, and you are billed for that computation, instead of asking every node to re-run open-ended wallet logic just to keep the tx in the mempool.

What chains get by adopting

Cheap, structured validation

Admission does not require tracing arbitrary wallet code. Canonical authenticators are stateless over the signature payload; the hot state is actor_config + nonce (+ balance / expiry).

Clear DoS knobs

Intrinsic auth gas, the authenticator allowlist (canonical set) with fixed / metered authenticator cost, config-change limits, payer pending-count thresholds, lock-based sender / payer rate, and nonce-free expiry windows. See Mempool design.

Fast inclusion-time checks

Keep the builder clear of dead work. The invalidation surface is known up front, and compared to a 1559 transaction it can be checked with a single additional SLOAD. No execution or extra crypto required.

Product surface without protocol sprawl

Session keys, payers, sub-accounts, and multi-key accounts are compositions of actors, scopes, and (optional) opaque policies, not new opcodes or per-app mempool rules.

What this is not

• Not a replacement for the normative EIP text.
• Not a wallet integration tutorial (see the Guide).
• Not a claim that every AA feature works identically on the portable 4337 path. The capability split is in Multichain & portability.