Ethereum and Base End Account Abstraction Collaboration
Ethereum and Base developers have abandoned an effort to create a shared account abstraction standard, according to Ethlabs developer Derek Chiang.
The collaboration was intended to bring together two competing proposals: Base-led EIP-8130 and Ethereum's EIP-8141, known as Frame Transactions. Both proposals seek to make blockchain wallets easier to use by supporting features such as alternative gas-payment mechanisms, transaction batching and more flexible authentication.
Chiang said in a September 14 post that discussions between the two sides ended the previous week after developers failed to reconcile their priorities. Rather than continue toward a single design, Ethereum and Base will now pursue their respective proposals independently.
Different Priorities Drove the Split
The disagreement is not centered on whether account abstraction is useful. Both sides are working toward a more flexible wallet model, but their priorities have increasingly diverged.
According to Chiang, Ethereum is prioritizing censorship resistance, privacy and security, while Base is focusing on scaling, customization and compliance. The different objectives made it difficult to find technical compromises that neither side considered too costly.
Chiang said the teams identified several possible technical solutions, but each required one side to compromise on important goals. The result is that wallet developers could ultimately have to handle the fragmentation created by separate standards.
What Account Abstraction Changes
Account abstraction is intended to move Ethereum wallets beyond the limitations of traditional externally owned accounts. Instead of requiring every transaction to follow the same private-key and ETH-payment model, smart-account systems can introduce more flexible authentication and transaction handling.
One practical benefit is gas sponsorship. A user could potentially interact with an application without personally holding ETH for every transaction, while another party handles the network fee. Account abstraction can also support features such as batching multiple actions into one transaction and using alternative authentication methods, including passkeys.
Ethereum's own developer documentation explains that EIPs are the mechanism through which proposed protocol standards are discussed and developed, with Core EIPs covering changes that require network-wide consensus changes.
Ethereum.org
EIP-8141 Takes the Ethereum Path
Ethereum's proposal, EIP-8141, introduces a new transaction structure called a Frame Transaction.
The draft proposal describes a transaction as a sequence of programmable frames. These frames can separately handle transaction validation, gas-payment approval and execution of the user's requested operations. The design aims to provide native account abstraction rather than relying entirely on external infrastructure.
The official EIP-8141 specification lists several intended benefits, including alternative fee-payment schemes, key rotation, batch processing and a pathway toward post-quantum-secure authentication. It describes the broader goal as making an account effectively an address with code.
Ethereum's direction for EIP-8141 has also become clearer. The Ethereum Foundation Protocol team included Frame Transactions among the headline components of the planned Hegotá upgrade, alongside EIP-7805's Fork-choice enforced Inclusion Lists. The foundation said the two headline components need to ship safely together and be tested for their interaction. (
Ethereum Foundation
EIP-8130 Takes a Different Approach
Base's EIP-8130 takes a different technical route.
The proposal introduces a new transaction type together with an onchain Keystore designed to provide account abstraction through custom authentication, transaction batching and gas sponsorship. The Keystore maintains account configuration and approved authenticators, while transactions specify the authenticator used to validate them.
The official EIP-8130 draft also describes two adoption profiles: one intended for base-layer networks and another designed for L2 or high-throughput EVM environments. The L2 profile allows greater flexibility around gas schedules and the set of accepted canonical authenticators. The proposal is designed with portability in mind. Its specification says the account infrastructure can be shared across EVM chains, although chains that do not support the native 8130 transaction type would need another transport mechanism, such as ERC-4337.
Wallet Developers Could Face New Complexity
The immediate consequence of the split may fall on wallet developers rather than ordinary users.
If both EIP-8130 and EIP-8141 are deployed as planned, wallets that want to provide native account abstraction across Ethereum and Base could need to support two different transaction formats and implementation paths.
That does not necessarily mean users will experience two completely separate wallet experiences. Developers could build abstraction layers that hide the technical differences. But maintaining compatibility across the two standards could add engineering work and potentially make cross-chain account abstraction more complicated.
Chiang acknowledged this trade-off, saying that if both standards are implemented successfully and wallet developers can bridge the resulting fragmentation, users could still end up with a strong overall experience.
Security and Privacy Remain Central to Ethereum
Ethereum's decision to continue with EIP-8141 reflects the network's broader protocol priorities.
The Ethereum Foundation's September protocol-priorities update says the protocol team's mandate centers on censorship resistance, open source and freedom, privacy, and security, collectively referred to as CROPS. EIP-8141 is positioned within that broader protocol strategy rather than simply being a wallet-UX upgrade.
The proposal also has a security-oriented component through its support for different authentication mechanisms. The EIP's canonical authenticator set includes secp256k1, P-256, WebAuthn/passkeys and delegated authentication, allowing accounts to become more flexible around how users authenticate transactions.
That design is particularly relevant to Ethereum's longer-term effort to make accounts more adaptable as cryptographic requirements evolve.
Base Prioritizes Scaling and Customization
Base's approach reflects the different environment in which an Ethereum Layer 2 operates.
As an L2, Base can prioritize throughput, customization and application-specific requirements while still settling to Ethereum. EIP-8130's adoption-profile design explicitly provides flexibility for L2 networks to use configurable parameters and maintain a canonical set of authenticators appropriate to their environment.
This does not mean the two proposals are incompatible at every level. Both are attempting to solve many of the same user-facing problems, including better authentication, transaction flexibility and gas sponsorship. The divergence is primarily about how those capabilities should be implemented at the protocol level.
What the Split Means for Ethereum's Ecosystem
The decision marks an important moment in the development of account abstraction across the Ethereum ecosystem.
For users, the long-term objective remains largely unchanged: wallets that are easier to operate, support more flexible authentication and reduce the need to manually manage ETH for every transaction. The technical fragmentation may remain mostly invisible if wallet developers successfully build compatibility layers.
For developers, however, the split creates another standardization challenge. Ethereum's ecosystem has historically benefited from common standards that allow applications and wallets to work across multiple EVM environments. Two native account-abstraction approaches could make that interoperability more complicated.
The outcome will ultimately depend on adoption. If Ethereum and Base each implement their proposals effectively and wallet providers support both, users may still receive a seamless experience. If wallet support fragments, developers and users could face additional complexity.
For now, the two networks are moving forward separately: Ethereum with EIP-8141 Frame Transactions and Base with EIP-8130 Keystore Accounts. The breakdown of their joint effort does not end the push toward account abstraction, but it does mean the Ethereum ecosystem will have to navigate two different paths toward the same broader goal.
