Ethereum and Base Split the Account Layer Wallets Must Bridge

Ethereum and Base ended a joint native account abstraction project the week of September 7, 2026, and will now ship two transaction types instead of one. Ethlabs researcher Derek Chiang said the authors of EIP-8130 and EIP-8141, known as Frame Transactions, stopped after every technical fix asked one side to yield a core goal.

The features users notice were never the fight. Passkeys, batched calls, and gas paid by someone else still sit on both roadmaps. What broke is when a chain is allowed to check that a transaction is valid, and how much of that check the protocol can see in advance.

Neither Side Would Yield Its Core Goal

Chiang, who is listed as a co-author on Frame Transactions and had been trying to keep the two drafts in one room, posted the break on September 14, 2026. He wrote that the EVM had held L1 and L2s together through a standard account (the EOA) and a standard fee market (EIP-1559), and that a shared account-abstraction type would have done the same for smart accounts, including post-quantum ones.

That shared type did not survive contact with what each chain actually needs to be. Chiang’s label for Ethereum L1 is CROPS: censorship-and-capture resistance, open source, privacy, and security. L2s, he said, are being built for scale, customization, and compliance, the constraints commercial and enterprise apps bring to a sequencer.

Both sides still want gasless flows and passkey wallets. They split on what those features have to obey. L1 wants transactions that stay uncensorable, private, and quantum-resistant, with accounts that developers can extend without asking the chain for a permission. L2s want validation that stays cheap, bounded, and readable so the protocol can say which accounts and transactions are allowed.

So separate ways we went, putting the burden on wallets to deal with the fragmentation that ensues.

Derek Chiang, Ethlabs researcher, on X

He also said interoperability lost to product goals. Ethereum wanted the best version of Ethereum, Base wanted the best version of Base, and a common spec would have forced at least a small compromise on one of those.

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

When Validation Runs Is the Whole Dispute

The August 25, 2026 note Chiang published for Ethlabs is the cleanest map of the remaining gap. After weeks of mutual patches, Frames had grown a “pure function” validation path that looks like Base’s authenticators, and EIP-8130 had grown an L1 profile that can accept non-canonical authenticators. The drafts were converging. The order of operations was not.

EIP-8130, titled Keystore Accounts, was filed on October 14, 2025 by Chris Hunter of Coinbase. It adds a new transaction type plus an onchain configuration contract. An account registers actors against authenticator contracts. A transaction names the authenticator it will use, so a node can reject unknown checkers before it runs wallet code. Hunter’s onchain Keystore Accounts draft says no EVM opcode changes are required, and that nodes filter on authenticator identity instead of simulating arbitrary bytecode.

The initial canonical set is small on purpose: k1 (secp256k1), p256, passkey (WebAuthn / FIDO2), and delegate. Under the L2 profile, that set is the only path onto the hot transaction pipe, at a constant enshrined cost. Under the L1 profile the same set still gets the cheap path, but other authenticators can come in through a bounded STATICCALL. New schemes on L1 still want a hard fork to join the enshrined set. That is the permissionless-innovation problem Chiang flagged for Ethereum.

Frame Transactions take the other bet. The official draft, created January 29, 2026, defines a new type 0x06 frame transaction as a list of contract calls. A frame can validate the sender, approve gas, or run the user’s calls. Intrinsic cost is 12,000 gas, plus 475 gas per frame, with a cap of 64 frames. Modes are DEFAULT (0), VERIFY (1), and SENDER (2). Protocol-checked signatures include secp256k1 at 2,800 gas and P256 at 6,700 gas, with an ARBITRARY bucket for schemes the EVM still has to interpret.

Chiang’s remaining distinction is timing. In 8130, validation is structured: it happens first, then execution. In 8141, validation can happen in any frame, including after the interesting work. That is how an account with memecoins and no ETH can swap first and pay after, or pull ETH out of a DeFi position and settle the bill at the end. It is also why those flows cannot live safely in the public mempool. State that changes under you can invalidate the check, so 8141 pushes the wild cases toward extra mempool rules and private builder paths.

THE TWO NATIVE ACCOUNT DESIGNS

L2s worry that frame validation is EVM code with an unknown gas bill, and that nodes must retrace it if the state it touched moved. L1 worries that a whitelist of authenticators freezes account design behind hard forks. Those are not the same bug. They are two products sharing a virtual machine.

Hegotá’s Headliner Is Frame Transactions

L1 is not waiting for a merger that no longer exists. On the August 27, 2026 All Core Developers Execution call (ACDE 244), EIP-8141 moved from Considered for Inclusion to Scheduled for Inclusion in Hegotá, the upgrade after Glamsterdam. Glamsterdam is aimed at the fourth quarter of 2026. Hegotá is the 2027 fork.

