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, with the rest of the OP Stack to follow. It has no activation date on Base, and as of mid-September 2026 it has no fork either. Cobalt was to carry it, then Denim was, and upstream has now dropped it from both upgrade pages without naming a successor. The node source points the same way: EIP-8130 transactions sit on a separate zenith gate that no canonical network sets, reserved for genesis-level testing. Vibenet is still the only place you can exercise it. 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. An authenticator is any contract satisfying:

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

  The reference set covers secp256k1 (ordinary EVM keys), P-256, and WebAuthn, which is what puts passkey validation at the protocol level instead of behind a wrapper contract.

  Base’s own node is narrower than the design for now. Since late September 2026 (#5232), its txpool admits only the native k1 authenticator on the transaction path, for the sender and the payer alike, and the payload must be exactly r || s || v (65 bytes). A sender or payer that names P-256, WebAuthn, or the delegate authenticator is turned away at admission, so passkey-signed 8130 transactions do not currently reach a block through the Base node. Treat this as the state of an unscheduled feature, not a final scope.

• Payer. A transaction may name a payer to cover gas for the sender. The draft ERC-8168 standardizes how apps discover and request that sponsorship.

What an 8130 transaction carries

A transaction under this model always does three things: it names the account it acts for, it shows that the submitter is cleared to act for that account, and it carries the calls to run. Four fields do that work.

Field	Purpose
sender	The account the transaction acts for.
accountChanges	Configuration applied before execution — creating the account included.
calls	The batch to run atomically.
payer	Optional. The account that covers gas instead of the sender.

The set of account changes is shrinking in the node. The same September change reorders the accountChanges type bytes so that code delegation takes 0x01 (ACCOUNT_CHANGE_TYPE_DELEGATION) and the signed config batch moves to 0x02 (ACCOUNT_CHANGE_TYPE_CONFIG), with creation still at 0x00. Source comments call delegation the one entry the launch wire keeps, and mark both Create and ConfigChange for deletion in follow-up work. Encoders built against the earlier byte order will now decode as the wrong change type, so rebuild any 8130 tooling against the current node.

Delegation is now opt-in only. Before late September 2026 (#5255), the node pointed a sender with no code at DEFAULT_ACCOUNT on its own during execution and charged an auto_delegation_cost of 4,600 gas for it. That path is gone: a code-less sender is delegated only when the transaction carries an explicit 0x01 delegation entry, and the intrinsic gas formula no longer has an auto-delegation term. Delegation updates also stop adding a DelegationApplied log to the receipt, so the protocol-injected logs are now only ActorAuthorized, ActorRevoked, and AccountCreated. An indexer that watched for DelegationApplied must read delegation from the transaction’s accountChanges instead.

Receipts need care here. Rather than collapsing to one status, an 8130 receipt reports a result for each phase, which means a transaction can come back successful at the top level while a phase inside it reverted. Check every phase before you treat a send as done. In the reference client allPhasesSucceeded does exactly that.

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, faucet POST https://api.vibes.base.org/api/vibenet/faucet/drip). Client-side support currently ships in an experimental fork of viem:

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.

What changes for each audience

• Users. A standard EOA gains access to new behaviors such as gas sponsorship and batching. In the current node that takes an explicit delegation entry, not an automatic upgrade (see above). 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. Nothing to do yet, because no fork carrying EIP-8130 is scheduled. When Denim gets a date, the required step is moving nodes onto that build and opening access to several new RPC methods. Upstream publishes the version requirements at that point.

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.