Base plans native account abstraction in Cobalt — EIP-8130 drops bundlers and EntryPoint, cutting USDC transfer gas 63.2% against ERC-4337

What happened

The upgrade tracker in Base's official documentation lists Cobalt as adding native account abstraction with EIP-8130, improving the B20 token standard and introducing dynamic node upgrades. Both Base Sepolia and Base Mainnet are marked "Targeting September 2026" with status Planning, and no activation timestamp is given. Base notes on the same page that a month without a confirmed activation timestamp is a planning target and may change. Node software requirements, it says, will be published once Cobalt is scheduled.

Base Engineering's blog post of 2026-07-17 set out the plan: launch EIP-8130 on Base as part of Cobalt, then across all OP Stack chains later in the year, working with Optimism, a major exchange and WalletConnect to push the standard across EVM chains generally. A temporary devnet, Base Vibenet, exists so developers can test ahead of activation. The documentation states that EIP-8130 is experimental and currently runs only on vibenet, and the reference implementation repository carries a warning that the spec is changing, the code is unaudited and it must not be used in production.

Recent Base history frames this. Base V1 in April–May consolidated onto base-reth-node and base-consensus, retiring op-node and op-geth compatibility. Beryl followed in June — Base Sepolia on 18 June, Base Mainnet on 25 June — bringing B20 tokens and Reth V2. Cobalt continues that line, with Denim after it targeting 200ms native blocks in November.

What actually changes in the design

ERC-4337 delivered smart accounts without touching the protocol, at the cost of an alternate mempool, bundlers and an EntryPoint contract. The features work, but every application that wants them inherits that stack, its operating cost and its failure modes. EIP-7702 simplified matters by letting an externally owned account delegate to contract code, but the account still validates against its single original key.

EIP-8130 moves the abstraction inside the chain. It defines a new transaction type together with an onchain system contract. Accounts configure authorised actors and authenticators in that contract, and the protocol validates transactions using onchain authenticator contracts implementing IAuthenticator.authenticate(hash, data). Smart accounts therefore send ordinary transactions rather than travelling a separate path.

Two account implementations are deployed. DefaultAccount is the bare building block — batched execution via executeBatch plus ERC-1271 isValidSignature, with all authorisation deferred to the Keystore. It is also deployed standalone as the EIP-7702 delegation target for EOAs, which can re-delegate to a new implementation at any time, so no upgrade wrapper is needed. CanonicalHighRatePayerAccount is an immutable high-rate payer variant behind a 45-byte ERC-1167 proxy; while locked it cannot move its own ETH during a transaction, so gas is the only balance decrease, which earns it higher mempool rate limits. Every account is a small per-account proxy at a deterministic CREATE2 address that delegatecalls into a shared implementation singleton.

On efficiency, Base's published comparison against ERC-4337 puts a USDC transfer at 46,000 gas rather than 125,000 — a 63.2% reduction — with transaction byte size down 83.4%. The engineering blog frames this as more than halving the per-transaction cost to end users, attributing it to co-designing EIP-8130 with the rest of the protocol so the transaction format could stay opinionated and optimisable.

Cobalt carries two further items. Dynamic Upgrades introduces an Ethereum smart contract that stores upgrade timestamps for Base nodes, which nodes query so they can apply changes live; for Cobalt it ships in metrics-only mode while data is collected to validate that the mechanism works. B20 improvements include paying transaction fees in B20s, scheduling multiplier updates, simplifying transfer blocking, and new Union and Intersect policies.

Pitfalls to watch

September is not a date. Base itself marks the status as Planning and says so in a note. Secondary coverage nonetheless writes "shipping in September", and a migration plan built on that will be wrong in either direction. Note also the ordering: node requirements are published after the schedule is set, not before.

Existing smart-account users face a one-time migration. Standard EOAs pick up gas sponsorship and batching automatically, but ERC-4337 smart accounts require a one-time upgrade step to benefit from the lower gas costs and faster inclusion. Whether your users hold EOAs or 4337 accounts changes your migration effort entirely.

For node operators the work is not just a version bump. Base's guidance is to update nodes for Cobalt and allow access to several new RPC methods. Where a proxy or API gateway restricts methods by allowlist, forgetting this means only the new transaction type fails.

The reference implementation is unaudited work in progress. Running on vibenet and being safe to hold funds are different things. Integration design can start now, but do not freeze a production implementation until an audited version exists.

[Technical Insights & Actions]

1. Moving account abstraction from external infrastructure into the protocol shifts operating cost and failure modes from the application to the chain. For teams that operate their own bundlers or paymaster implementations, an asset becomes redundant duplication. The same shift is expected to reach other OP Stack chains, so the useful lifetime of your AA-related code is now a live question. [Product / contract developers] This quarter, inventory your bundler, paymaster and EntryPoint integration code and separate what becomes unnecessary once EIP-8130 is in production from what you still need.
2. "Supported" means different things at different layers. Here a node version bump is accompanied by a separate task — permitting new RPC methods. Any setup that filters methods at the network boundary generates this class of oversight at every protocol change. [Infrastructure / node operators] Once the Cobalt activation timestamp is published, make the RPC gateway method allowlist review a checklist item alongside the node update, and verify new-format transactions end to end on testnet.
3. If you do not distinguish planning targets from confirmed dates, everything you publish internally becomes suspect later. Where the source itself says Planning, carry that qualifier through. [Everyone] When circulating internally, reproduce the Base tracker's status label (Planning / Live) along with the date you read it, and re-circulate with an explicit diff once a schedule is confirmed.

[Sources]

• Base Docs, "Base Network Upgrades" (upgrade tracker): https://docs.base.org/upgrades/overview
• Base Docs, "Cobalt Overview": https://docs.base.org/base-chain/specs/upgrades/cobalt/overview
• Base Docs, "Native Account Abstraction": https://docs.base.org/base-chain/network-information/native-account-abstraction
• Base Engineering Blog, "Native Account Abstraction" (2026-07-17): https://blog.base.dev/native-account-abstraction
• base/eip-8130 reference implementation: https://github.com/base/eip-8130

This article is a technical commentary based on publicly available information and is not investment advice.