|
| 1 | +--- |
| 2 | +title: "Native Account Abstraction" |
| 3 | +description: "Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays." |
| 4 | +--- |
| 5 | + |
| 6 | +[EIP-8130](https://eip.tools/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. |
| 7 | + |
| 8 | +<Warning> |
| 9 | +EIP-8130 is experimental and currently runs only on the [vibenet devnet](https://vibes.base.org/build). |
| 10 | +</Warning> |
| 11 | + |
| 12 | +## Build with EIP-8130 |
| 13 | + |
| 14 | +EIP-8130 is live on vibenet (chain ID `84538453`, RPC `https://rpc.vibes.base.org`). Client support lives in an experimental viem fork: |
| 15 | + |
| 16 | +```bash |
| 17 | +bun add "viem@github:chunter-cb/viem#feat/eip-8130" |
| 18 | +``` |
| 19 | + |
| 20 | +The example below performs the full flow: |
| 21 | + |
| 22 | +1. Creates an account. |
| 23 | +2. Funds it from the faucet. |
| 24 | +3. Sends a batch of calls that succeed or revert together. |
| 25 | +4. Verifies that every phase succeeded. |
| 26 | + |
| 27 | +```ts create-and-send.ts highlight={19,30-40,43-44} |
| 28 | +import { createPublicClient, http, parseEther } from "viem"; |
| 29 | +import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; |
| 30 | +import { |
| 31 | + newSmartAccount8130, sendCalls8130, estimateGas8130, |
| 32 | + encodeWalletCalls, waitForTransactionReceipt8130, allPhasesSucceeded, |
| 33 | +} from "viem/experimental/eip8130"; |
| 34 | + |
| 35 | +const RPC_URL = "https://rpc.vibes.base.org"; |
| 36 | +const chain = { |
| 37 | + id: 84538453, |
| 38 | + name: "vibenet", |
| 39 | + nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 }, |
| 40 | + rpcUrls: { default: { http: [RPC_URL] } }, |
| 41 | +}; |
| 42 | +const client = createPublicClient({ chain, transport: http(RPC_URL) }); |
| 43 | + |
| 44 | +// The account address is deterministic and exists before any deployment |
| 45 | +const signer = privateKeyToAccount(generatePrivateKey()); |
| 46 | +const account = newSmartAccount8130({ signer }); |
| 47 | + |
| 48 | +// Fund it from the vibenet faucet |
| 49 | +await fetch("https://vibes.base.org/api/vibenet/faucet/drip", { |
| 50 | + method: "POST", |
| 51 | + headers: { "content-type": "application/json" }, |
| 52 | + body: JSON.stringify({ address: account.address }), |
| 53 | +}); |
| 54 | + |
| 55 | +// Estimate, then send a batch. Account creation rides along in the same transaction |
| 56 | +const calls = [{ to: "0x…recipient", value: parseEther("0.001") }]; |
| 57 | +const gas = await estimateGas8130(client, { |
| 58 | + sender: account.address, |
| 59 | + accountChanges: [account.createChange], |
| 60 | + calls: encodeWalletCalls({ account: account.address, calls: [calls] }), |
| 61 | +}); |
| 62 | +const hash = await sendCalls8130(client, { |
| 63 | + account, |
| 64 | + accountChanges: [account.createChange], |
| 65 | + calls, |
| 66 | + gas: (gas * 120n) / 100n, |
| 67 | +}); |
| 68 | + |
| 69 | +// An 8130 receipt reports per-phase results, so check all of them |
| 70 | +const receipt = await waitForTransactionReceipt8130(client, { hash }); |
| 71 | +if (!allPhasesSucceeded(receipt)) throw new Error("a phase reverted"); |
| 72 | +``` |
| 73 | + |
| 74 | +One transaction creates the account, executes the batch, and pays for gas. |
| 75 | + |
| 76 | +## How it works |
| 77 | + |
| 78 | +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. |
| 79 | + |
| 80 | +### Account |
| 81 | + |
| 82 | +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. |
| 83 | + |
| 84 | +### Signer and Actor |
| 85 | + |
| 86 | +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. |
| 87 | + |
| 88 | +### Scope and Policy |
| 89 | + |
| 90 | +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. |
| 91 | + |
| 92 | +### Authenticators |
| 93 | + |
| 94 | +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. |
| 95 | + |
| 96 | +### Payer |
| 97 | + |
| 98 | +A transaction can name a **payer** that covers gas on the sender's behalf. Draft [ERC-8168](https://eip.tools/eip/8168) standardizes the payer service flow: how apps discover and request sponsorship. |
| 99 | + |
| 100 | +## Why native account abstraction |
| 101 | + |
| 102 | +Smart accounts on Ethereum today are bolted on from outside the protocol. [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) requires an alternate mempool, bundlers, and an EntryPoint contract; every app inherits that infrastructure and its costs. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) delegates an EOA to contract code, but the account still validates against its single original key. |
| 103 | + |
| 104 | +EIP-8130 moves the abstraction into the chain, so the features 4337 provides through external services come built into ordinary transactions: |
| 105 | + |
| 106 | +| | ERC-4337 | EIP-7702 | EIP-8130 | |
| 107 | +|---|---|---|---| |
| 108 | +| Validation | EntryPoint contract via bundlers | One fixed key | Protocol, against onchain configuration | |
| 109 | +| Infrastructure | Bundlers + alternate mempool | None | None - standard transactions | |
| 110 | +| Session keys | Per-wallet plugin systems | Not native | Native actors with scoped policies | |
| 111 | +| Gas sponsorship | Paymaster contracts | Not native | Native payers ([ERC-8168](https://eip.tools/eip/8168)) | |
| 112 | +| Batching | Via account contract | Via delegated code | Native, atomic, per-transaction | |
| 113 | + |
| 114 | +## Go deeper |
| 115 | + |
| 116 | +<CardGroup cols={2}> |
| 117 | + <Card title="Reference contracts" href="https://github.com/base/eip-8130" icon="github"> |
| 118 | + `AccountConfiguration`, account implementations, and authenticators, with Foundry tests. |
| 119 | + </Card> |
| 120 | + <Card title="Specifications" href="https://eip.tools/eip/8130" icon="file-lines"> |
| 121 | + The EIP-8130 draft, and companion draft [ERC-8168](https://eip.tools/eip/8168) for payer services. |
| 122 | + </Card> |
| 123 | +</CardGroup> |
0 commit comments