Ethereum and Base developers have ended efforts to merge two competing account abstraction proposals into a shared standard, setting up a split that could require wallet software to support different native transaction formats across Ethereum’s main network and the Coinbase-incubated Layer 2.
Derek Chiang, a developer at Ethlabs, said discussions around EIP-8130 and EIP-8141 ended last week after the groups reached different conclusions on technical priorities. Base is continuing with EIP-8130, while Ethereum developers are advancing EIP-8141, also known as Frame Transactions, toward a potential inclusion in Ethereum’s Hegotá upgrade.
The separation places wallet developers in the middle of a design dispute over how Ethereum accounts should work. Both proposals seek to make wallets easier to use by enabling features such as passkey authentication, sponsored transaction fees, and batching several actions into one user approval. Their underlying approaches, though, are now diverging.
Chiang said Ethereum’s proposal has been shaped around censorship resistance, privacy, and security, while Base has emphasized scalability, customization, and compliance. Those priorities can lead to different choices over transaction validation, how accounts designate authorized signers, and the extent to which wallet behavior is standardized at the protocol level.
Two paths for native account abstraction
Account abstraction shifts more wallet logic into programmable accounts, allowing users to replace the familiar model of a single private key signing every transaction. A wallet could instead use a phone passkey, set spending rules, permit recovery through pre-approved methods, or allow another party to cover network fees.
Ethereum already supports many account abstraction-style features through smart contracts and infrastructure built around ERC-4337. The current proposals aim to make those capabilities more native to the transaction layer, reducing reliance on separate systems that package and relay user operations.
EIP-8141 proposes a framework in which a transaction is made up of programmable “frames.” Each frame would perform a defined part of the transaction process, including validating the sender, selecting the gas payer, and carrying out the intended actions. The structure is intended to support a range of authentication systems and payment arrangements without requiring each wallet to create its own transaction framework.
EIP-8130, led by Base, also introduces a new transaction type but centers its design on an onchain Keystore. The Keystore would hold information about an account’s approved signers and authentication methods. According to the proposal’s description, that design would support custom authentication, batched calls, and gas sponsorship.
The difference is more than a naming issue. Separate native formats could mean that a wallet seeking the same user experience on Ethereum and Base would need to integrate, test, and maintain two transaction systems. That work could fall particularly heavily on smaller wallet teams and app developers that already support multiple networks.
Ethereum proposal moves toward Hegotá
EIP-8141 has gained momentum within Ethereum’s protocol-development process. Earlier this month, the Ethereum Foundation’s Protocol cluster placed the proposal in its “must-ship” category in a tier list for the Hegotá upgrade.
That designation signals strong internal support but does not by itself guarantee inclusion in a hard fork. Ethereum upgrade contents are ultimately determined through ongoing coordination among client teams, researchers, and core developers, with implementation and testing constraints often narrowing the final scope.
Vitalik Buterin, Ethereum co-founder and a co-author of EIP-8141, has described the proposal as an attempt to consolidate unresolved account abstraction problems into one architecture. In a February post on X, Buterin called it an “omnibus that wraps up and solves every remaining problem that AA was intended to address.”
In a Sept. 5 post on X, Buterin said EIP-8141 had made “a lot of important progress” over recent months and had moved “close to optimal.” The proposal has also been framed by its authors around long-term security, including readiness for cryptographic changes that may be needed if quantum computing weakens today’s signature schemes.
A modular transaction format could give Ethereum more room to support future authentication methods without repeatedly redesigning basic transaction rules. Its flexibility also raises implementation questions, since client software, wallets, and security tooling would need to interpret and validate a more programmable transaction structure.
Base prioritizes different operational needs
Base’s EIP-8130 reflects a Layer 2 environment with different product and operational pressures. Networks seeking low-cost, consumer-facing transactions often want wallets to offer sponsored fees, streamlined sign-in methods, and account controls tailored to individual applications.
Compliance considerations may also push an ecosystem toward more configurable account-management tools. Chiang’s description of Base’s priorities suggests its developers want a standard that can adapt to product-specific requirements rather than one optimized principally for Ethereum Layer 1’s neutrality and resistance to transaction censorship.
The Keystore design could make it easier for an account to maintain a changing set of approved authenticators onchain. That may appeal to wallets built around passkeys, recovery systems, or multiple signing devices. Yet a dedicated account registry introduces a different architectural choice from EIP-8141’s transaction-frame model.
Neither proposal eliminates the possibility that wallets could eventually support both. Large wallet providers routinely handle differences among chains, but native account abstraction affects the core path through which users authorize and pay for transactions. Supporting two standards would involve more than adding another network endpoint or token list.
Fragmentation becomes a wallet design problem
The immediate effect of the split is likely to be felt first by developers, not everyday users. Wallets will need to decide whether to prioritize Ethereum’s Frame Transactions, Base’s Keystore-based approach, or both. Applications that expect users to move between Ethereum and Base could face different signing flows, recovery features, and fee-payment options depending on which network they use.
The outcome also complicates the goal of making blockchain interactions feel consistent across Ethereum’s expanding ecosystem. A user may be able to pay fees with a sponsored transaction on both networks, for example, while the wallet handles authorization and account configuration through incompatible underlying rules.
Ethereum’s Hegotá process will now be closely watched as EIP-8141 progresses from a favored proposal toward a deployable protocol change. Base’s decision to continue independently with EIP-8130 ensures that account abstraction will remain an active area of competition as well as collaboration between Ethereum’s main chain and one of its largest Layer 2 networks.
For deeper context on Ethereum’s roadmap and upgrades, explore this detailed guide on Ethereum upgrades.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
