Native Account Abstraction Reference

EIP-8130 reference for Base: vibenet chain details, client setup, transaction structure, account configuration, authenticators, and payers.

This is the technical reference for EIP-8130 on Base. For what native account abstraction is and why the protocol implements it, start with Native Account Abstraction.

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.

Network details

Field	Value
Network	vibenet devnet
Chain ID	84538453
RPC	https://rpc.vibes.base.org
Faucet	POST https://api.vibes.base.org/api/vibenet/faucet/drip

Client setup

Client support lives in an experimental viem fork:

bun add "viem@github:chunter-cb/viem#feat/eip-8130"

Create an account and send a batch

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

import { createPublicClient, http, parseEther } from "viem";
import { privateKeyToAccount, generatePrivateKey } from "viem/accounts";
import {
  newSmartAccount8130, sendCalls8130, estimateGas8130,
  encodeWalletCalls, waitForTransactionReceipt8130, allPhasesSucceeded,
} from "viem/experimental/eip8130";

const RPC_URL = "https://rpc.vibes.base.org";
const chain = {
  id: 84538453,
  name: "vibenet",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: [RPC_URL] } },
};
const client = createPublicClient({ chain, transport: http(RPC_URL) });

// The account address is deterministic and exists before any deployment
const signer = privateKeyToAccount(generatePrivateKey());
const account = newSmartAccount8130({ signer });

// Fund it from the vibenet faucet
await fetch("https://api.vibes.base.org/api/vibenet/faucet/drip", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ address: account.address }),
});

// Estimate, then send a batch. Account creation rides along in the same transaction
const calls = [{ to: "0x…recipient", value: parseEther("0.001") }];
const gas = await estimateGas8130(client, {
  sender: account.address,
  accountChanges: [account.createChange],
  calls: encodeWalletCalls({ account: account.address, calls: [calls] }),
});
const hash = await sendCalls8130(client, {
  account,
  accountChanges: [account.createChange],
  calls,
  gas: (gas * 120n) / 100n,
});

// An 8130 receipt reports per-phase results, so check all of them
const receipt = await waitForTransactionReceipt8130(client, { hash });
if (!allPhasesSucceeded(receipt)) throw new Error("a phase reverted");

One transaction creates the account, executes the batch, and pays for gas.

Transaction structure

An 8130 transaction names a sender account, proves the sender is authorized to act for it, and carries a batch of calls.

Field	Purpose
sender	The account the transaction acts for.
accountChanges	Configuration changes applied before execution, including account creation.
calls	The batch to execute atomically.
payer	Optional account that covers gas on the sender’s behalf.

Receipts report results per phase rather than as a single status, so a transaction can succeed at the transaction level while an individual phase reverts. Check every phase; allPhasesSucceeded does this in the reference client.

Accounts

Account addresses are derived with CREATE2, so a client computes them locally and the address exists before any deployment. That is why account.address is available immediately and account.createChange can ride along in the first transaction.

Each account is a small proxy contract that forwards calls to a shared implementation.

Implementation	Notes
DefaultAccount	The minimal building block. Also backs EOAs upgraded via EIP-7702.
High-rate variant	Locks outbound ETH during execution in exchange for higher mempool rate limits.

Account configuration

Authorization lives in the AccountConfiguration system contract. It records the actors an account authorizes: the onchain identities that a signer’s authorization resolves to. An account may authorize many actors and revoke each independently.

Each actor entry carries:

Element	Purpose
Scope flags	SCOPE_NONCE and SCOPE_POLICY bound what the actor may do.
Policy binding	Optional onchain policy: per-token spend limits, and allowed contracts and functions.
Authenticator	The contract that validates this actor’s signatures.

Binding an actor to a policy is the native session key model: an app receives an actor with exactly the permissions it needs, revocable at any time.

Authenticators

Signature validation is pluggable. Authenticator contracts implement:

interface IAuthenticator {
    function authenticate(bytes32 hash, bytes calldata data) external view returns (bool);
}

The reference set covers:

Authenticator	Keys
secp256k1	Standard EVM keys
P-256	NIST P-256
WebAuthn	Passkeys and platform authenticators

Passkeys therefore validate at the protocol level, not through wrapper contracts.

Payers

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

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.