Cabinet
Back to Technology Insights
2026.09.14

[Follow-up] Ethereum and Base Abandon Effort to Unify Native Account Abstraction: EIP-8141 and EIP-8130 Proceed as Separate Standards, and Wallets Will Have to Implement Both

[Follow-up] Ethereum and Base Abandon Effort to Unify Native Account Abstraction: EIP-8141 and EIP-8130 Proceed as Separate Standards, and Wallets Will Have to Implement Both

What happened

According to The Block, Ethlabs developer Derek Chiang posted on X on Monday, September 14, that the coordination effort between the authors of EIP-8130 and EIP-8141 had ended the previous week. The two sides had tried to define a common standard usable on both Ethereum L1 and Base L2. "While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals," Chiang wrote. "So separate ways we went, putting the burden on wallets to deal with the fragmentation that ensues."

EIP-8141 treats a transaction as a sequence of "frames" that separately validate the sender, approve who pays gas, and execute the user's actions. The proposal says: "an account simply becomes an address with code." In the Hegotá tier list published by the Ethereum Foundation's Protocol cluster on September 7, EIP-8141 was labeled "must-ship." Co-author Vitalik Buterin said on September 5 that the proposal had made "a lot of important progress" and "gets close to optimal." A technical newsletter from the third week of September reports test specs at v0.3.0 and three clients ready for frames-devnet-0.

EIP-8130, led by Base, combines a new transaction type with an on-chain "Keystore" that records each account's approved signers and authenticators. Together they provide custom authentication, call batching and gas sponsorship.

Same problem, different optimization

Both proposals target the same problems: paying fees without holding ETH, signing with arbitrary schemes such as passkeys, and bundling several actions into one transaction. Today these are partly addressed by ERC-4337 (contract-level AA) and EIP-7702 (code delegation for EOAs). Constraints remain, however, including a separate mempool and bundlers and extra gas overhead, which is why native, in-protocol AA has been sought.

The difference appears to lie in how much freedom validation gets. EIP-8141 favors generality: validation itself can be written as EVM code. That generality means signature schemes can be swapped later, which also gives Ethereum a path toward quantum resistance. EIP-8130 instead has accounts register approved signers and authenticators declaratively in the Keystore. Because validation is bounded in advance, nodes and sequencers can predict processing cost more easily, which reads as a fit for an L2 handling high transaction volumes. This contrast is the author's reading of the proposals' structure, not an official statement from either camp.

The priorities Chiang named map onto this structural difference. Arbitrary-code validation makes mempool validation cost and DoS resistance harder to design; that is why ERC-4337 put strict limits on its validation phase. Limiting validation to declarative registration makes operations more predictable, but adding a new authentication scheme then waits on a Keystore spec change. The question is who carries which burden, and L1 and L2 answered it differently.

Effects on existing AA assets and other L2s

The split affects more than two future formats. It also raises the question of how ERC-4337 smart accounts already in production, and EOAs that have set EIP-7702 delegations, will migrate. EIP-8141's framing of an account as "an address with code" points toward absorbing existing smart accounts naturally. EIP-8130's Keystore keeps signer information in an on-chain registry, so existing accounts would likely need to re-register their authentication setup. Neither proposal has presented a final migration procedure for existing accounts. What is certain today is that migration paths may differ by chain.

The other question is what L2s besides Base will do. OP Stack and Arbitrum Orbit chains will have to choose whether to adopt L1's format, Base's format, or their own extension. As of now, we have not found an official statement of position from any other major L2. Rollup Improvement Proposals (RIPs) offer a path to align L2s. But this case shows that even L1 and one of the largest L2s could not unify because their objectives differ, so alignment will not be easy.

How far from implementation

EIP-8141 is "must-ship" for Hegotá, but Hegotá follows Glamsterdam and public information puts its target in 2027. With even Glamsterdam's mainnet date unset, native AA on L1 is still some way off. The reporting gives no new schedule for when EIP-8130 might activate on Base. For now, production AA continues to run on ERC-4337 and EIP-7702. In other words, for at least another year or so, bundler and paymaster infrastructure and security review of EIP-7702 delegate contracts will remain the main work for teams implementing AA. Native AA does not make those investments wasted. With two native formats in parallel, existing 4337-style infrastructure may well stay relevant longer as the layer that ties them together.

Pitfalls to watch

First, having an EIP number does not make something an Ethereum-wide standard. EIP-8130 has an EIP number, but its main target is Base. The split likely makes L1 adoption of it less likely.

Second, as Chiang acknowledged, the burden of fragmentation falls on wallets. If signing request formats, gas payer designation and session-key representations differ by chain, branches pile up in wallets and SDKs just to deliver the same UX.

Third, Hegotá's spec is not frozen. Neither "must-ship" nor SFI (Scheduled for Inclusion) freezes the detailed frame spec. Building deeply against today's spec risks rework.

[Technical Insights & Actions]

  1. Native AA design split over which to prioritize: validation flexibility (L1's post-quantum migration) or predictable validation cost (L2 throughput). As long as L1 and L2 optimize for different objectives, divergences like this will recur beyond AA. [Product teams / Architects] In your next technical roadmap, decide feature by feature, for each chain you support, whether to follow the L1 standard or use L2-specific extensions, and record the reasoning.
  2. When signing and gas-payment formats multiply, branching accumulates in wallets and SDKs. Building ERC-4337, EIP-7702, EIP-8141 and EIP-8130 as four separate paths makes maintenance cost grow linearly. [Wallet / SDK developers] Within six months, define an internal representation of the user's intent (action, payer, authentication) and design an abstraction that keeps conversion to each format in a separate layer. Validate it first on the existing ERC-4337 and EIP-7702 paths.
  3. A spec's status (Draft, SFI, must-ship) and the time it goes live on mainnet are different things. Hegotá comes after Glamsterdam, whose mainnet date is itself still open. [Contract developers] Until Hegotá's spec is frozen, keep EIP-8141-based work out of production code and limited to prototypes on frames-devnet. Continue production AA support on ERC-4337 and EIP-7702.

[Sources]

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

Previous Article[Follow-up] Glamsterdam's Sepolia Fork Locked for 2026-10-06 13:53:36 UTC (Epoch 353024): First Clean Transition on Devnet-11, and the "Epoch 351232" Mismatch ExplainedNext Article ether.fi Liquid's AtomicQueue.solve() Trusted a Caller-Supplied Solver, and Existing ERC-20 Allowances Were Drained