Ethereum and Base developers have stopped trying to create one shared account abstraction standard after failing to combine EIP-8141 and EIP-8130. The two networks will now continue with separate transaction designs.
The two proposals were designed to make crypto wallets easier to use. They could allow users to make transactions without holding ETH specifically to pay gas fees. They also support newer authentication methods, including phone passkeys.
Developers had been exploring whether one system could work across Ethereum Layer 1 and Base Layer 2. But after several technical discussions, they concluded that combining the two designs would force either Ethereum or Base to give up some of its main goals.
Derek Chiang of Ethlabs said the teams found several possible technical solutions, but each would require one side to compromise. As a result, they decided to move forward separately, leaving wallet developers to deal with the differences.
Ethereum is mainly focused on censorship resistance, privacy and security. Base, meanwhile, is putting more emphasis on scalability, customization and compliance.
If both proposals eventually launch, wallet developers may need to support two different native transaction formats. Users could still get a similar experience, but wallets would have to handle the technical differences behind the scenes.
The split comes only days after developers were exploring ways to make EIP-8141 and EIP-8130 compatible.
EIP-8130 uses an onchain keystore that records approved signers and authentication systems. Transactions identify which authentication method they use, allowing the network to determine how the transaction should be verified.
EIP-8141 takes a different approach. It uses programmable “frames” that can handle different parts of a transaction, including validation, gas payments and execution.
Ethereum will now continue developing EIP-8141 as part of its planned Hegotá upgrade. The Ethereum Foundation Protocol cluster has placed the proposal in its “must-ship” category.
Frame Transactions would divide a transaction into several programmable steps. One frame could verify the sender, another could authorize the account paying the gas, and others could execute the user’s requested actions.
This could allow one account to start a transaction while another account pays the fee.
The system could also reduce the need for users to keep ETH in their wallets just to pay gas. An application could cover the fee, or users could potentially pay through another asset while validators still receive the network fee in ETH.
EIP-8141 could also make transaction batching easier. Several related actions could be placed into one transaction so they either all succeed or are reversed if something goes wrong.
For example, a token trade often requires a separate approval before the trade can happen. With programmable frames, those steps could potentially be handled within the same transaction.
The proposal also aims to make account security more flexible. Instead of relying on the fixed authentication system used by traditional Ethereum accounts, more of the account’s security logic could be handled through programmable code.
This could support alternative signature systems, sponsored gas payments, transaction batching, key rotation and other account controls.
Users could potentially change the authentication method controlling an account without having to move their assets to a new address.
Base, meanwhile, will continue developing EIP-8130 separately.
The Base proposal combines a new transaction type with an onchain keystore that keeps track of approved signers and authenticators. It is designed to support custom authentication, transaction batching and sponsored gas payments.
Both EIP-8130 and EIP-8141 are trying to solve similar wallet and account-abstraction problems, but they take different technical paths.
With the joint development effort now over, EIP-8141 remains Ethereum’s planned account abstraction system for Hegotá, while Base will continue working on EIP-8130.
The biggest change for users may eventually come at the wallet level. If both systems reach production, wallets will need to handle the two standards while trying to give users a simple and consistent experience.