nixo.eth, who helps coordinate Ethereum upgrades, wrote the same day that core developers wanted account abstraction in Hegotá even if the exact implementation was still in play. Scheduled status, in that note, meant the fork’s calendar depends on shipping AA. It did not freeze the current spec, the transaction type, or even the EIP number. Chiang, who had argued against SFI-ing Frames that afternoon, later accepted that reading: Ethereum will ship native AA in Hegotá, and the collab with 8130 was still allowed to change what that AA looks like. The collab then ended anyway.

The draft on the EIP site is still marked Draft. Authors include Vitalik Buterin, lightclient, Felix Lange, Yoav Weiss, the long-running ERC-4337 group, Chiang, Toni Wahrstätter, and Stavros Vlachakis. Motivation text puts a native off-ramp from today’s elliptic-curve signatures toward post-quantum schemes, key rotation, batch calls, and fee payment without a centralized relayer. An account, in that writeup, is an address with code.

That is the L1 clock. A Base engineer, writing after Chiang’s post, put the same clock in plainer words: Frames, as written, are “at least a year out.”

THE ACCOUNT ABSTRACTION PATH TO THIS SPLIT

1. March 2023: ERC-4337 goes live as an extra mempool of UserOperations, with bundlers and an EntryPoint contract, and no consensus change.
2. May 7, 2025: Pectra ships EIP-7702, letting an existing EOA borrow contract code for a transaction without moving to a new address.
3. October 14, 2025: Hunter files EIP-8130 as Keystore Accounts, aimed at native AA that nodes can filter without running wallet code.
4. January 29, 2026: Frame Transactions land as EIP-8141, a type 0x06 list of programmable frames.
5. July 17, 2026: Base engineering says EIP-8130 will launch on Base in the Cobalt upgrade that September, then on OP Stack chains later in 2026, with Vibenet as the public testbed.
6. August 27, 2026: Core developers schedule EIP-8141 for Hegotá, with a public caveat that the shipped AA may still change.
7. Week of September 7, 2026: The 8130/8141 collab ends. Chiang reports it on September 14. Base engineering says 8130 still ships later in 2026.

The through-line is a decade of trying to make accounts programmable without forking the base chain, followed by two native designs that no longer fit in one envelope.

8130 Is Ready, Frames Are a Year Out

Lukas, who works on engineering at Base, replied a few hours after Chiang. Base, he said, is still going to ship EIP-8130 in an upgrade later in 2026. Batch transactions, gas abstraction, several performant key types, key rotation, and a path to post-quantum auth remain the pitch. The line that matters for sequencing is that 8130 is “ready to be implemented today,” while 8141 is, on an optimistic read, a year away.

And most importantly, optimistically it’s at least a year out.

Lukas, engineering at Base, on X

Base is proceeding with our plans to ship EIP-8130 in an upgrade later this year. As a reminder, this will unlock features many users and developers have been excited about like:

– Batch transactions

– Gas abstraction

– Multiple (performant) key types

– Key rotation

– Path…

— Lukas (@0xlsr) September 14, 2026

He also said the collab was not wasted. The teams found ways to express Keystore accounts on Frames without giving up the performance 8130 wants, which is why Base does not treat 8130 as a one-way door. A chain that ships it can still add 8141 later. The complaints he listed about Frames are operator-shaped: arbitrary account-defined authentication, two-dimensional gas accounting, and fee payment that has to be composed as frame prefixes instead of sitting in explicit fields with defaults.

Jesse Pollak, Base’s first builder, boosted that note the same evening and said Base still wants Frames and 8141 to work well with the EVM for everyone. That is a sequencing split more than a blood feud. It is still a split users will live inside for a long time, because Hegotá is a 2027 L1 event and Base is trying to land native AA on an L2 clock.

The July 17, 2026 Base engineering post, written by Hunter, had aimed EIP-8130 at Cobalt in September 2026, with Optimism, Coinbase, and WalletConnect as partners, and Vibenet as the early network. Current Base documentation still describes the spec as experimental and running on that vibenet devnet. The public promise on September 14 is the later-2026 upgrade, not a mainnet block number.

The cost argument Base published in July is specific. On the figures in that post, a USDC transfer on the ERC-4337 path takes 125,000 gas and 1,090 bytes. The native AA path takes 46,000 gas and 180 bytes, which Base puts at a cut USDC transfer gas 63.2% and an 83.4% cut in bytes. A passkey-sponsored USDC transfer falls from 173,000 gas and 1,940 bytes to 68,700 gas and 890 bytes, a 60.3% gas cut. Hunter wrote that native AA more than halves the per-transaction cost users paid under ERC-4337 without dropping Base’s scaling targets.

