Build with EIP-8130
EIP-8130 is live on vibenet (chain ID84538453, RPC https://rpc.vibes.base.org). Client support lives in an experimental viem fork:
- Creates an account.
- Funds it from the faucet.
- Sends a batch of calls that succeed or revert together.
- Verifies that every phase succeeded.
create-and-send.ts
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 withCREATE2. 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 implementIAuthenticator.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.