Ethereum and the Base ecosystem are moving toward different account abstraction (AA) standards after an effort to align on a shared approach reportedly stalled last week. The split could have practical consequences for wallet developers, potentially requiring support for multiple transaction formats to deliver a consistent user experience across networks.

In an X post on Monday, Derek Chiang—founding member and researcher at Ethlabs and a co-author of Ethereum’s EIP-8141—warned that interoperability standards have taken a back seat to each chain’s primary goals. “Putting the burden on wallets,” Chiang wrote, framing the divergence as a shift in where the compatibility work will land.

Key takeaways

Ethereum and Base are pursuing different native account abstraction paths after a previously sought shared standard failed to materialize.
Wallets may need to handle separate transaction formats to maintain a uniform experience across networks.
Ethereum is progressing account abstraction under EIP-8141 via “Frame Transactions” as part of its Hegotá upgrade plan.
Base’s native account abstraction implementation via Keystore is aligned with EIP-8130 and is already live on devnet.
The divergence reflects a broader tension: L1 priorities around security and resistance themes vs. L2 alignment with scalability-oriented standards.

Why the account abstraction split matters

Account abstraction is designed to move transaction logic out of fixed protocol rules and into programmable authorization mechanisms. That enables more flexible transaction policies—for example, defining how users authorize actions and how network fees are handled—without relying solely on traditional externally owned account behavior.

But as AA becomes native to more chains, standardization becomes increasingly important for the application layer. When chains choose different AA schemes, wallet software often becomes the integration point. In that scenario, developers may have to map user actions into multiple formats, or maintain separate signing and fee-handling flows depending on which chain the transaction targets.

Chiang’s framing suggests that while technical progress continues, the interoperability “cost” is shifting away from cross-chain AA agreements and toward wallet infrastructure. For end users, that tradeoff can surface as inconsistent behavior across networks—especially in edge cases involving authorization rules, fee sponsorship patterns, or signature semantics.

Ethereum’s Hegotá direction: EIP-8141 and Frame Transactions

On Ethereum, the roadmap for native account abstraction is closely tied to EIP-8141. According to the proposal’s materials, Ethereum is advancing “Frame Transactions” as a “headliner” item under its Hegotá upgrade, which is planned to introduce native account abstraction and create a path toward post-quantum authentication.

Ethereum Foundation communications also identify protocol Hegotá as an upgrade with multiple items, and EIP-8141 is highlighted as a key feature. The intent, as described in these sources, is to make account abstraction an integrated capability rather than an external add-on—an approach that could influence how wallets, dApps, and security tooling interact with Ethereum accounts going forward.

Timing is still dependent on broader upgrade sequencing. The same coverage notes that Ethereum developers could begin implementing Hegotá in late 2026 following Glamsterdam. Glamsterdam, per Ethereum’s public roadmap as discussed in prior reporting, is expected to improve scalability, harden the network, and make the system easier to use, with a mainnet launch expected in the second half of 2026.

Base’s native AA: EIP-8130 and Keystore on devnet

Base, meanwhile, is taking a separate route to native account abstraction through Keystore. The project’s documentation describes native account abstraction under EIP-8130, and the specification indicates that the implementation is currently live on devnet.

The significance of Base’s approach is twofold. First, it suggests that Base is treating the AA feature as something it will integrate and iterate on quickly in its own ecosystem, rather than waiting for a cross-chain convergence point. Second, if Base’s AA model differs from Ethereum’s, wallet teams will likely have to build a more adaptable abstraction layer to support both ecosystems.

For developers building across networks, the divergence may also affect application assumptions around transaction structure and how authorization and fee-related operations are packaged. Even if user-facing features remain similar, the underlying transaction format can change—forcing more careful integration work for cross-chain dApps and tooling.

L1 vs. L2 priorities: different visions, different standards

Chiang’s argument connects the technical divergence to differing design priorities between layer-1 networks and layer-2 networks. He suggested that L1s are increasingly focused on elements such as censorship resistance, capture-resistance, open-source values, privacy, and security features—factors that could naturally lead to different account abstraction standards than those favored by scalability-focused L2 environments.

In contrast, he implied that L2s may be more aligned with standards such as EIP-8130. That difference helps explain why standardization efforts may stall: each network is optimizing for its own constraints and goals rather than minimizing complexity for shared infrastructure.

Still, Chiang cautioned against treating the separation as an automatic negative. He argued that the outcome doesn’t necessarily end badly because Ethereum and Base are “free to innovate” on account abstraction within the boundaries of their respective visions. Practically, however, the gap creates work for wallets and middleware, which must bridge distinct transaction behaviors for users who expect portability.

What to watch next

Wallet developers and cross-network builders should watch for how EIP-8141-based “Frame Transactions” and Base’s EIP-8130 Keystore model evolve into production-ready interfaces, and whether any new compatibility layer emerges to reduce fragmentation. The next milestone will be less about theoretical AA support and more about how transaction formatting differences are surfaced—or hidden—from users and developers in real tooling.