WHAT BASE MEASURED AGAINST ERC-4337

• Plain USDC send: 125,000 gas and 1,090 bytes on ERC-4337, versus 46,000 gas and 180 bytes with native AA.
• Passkey, sponsored: 173,000 gas and 1,940 bytes on ERC-4337, versus 68,700 gas and 890 bytes with native AA.
• Portability claim: the same account configuration is meant to work on chains that never adopt the 8130 transaction type, by falling back to ERC-4337 bundlers.
• Wallet pitch: existing wallets keep working; adding native AA is how they sell subscriptions and ERC-8168 payer services.

Those numbers are why Base will not sit on its hands until Hegotá. They are also why a wallet that only speaks Frames will be late to the L2 that actually has the users.

Wallet Software Becomes the Compatibility Layer

Chiang offered the ecosystem two jobs, and said he is more bullish on the second. One is a coordination body broader than All Core Devs, where only L1 client teams vote, so L2s can shape shared EVM resources instead of forking. The collab was a trial run of that job. He thinks it started too late, after L1 had already rallied around Frames.

The other job is to accept that L1 and L2s will keep different native types, and to spend the engineering on wallets and apps that speak both and hide the difference. That is the path that puts the bill on wallet teams. It is also, in his telling, where wallets can compete.

TWO WAYS TO LIVE WITH THE SPLIT

• Govern the shared EVM: bring L2s into a process that can bind L1 client teams on account and transaction design, so the next native feature does not fork at the envelope.
• Hide two types in software: keep 8130 and 8141 as native chain formats and make the wallet the place a user still sees one account, one passkey, one batch button.
• Treat 8130 as a temporary L2 face: ship Keystore accounts now, keep a documented path to express them as frames later, and hope Hegotá does not strand the addresses.

App teams already know what dual-stack work looks like. A client that talks to Base and to L1 will have to pack two envelopes for the same human action, the same way ERC-4337 UserOperations and plain ETH transfers already sit side by side in a lot of code. The extra work is real even when the user never sees a hex type. That is the cost Chiang placed on wallets, and it is the cost that does not show up in a gas table.

Pedro Gomes, founder and director of WalletConnect, which is named as a partner on Base’s native AA push, called Chiang’s post good news. L2 rollups, he wrote, should not wait for L1 to deliver the better UX, and he wants EIP-8130 on Base, Optimism, Arbitrum, Polygon, Monad, and the rest. That is the L2-first reading: native AA as a rollup product, with L1 following on the Hegotá calendar.

If wallets actually mask the gap, users get passkeys and sponsored gas on both sides and never learn the EIP numbers. If they do not, the next year-plus is two “Ethereum accounts” that do not pack the same, on chains that still advertise themselves as EVM. Chiang’s optimistic case depends on software quality, not on another breakout call.

ERC-4337 Bought Time the Protocol Just Spent

Account abstraction has been an Ethereum goal since the chain was new. The 2023 answer was to stop waiting for a hard fork. ERC-4337 put smart-account validation in a contract and a separate mempool. It worked, and it left bundlers, extra bytes, and extra gas on the table. EIP-7702 then let yesterday’s EOA act like a contract for a single transaction. Both were peace treaties with the old account model.

Native AA ends that truce in two different ways. Base’s version keeps authentication in a small, named set of checkers so a high-throughput chain can price and admit transactions without tracing wallet code. Ethereum L1’s version keeps the checker in the EVM so the account layer can grow without a hard fork for every new scheme, including the privacy and post-quantum designs CROPS implies. Same slogan, opposite constraints.

The second-order result is not that passkeys fail. It is that “EVM compatible” no longer includes a single native way to prove who you are and who pays. For a stretch that runs from Base’s 2026 upgrade through Hegotá in 2027, and maybe after if 8130 accounts only later sit on frames, the compatibility layer is a wallet. Chiang’s closing line was that Ethereum is the art of staying together while remaining different. The next test of that line is whether a passkey on Base and a frame on L1 still feel like one account.

Base can still add Frames after it ships Keystore accounts. L1 can still change what Hegotá actually activates. Until one of those happens, the two native types are the design, and the people who have to make them feel like one product already have the spec numbers.

Disclaimer: This article is news reporting and analysis of Ethereum and Base protocol drafts, developer calls, and public posts. It is informational only and is not investment, trading, legal, or tax advice, and it is not a recommendation to buy, sell, or hold ETH or any other asset. Readers who plan to build wallets, apps, or infrastructure on these drafts, or to make financial decisions around them, should consult a qualified software engineer and a licensed financial adviser. Figures, fork dates, and spec details reflect the cited primary documents and posts as of September 14-15, 2026 and can change as the drafts and upgrade plans move.