> ## Documentation Index
> Fetch the complete documentation index at: https://base-a060aa97-mux-docs-claude-6.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/base-chain/network-information/native-account-abstraction).

[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.

<Warning>
  EIP-8130 is experimental and currently runs only on the [vibenet devnet](https://chain.base.org/vibenet). You can learn more about connecting to vibenet [here](/base-chain/quickstart/connecting-to-base#vibenet).
</Warning>

## 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:

```bash theme={null}
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.

```ts create-and-send.ts highlight={19,30-40,43-44} theme={null}
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:

```solidity theme={null}
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](https://eip.tools/eip/8168) standardizes the payer service flow: how apps discover a payer and request sponsorship.

## Go deeper

<CardGroup cols={2}>
  <Card title="Reference contracts" href="https://github.com/base/eip-8130" icon="github">
    `AccountConfiguration`, account implementations, and authenticators, with Foundry tests.
  </Card>

  <Card title="Specifications" href="https://eip.tools/eip/8130" icon="file-lines">
    The EIP-8130 draft, and companion draft [ERC-8168](https://eip.tools/eip/8168) for payer services.
  </Card>
</CardGroup>