Native Account Abstraction

Understand native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers, relays, or paymaster infrastructure.

Native account abstraction makes smart accounts a property of the chain instead of something bolted on around it. An account records who is allowed to act for it, and how its signatures are checked, in an onchain system contract. Base validates every transaction against that configuration, so smart accounts send ordinary transactions.

Base’s implementation is EIP-8130, landing with the Cobalt upgrade.

EIP-8130 is experimental and currently runs only on the vibenet devnet. See connecting to Base for connection details.

Why native

Smart accounts on EVM networks today work around the protocol rather than inside it, and you pay for that in infrastructure.

ERC-4337 introduces an alternate mempool, bundlers, and an EntryPoint contract. Every app that wants smart account features inherits that stack, its operating cost, and its failure modes. EIP-7702 lets an externally owned account (EOA) delegate to contract code, which is simpler, but the account still validates against its single original key.

EIP-8130 moves the abstraction into the chain, so features that 4337 provides through external services come built into ordinary transactions:

	ERC-4337	EIP-7702	EIP-8130
Validation	EntryPoint contract via bundlers	One fixed key	Protocol, against onchain configuration
Infrastructure	Bundlers and an alternate mempool	None	None, standard transactions
Session keys	Per-wallet plugin systems	Not native	Native actors with scoped policies
Gas sponsorship	Paymaster contracts	Not native	Native payers (ERC-8168)
Batching	Via the account contract	Via delegated code	Native, atomic, per transaction

The five concepts

An EIP-8130 transaction names a sender account, proves the sender is authorized to act for it, and carries a batch of calls. Everything in the model maps to one of five ideas.

Account

An account is a small proxy contract that forwards calls to a shared implementation. Its address is deterministic, so it exists and can receive funds before anything is deployed, and the deployment can ride along in the account’s first transaction.

DefaultAccount is the minimal building block, and also backs EOAs upgraded through EIP-7702. A separate variant built for high transaction rates locks outbound ETH during execution in exchange for higher mempool rate limits.

Signer and actor

A signer is what produces a transaction’s authorization: a private key, a passkey, a hardware device.

An actor is the onchain identity that authorization resolves to, recorded for the account in a system contract. The distinction matters because an account can authorize many actors at once and revoke each one independently. Losing a device means revoking one actor, not migrating the account.

Scope and policy

Each actor carries scope flags that limit what it may do, and can bind to an onchain policy: per-token spend limits, plus restrictions on which contracts and functions it may call.

This is the native session key model. An app receives an actor with exactly the permissions it needs and nothing more, enforced by the chain, revocable at any time.

Authenticators

Signature validation is pluggable. Authenticator contracts implement a single authenticate entrypoint, and the reference set covers secp256k1 (standard EVM keys), P-256, and WebAuthn.

Passkeys therefore validate at the protocol level. There is no wrapper contract and no verification cost premium for using a device credential instead of a seed phrase.

Payer

A transaction can name a payer that covers gas on the sender’s behalf, so sponsorship needs no paymaster contract. Draft ERC-8168 standardizes the service flow around it: how apps discover a payer and request sponsorship.

What it unlocks

• Passkey accounts by default. A user signs with the biometric on their device, validated by the protocol, with no seed phrase anywhere in the flow.
• Session keys that are real permissions. Grant an app a scoped, spend-limited actor instead of blanket approval, and revoke it without moving funds.
• Atomic batching. Approve and swap, or claim and stake, succeed or revert together in one transaction.
• Sponsored onboarding. A new user’s first transaction can be paid for by the app, with no bundler or paymaster deployment.
• Accounts that survive a lost device. Rotate an actor rather than recover a key.

Next steps

EIP-8130 reference

Chain details, client setup, a working code example, and the onchain interfaces.

Cobalt upgrade

Activation status and required node software.

Reference contracts

AccountConfiguration, account implementations, and authenticators, with Foundry tests.

Connect to vibenet

RPC endpoints and chain ID for the devnet where EIP-8130 runs today.