Skip to main content
EIP-8130 builds account abstraction into the protocol. An account registers who can act for it, and how its signatures are checked, in an onchain system contract. The chain validates each transaction against that configuration, so smart accounts work without bundlers, relays, or a separate mempool.
EIP-8130 is experimental and currently runs only on the vibenet devnet. You can learn more about connecting to vibenet here.

Build with EIP-8130

EIP-8130 is live on vibenet (chain ID 84538453, RPC https://rpc.vibes.base.org). Client support lives in an experimental viem fork:
The example below performs the full flow:
  1. Creates an account.
  2. Funds it from the faucet.
  3. Sends a batch of calls that succeed or revert together.
  4. Verifies that every phase succeeded.
create-and-send.ts
One transaction creates the account, executes the batch, and pays for gas.

How it works

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

Account

Account addresses are deterministic: viem computes them locally with CREATE2. That is why account.address exists before any deployment and account.createChange rides along in the first transaction. Each account is a small proxy contract that forwards calls to a shared implementation. DefaultAccount is the minimal building block and backs externally owned accounts (EOAs) upgraded via EIP-7702. A variant built for high transaction rates locks outbound ETH during execution in exchange for higher mempool rate limits.

Signer and Actor

A signer produces the transaction’s authorization (privateKeyToAccount above). An actor is the onchain identity that authorization resolves to, recorded in the AccountConfiguration system contract. An account can authorize many actors and revoke each independently.

Scope and Policy

Each actor carries scope flags (SCOPE_NONCE, SCOPE_POLICY) that limit what it may do. It can also bind to an onchain policy: per-token spend limits and restrictions on which contracts and functions it may call. This is the native session-key model: an app gets an actor with exactly the permissions it needs, revocable at any time.

Authenticators

Signature validation is pluggable. Authenticator contracts implement IAuthenticator.authenticate(hash, data). The reference set covers secp256k1 (standard Ethereum keys), P-256, and WebAuthn. Passkeys therefore validate at the protocol level, not through wrapper contracts.

Payer

A transaction can name a payer that covers gas on the sender’s behalf. Draft ERC-8168 standardizes the payer service flow: how apps discover and request sponsorship.

Why native account abstraction

Smart accounts on Ethereum today are bolted on from outside the protocol. ERC-4337 requires an alternate mempool, bundlers, and an EntryPoint contract; every app inherits that infrastructure and its costs. EIP-7702 delegates an EOA to contract code, but the account still validates against its single original key. EIP-8130 moves the abstraction into the chain, so the features 4337 provides through external services come built into ordinary transactions:

Go deeper

Reference contracts

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

Specifications

The EIP-8130 draft, and companion draft ERC-8168 for payer services.