--- title: "Native Account Abstraction" description: "How Base brings account abstraction into the protocol itself via EIP-8130, cutting per-transaction cost over the ERC-4337 smart-account model while keeping accounts portable across EVM chains." source: https://basehub.org/architecture/native-account-abstraction/ --- Native Account Abstraction folds the capabilities of smart accounts directly into the chain through **EIP-8130**, rather than layering them on top of the EVM the way **ERC-4337** did. Base is building it alongside Optimism, Coinbase, and WalletConnect, and it reaches Base with the **Cobalt** upgrade scheduled for September 2026, and the rest of the OP Stack later in the year. Because the transaction type is co-designed with the protocol instead of bolted on, Base reports it can more than halve the per-transaction cost users paid under ERC-4337 without giving up any of the chain's scaling targets. ## Why move account abstraction into the protocol Smart accounts have carried much of the UX progress in crypto over the past few years — gas abstraction, batched actions, and flexible key management all became possible. But the ERC-4337 design that delivered them sits above the EVM, and that placement carries a tax: higher gas, added latency, and more moving parts. Native AA removes that overhead by making these behaviors first-class properties of a chain-level transaction type. Co-designing **EIP-8130** with the surrounding protocol let Base keep the transaction opinionated and easy to optimize. The savings show up directly in gas and calldata: | Transaction type | ERC-4337 | Native AA | | --- | --- | --- | | USDC Transfer | 125,000 gas / 1,090 bytes | 46,000 gas (-63.2%) / 180 bytes (-83.4%) | | USDC Transfer (Passkey, Sponsored) | 173,000 gas / 1,940 bytes | 68,700 gas (-60.3%) / 890 bytes (-56.1%) | ## What becomes native to the chain With EIP-8130, the following capabilities are provided by the chain itself rather than by contract-level machinery: - **Batch calls** — bundle several actions into one transaction. - **Sponsorship** — an application can cover its users' gas, or let them pay in a token of their choice. - **Portability** — the same account travels to any chain, including ones that have not yet adopted Native AA. - **Quantum readiness** — support for key rotation and multiple authentication schemes leaves room to move to post-quantum authentication. - **High throughput** — parallel nonces and generous sender limits allow a high degree of concurrency. - **Session keys** — an application can act for you within bounded, revocable permissions. - **Sub-accounts** — a fully isolated account you own that an application can operate. - **Metadata** — attach memos and attribution to transactions. A key point of the design is that adopting Native AA on Base does not tie an account to Base — accounts remain usable on other EVM chains regardless of whether those chains support the feature yet. ## How EIP-8130 works Every 8130 transaction identifies the account it is sent from, demonstrates that whoever submitted it is permitted to act on that account's behalf, and bundles a group of calls to execute together. The whole model reduces to five pieces: - **Account.** Addresses are deterministic — a client derives them locally with `CREATE2`, so an account address exists before any code is deployed and its creation can ride along inside the first transaction it sends. Each account is a thin proxy that routes its calls into a shared implementation contract; `DefaultAccount` is the minimal version and also backs EOAs upgraded through EIP-7702. A variant tuned for high transaction rates locks up outbound ETH mid-execution in return for looser mempool rate-limit ceilings. - **Signer and actor.** A *signer* is what generates the authorization attached to a transaction; the *actor* is the onchain identity that authorization maps back to, as recorded in the `AccountConfiguration` system contract. One account can authorize many actors and revoke any of them independently. - **Scope and policy.** Every actor carries scope flags — `SCOPE_NONCE`, `SCOPE_POLICY` — that bound what it can do, and it can bind to an onchain policy setting per-token spend limits and allowed contracts/functions. This is the native session-key model: give an app an actor scoped to precisely the permissions it should have, and pull that grant back whenever you want. - **Authenticators.** Signature checking is pluggable through contracts implementing `IAuthenticator.authenticate(hash, data)`. The reference set covers secp256k1, P-256, and WebAuthn, so passkeys validate at the protocol level instead of through wrapper contracts. - **Payer.** A transaction may name a payer to cover gas for the sender. The draft [ERC-8168](https://eip.tools/eip/8168) standardizes how apps discover and request that sponsorship. ## Trying it on vibenet EIP-8130 is experimental and, for now, only runs on the vibenet devnet (chain ID `84538453`, RPC `https://rpc.vibes.base.org`). Client-side support currently ships in an experimental fork of viem: ```bash bun add "viem@github:chunter-cb/viem#feat/eip-8130" ``` The `viem/experimental/eip8130` helpers let a single transaction create an account, fund it from the vibenet faucet, and send an atomic batch of calls — an 8130 receipt reports per-phase results, so a successful send still has to be checked phase by phase. The reference contracts (`AccountConfiguration`, the account implementations, and the authenticators, with Foundry tests) live at [github.com/base/eip-8130](https://github.com/base/eip-8130). ## What changes for each audience - **Users.** A standard EOA gains access to new behaviors such as gas sponsorship and batching automatically. An existing ERC-4337 smart account takes a one-time upgrade to move onto the cheaper, faster-to-include path. - **Application developers.** Existing integrations keep working unchanged — for example, `wallet_sendCalls` continues to function against Native AA — while new capabilities like memos (for attribution), session keys, and sub-accounts become available. - **Wallets.** No changes are required to keep working as they do today. Adding Native AA support opens new revenue paths through subscriptions and **ERC-8168** payer services. - **Node operators.** The only required step is upgrading nodes for Base Cobalt and permitting access to several new RPC methods. ## Testing ahead of activation To let developers exercise EIP-8130 before it goes live, Base is introducing **Base Vibenet**, an ephemeral devnet for trying out chain-level features prior to their activation. Native AA is meant to run on any EVM chain, and Base is inviting chains, wallets, and applications to integrate it. See the original announcement at [blog.base.dev/native-account-abstraction](https://blog.base.dev/native-account-abstraction).