Ethereum and Base developers have ended work on a common account abstraction standard after efforts to reconcile EIP-8141 and EIP-8130 failed, leaving the two networks to pursue separate tran
Ethereum and Base developers have ended work on a common account abstraction standard after efforts to reconcile EIP-8141 and EIP-8130 failed, leaving the two networks to pursue separate transaction designs.
SummaryEthlabs developer Derek Chiang said Monday that the authors of the two proposals stopped working toward a shared specification last week after finding that the technical options available would require either Ethereum or Base to compromise on core requirements.
I'm sad to report that the AA collab between 8130 and 8141 (Frames) broke down last week, and Base and Ethereum are now going separate ways to implement different AA standards.I want to share some reflections on this collab and on the future of the EVM.For a long time, the…
— Derek Chiang | Ethlabs (@decentrek) September 14, 2026
Both proposals seek to simplify how users interact with crypto wallets, including allowing transactions without users first holding ETH for gas and supporting authentication methods such as phone passkeys. The teams had been exploring whether one design could serve Ethereum Layer 1 and Base Layer 2.
“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 said. “So separate ways we went, putting the burden on wallets to deal with the fragmentation that ensues.”
Ethereum’s developers are prioritizing censorship resistance, privacy and security, while Base is focusing on scale, customization and compliance, according to Chiang. The differences eventually prevented the teams from settling on one transaction format.
The decision leaves wallet developers facing the possibility of supporting two native transaction formats if EIP-8141 and EIP-8130 both reach production.
Chiang said wallets could still provide users with a consistent experience despite the technical differences between networks, depending on how developers handle the separate standards.
“If they execute well, and if the wallet community can bridge over the fragmentation, we may well end up with the best possible UX for the end users,” he said.
The outcome changes the direction developers were discussing only days earlier. On Sept. 7, crypto.news previously reported that EIP-8141 developers were exploring compatibility with EIP-8130 as they worked on ways to keep transactions programmable while making their authentication requirements easier for infrastructure providers to inspect.
At that stage, Chiang said EIP-8130 could provide defined structures around EIP-8141 frames. The proposed arrangement was intended to preserve the programmable nature of frames while giving wallets and high-throughput networks a clearer transaction format.
You might also like: Ethereum price holds $2,500, but ADX signals weakness
EIP-8130 uses an onchain keystore where accounts can register approved actors and authenticator contracts. Transactions identify the authentication method they use, allowing a network to determine the required validation process before executing wallet code.
EIP-8141 takes a different route by structuring transactions as programmable contract calls called frames. Frames can perform different functions within the same transaction, including validation, gas approval and execution.
The teams have now abandoned the effort to turn those approaches into one standard.
Ethereum is continuing with EIP-8141, or Frame Transactions, as part of its planned Hegotá upgrade.
The Ethereum Foundation Protocol cluster placed the proposal in its “must-ship” category earlier this month, while the source material states that the proposal is intended to make account abstraction native to Ethereum and improve security and post-quantum readiness.
Frame Transactions divide a transaction into a sequence of programmable frames. One frame can validate the sender, another can authorize the account responsible for gas, and subsequent frames can execute the actions requested by the user.
The model would allow the account initiating an action and the account paying for it to be different.
Ethereum developers had already scheduled EIP-8141 for Hegotá by Sept. 7. Core developers moved the proposal from Considered for Inclusion to Scheduled for Inclusion during the Aug. 27 All Core Developers Execution call, giving Frame Transactions a formal position in the planned 2027 upgrade while its specification remained in draft form.
Under the proposed system, an application could cover a user’s transaction fee or arrange for the user to pay through another asset while Ethereum validators continue receiving the network fee in ETH.
The structure could remove a common wallet requirement under which users holding stablecoins or other tokens still need ETH before they can make a transaction.
Frames can be used for transaction batching as well. Related actions could be grouped so that all of them succeed together or are reversed when one fails.
A token trade, for example, can currently require a separate approval allowing an application to spend tokens before the trade itself is executed. Frame Transactions could place related actions within the same programmable transaction structure.
EIP-8141 is designed to move more account validation logic into programmable code instead of requiring conventional Ethereum accounts to depend on a fixed authentication process.
The proposal describes its end state as one where “an account simply becomes an address with code.”
Vitalik Buterin, an EIP-8141 co-author, described the proposal in February as an “omnibus that wraps up and solves every remaining problem that AA was intended to address.”
On Sept. 5, Buterin said the proposal had made “a lot of important progress” over the preceding months and was getting “close to optimal.”
Developers subsequently found that several transaction features could be expressed through programmable EIP-8141 frames instead of repeatedly expanding Ethereum’s transaction envelope.
The Sept. 7 crypto.news report said the approach could handle transaction expiry, signature aggregation, privacy proofs and post-transaction assertions as programmable contract calls. Frame Transactions would still require changes to Ethereum’s consensus rules, but individual functions could be built through frame targets and call patterns.
Programmable validation could give accounts more control over authentication. EIP-8141 is designed to support features including alternative signature systems, sponsored gas payments, transaction batching and key rotation.
The same architecture could help Ethereum accounts move away from dependence on the signature system used by conventional externally owned accounts. A user could potentially change the authentication method controlling an account without transferring the assets to a new address.
Ethereum researchers had been considering Frame Transactions for Hegotá before the proposal was formally scheduled. In August, developers were comparing EIP-8141 with EIP-8130 as competing approaches to native account abstraction while narrowing the scope of the 2027 upgrade.
At the time, the proposals were part of a larger Hegotá selection process covering censorship resistance, privacy, gas pricing, validator economics and Layer 1 scaling.
Ethereum researchers had separately examined how Frame Transactions could support privacy-focused applications. An August proposal discussed self-funded privacy pools in which programmable fee payments could allow a privacy pool to cover its own gas instead of relying on an outside relayer.
That work paired Frame Transactions with other proposed changes including Keyed Nonces, Recent Roots and Transaction Assertions. The privacy-pool proposal remained a researcher’s preferred package rather than a final Ethereum core developer decision at the time.
Base’s EIP-8130 will now proceed separately from Ethereum’s Frame Transactions proposal.
The Base-authored design combines a new transaction type with an onchain “Keystore” that records approved signers and authenticators for an account. It is intended to support custom authentication, call batching and gas sponsorship.
While the two proposals share several account abstraction goals, their technical structures give their respective networks different levels of control over how transactions are authenticated and processed.
Before the teams separated, Ethereum developers had been trying to determine whether EIP-8130’s structured authentication system could be combined with EIP-8141’s programmable frames without forcing either Layer 1 or Layer 2 networks to give up their preferred properties.
Ethlabs had previously placed Frame Transactions among its main priorities for the Hegotá upgrade, citing native account abstraction alongside censorship resistance, faster blocks and continued Layer 1 scaling.
With the joint effort now ended, EIP-8141 remains Ethereum’s planned native account abstraction route for Hegotá, while Base will continue developing EIP-8130 around its separate transaction type and onchain keystore.
Read more: Balancer wind-down proposed as post-exploit revenue fails to recover
