The AA Schism: Base's EIP-8130, Ethereum's EIP-8141, and the Compatibility Debt Nobody Booked

Hook

There is a particular kind of invoice that gets issued when a standards effort splits, and it is never mailed to the party that did the splitting.

According to Derek Chiang — founder of the smart account infrastructure firm ZeroDev, formerly of Ethlabs — a collaboration between Base and Ethereum core contributors on native account abstraction broke down, and both sides are now advancing independent transaction-level proposals. EIP-8130 is attributed to the Base side. EIP-8141, described as "Frame Transactions," is attributed to the Ethereum side. That is the entire public record: one person's account, two proposal numbers, no joint statement from either party, no merged specification, and no reference implementation anyone outside those rooms can point to and run.

The interesting part is not the divorce. It is where the bill gets mailed — and whether the address on the invoice has ever been audited.

Context: What Account Abstraction Was Supposed to Settle

Account abstraction is a clumsy term for a precise problem. Ethereum has two classes of account, and only one of them can be programmed.

An externally owned account is a keypair. Its validity rule is fixed by consensus — sign with secp256k1, recover an address, compare, check the nonce. You cannot change that rule. You cannot batch two actions into one atomic transaction. You cannot pay fees in anything but ETH. You cannot delegate spending authority with a scope and an expiry. You cannot recover the account when the key is gone. A smart contract account can do all of it, because its validation logic is code. But a smart contract account cannot originate a transaction. It can only be called by something that can.

ERC-4337 was the workaround. It did not touch the protocol. It introduced a parallel pipeline: users sign UserOperation structs, bundlers package them, and a singleton EntryPoint contract validates and executes them. Signature verification, sponsorship, nonce handling, and fee payment all happen one layer above the EVM's own transaction validity rules. The protocol sees an ordinary transaction from a bundler EOA to an address. Everything the user actually cares about is enforced somewhere else.

That design has held up remarkably well. It is also a confession — the most consequential transaction semantics in the ecosystem live in a deployed contract whose address varies per chain, whose interfaces are versioned by the community rather than the protocol, and whose validation path the protocol cannot reason about natively.

I have a habit, formed early, of reading the specification before the announcement. In 2018 I spent six weeks with the EGEcoin token contract and came out with three reentrancy paths and an integer overflow that would have drained roughly $50,000 in ETH — not because I was clever, but because I read the code the marketing never mentioned. That habit has never once produced a worse decision. So when a story arrives carrying two EIP numbers and no text, the first thing I do is check whether the artifacts actually resolve.

Core Analysis

What "native" actually moves

Native account abstraction — and here the word is doing real work — moves account validity rules into the transaction validity predicate. Not into a contract the protocol calls. Into the predicate the protocol itself evaluates when deciding whether a transaction is includable in a block.

That is a far larger change than it sounds, and its size is easy to underestimate because the framing sounds incremental. It is not incremental. The following subsystems all hold opinions about the transaction validity path, and all of them would have to be rewritten or re-governed:

• Mempool admission policy — what a node will relay before it has seen a block.
• Simulation — what eth_call and debug_traceCall return for a transaction that has not executed.
• Gas estimation — how a wallet computes limits for a transaction whose cost is determined by code it has not run.
• Fee markets — whether a transaction can be sponsored, by whom, and under what policy.
• Block building — what a builder must verify before including a transaction in a bundle.
• Censorship resistance — whether a transaction that is valid can be selectively excluded.

ERC-4337 answers each of these in the application layer, one at a time. It caps validation gas. It restricts storage access during validation. It leans on bundler-side simulation to prevent griefing, and it exposes paymasterAndData as an explicit opt-in to third-party fee payment. Those are engineering answers, and they can be patched by shipping a new EntryPoint.

A native design has to answer the same six questions as consensus rules — which means the answers are harder to change and the mistakes are harder to un-ship. That asymmetry, not performance, is the whole game.

Frame Transactions, and an identifier that does not resolve

EIP-8141 is described as "Frame Transactions." I want to be careful here, because a name is not a specification, and names chosen during a fight are frequently chosen to win it.

If the name is honest, the model segments a transaction into ordered frames — plausibly a validation frame that establishes authority, an execution frame that carries the calls, and a post-execution frame that settles fees, refunds unused gas, or runs cleanup. Anyone who has written a state machine for account recovery will recognize the appeal: it makes the account's lifecycle phases explicit instead of packing them into a single validateUserOp call with a ValidationData tuple as the return channel. Explicit phases are auditable phases. I have written that finding often enough that it is nearly a reflex.

But I cannot verify any of it. Which brings up something that bothered me before I finished the first paragraph.

Ethereum's assigned EIP numbers sit in roughly the 7000–7700 range as of my last check. EIP-8130 and EIP-8141 sit well above that window. Either the reporter is paraphrasing internal or draft identifiers, the proposals live in a namespace I am not indexing, or the numbers are attached to something other than what the article implies. I flag this the way I would flag an unverified address in an audit report: an identifier that does not resolve is a finding, not a footnote. It does not mean the story is false. It means the story is not yet checkable — and a story about a standards process that cannot be checked against the standards repository is a story about a rumor with good posture.

Everything downstream of that paragraph depends on resolving it.

The fault line I would bet on

If I had to name the disagreement without seeing either document, I would name two candidates, and they are not mutually exclusive.

One candidate is the account model. Base is an OP Stack rollup with a centralized sequencer and a design culture that optimizes for cheap verification, aggressive gas metering, and predictable inclusion. Ethereum L1 has to serve a heterogeneous mempool, a PBS supply chain, and an adversary who is actively trying to make validation expensive. If an L2 wants to let a smart account pay fees in an ERC-20 through a sponsor, that is tractable when validity is a single deterministic predicate over a fixed struct. If L1 wants the same feature, it has to preserve DoS resistance against arbitrary validation logic — the same constraint that forced ERC-4337 to restrict storage access during validation and lean on simulation. Those two objectives do not converge naturally. They diverge at the exact point where the standard is being written.

The other candidate is the validation boundary: how much authority the protocol retains to constrain what an account's validation code is permitted to do, versus how much it delegates to the account. Delegate too much and you have reinvented an unpatched pseudo-EVM inside the mempool. Delegate too little and smart accounts become a gated feature with a committee deciding which patterns ship.

I would put money on the first. Fragmentation of this kind is rarely about philosophy. It is about whose execution environment the spec was written for.

The precedent that actually matters: 3074 versus 7702

This fight has a dress rehearsal, and the industry is behaving as if it does not remember it.

EIP-3074 proposed giving an EOA control of a contract through two new opcodes, AUTH and AUTHCALL, backed by a separate authorization signature scheme and a fresh commitment format. EIP-7702 proposed the same outcome — let an EOA delegate execution — by setting the EOA's own code to a delegation designator, reusing the existing typed transaction envelope. No new opcodes. No new precompile semantics. No parallel authorization namespace that every client, indexer, and explorer would have had to learn.

7702 won. It won for reasons that were almost entirely structural rather than ideological: it minimized the surface area of state-model perturbation. Ethereum's selection pressure rewards proposals that reuse existing envelopes and punishes proposals that create new ones, regardless of which design is more elegant on a whiteboard.

That gives me a working prior for 8130 versus 8141. If one proposal introduces a genuinely new transaction type with new validity phases, and the other configures an existing account to carry more of the logic, the second one has the historical advantage — and it has it whether or not the arguments for the first are better.

It also raises a question the coverage is not asking. EIP-7702 is already live. EOAs can already delegate to smart account code. The fight over whether smart accounts exist in Ethereum is over; the fight over the envelope above them has barely started. Those are different problems with different stakeholders, and conflating them is how a two-month standards dispute gets written up as a crisis.

Itemizing the bill

The coverage frames the split as a loss of coordination. That is accurate and useless. The useful framing is accounting: who actually pays, and in what currency.

Every item below has to support two validity models, on every chain it touches, for as long as both models persist:

| Layer | What must be duplicated | Nature of the cost | |---|---|---| | Client libraries | Serialization, signing, decoding for two transaction shapes | Engineering hours, one-time plus maintenance | | Wallet firmware | Signature paths, simulation display, fee UX | Slowest to change, highest blast radius | | RPC providers | Node support, trace decoding, estimation endpoints | Recurring infrastructure | | Indexers and explorers | Two decode paths, two validity interpretations | Long-tail correctness risk | | Paymaster and sponsorship engines | Two policy models, two refund paths | Recurring, policy-sensitive | | Multisig and recovery vendors | Two signing ceremonies, two revocations | Security-critical | | Audit firms | Two spec surfaces worth of expertise | Scarcest resource on the list |

Note the shape of this table. It is not one-to-one. Each wallet integrates with many chains, and each chain may support one standard, the other, or both. The compatibility burden multiplies rather than adds, and it lands on precisely the parties with the least leverage to refuse it.

The article is explicit that cross-chain compatibility work shifts down to wallets and applications. That is the correct observation and the wrong conclusion. Work is not shifting down and out. It is shifting down and staying — as permanent maintenance overhead, paid by teams that had no seat in the room where the standard was drafted.

A misallocated attention budget

Set this next to the industry's other obsession and the misallocation becomes embarrassing.

For three years, the modular thesis has directed capital and engineering hours at the data availability layer — Celestia, EigenDA, Avail, and a dedicated DA announcement from nearly every rollup with a blog. Blob space after EIP-4844 targets a handful of blobs per block, and the overwhelming majority of rollups post well below that ceiling. I have said consistently that the DA layer is overhyped: 99% of rollups do not generate enough data to need dedicated DA. They are buying insurance against a bottleneck that does not bind.

Meanwhile, the change that touches every single user of every rollup — the definition of what counts as a valid transaction — is treated as a working-group agenda item. Core developer attention and audit capacity are the scarcest resources in this industry. Allocating them to a non-binding bottleneck while a binding one gets an hour on a call is a portfolio error, and portfolios do not care that the mistake was made with good intentions.

Who is structurally positioned to absorb a split

ZeroDev is a smart account infrastructure company. Its founder is the sole named source for the claim that the collaboration broke down.

I am not making a motive claim. I am making a capability claim, which is a different and much harder thing to argue with: a middleware provider that maintains dual-stack adapters is more valuable after fragmentation than before it. Every additional standard increases the value of the abstraction that hides it. That is not an accusation; it is a dependency graph.

What I am accusing the coverage of is a disclosure gap. There is no counterweight in the record — no statement from Base, no statement from Ethereum core contributors, no EIP repository status change I can cite as corroboration. When I audit a contract and find that a single contributor holds the upgrade key, I do not write "malicious." I write "single point of trust, undocumented." The same language applies here, and it should have appeared in the original piece rather than in a follow-up.

No one calls a standards schism revolutionary. But the narrative economics of a broken collaboration are excellent for the vendors who sell the adapter — and that is the sentence a disclosure section exists to write.

What native AA is sold as, and what it is

The pitch deck for every native account abstraction proposal arrives wearing the word "revolutionary," and it usually lists the same four unlocks: social recovery, sponsored gas, batched execution, and session keys.

Three of those are already shipping today under ERC-4337. Session keys with expiry and scope work. Sponsored gas works. Batching works. The fourth, recovery, works with caveats that are about key management discipline rather than protocol capability.

What actually remains unlocked is narrower and more valuable than the marketing: fee abstraction across asset types, and validity rules that the protocol enforces rather than a contract author promises. That is a real improvement. It is not a revolution, and the vocabulary is doing load-bearing work it was never engineered for.

The adjacent pitches are worse. Dynamic NFTs and programmable royalties have been sold as the reason to care about account programmability for four years running, and the argument has never closed. Artists need stable buyers, not a more complex tech stack; a programmable royalty that settles on-chain is worthless if the secondary market routes around it, and the secondary market has been routing around it since 2021.

The DeFi framing deserves the same skepticism for a different reason. I have argued that Aave's and Compound's interest rate models are arbitrary governance artifacts rather than market discovery — kink points at 80% utilization, base rates and slope parameters set by vote, dressed as a curve. That critique matters less than it sounds, because those parameters are changeable by a governance transaction. Native account abstraction is not. Account validity rules written into consensus are editable only by a fork. Putting a number into a multisig is a liability you can edit. Putting a rule into consensus is a liability you cannot. Those are different risk classes, and the industry is currently treating them as the same line item.

Contrarian Angle: This Is a Verification Failure, Not a Coordination Failure

The consensus reading will be that two engineering teams could not agree, and that fragmentation is the cost of disagreement. I think that reading mistakes the artifact for the event.

Look at what actually exists. No on-chain artifact. No merged specification. No reference implementation. No statement from Base. No statement from Ethereum core contributors. No EIP repository status transition. Two identifiers that do not index cleanly into the numbering range I can verify. One founder, quoted.

We are being asked to update our model of Ethereum's standardization process on the strength of a single named source with a documented structural interest in the outcome. That is not a coordination failure by the two parties. It is a verification failure by everyone else.

The second blind spot is the assumption that fragmentation is strictly negative. It is not. The 3074 versus 7702 contest produced a better result than either original proposal, because competition forced both sides to justify their state-model footprint. Fragmentation is expensive in the middleware layer and productive at the design layer. Both of those are true, and the second does not cancel the first — the cost is real, and it is being paid by parties who were not in the room.

The third blind spot is the assumption that ERC-4337 is a transitional artifact on its way to being replaced. It may be the terminal state. It may be the lowest common denominator that both native proposals end up having to interoperate with, precisely because it is deployed, audited, and running. Standards do not always converge on the newest design. They frequently converge on whichever one already has users.

Takeaway

Watch the machine-readable instruments, not the narrative. EIP repository status transitions, from Draft to Review to Last Call or Stagnant. Support matrices in RPC providers and block explorers. Dual-stack adapters appearing in the changelogs of account abstraction SDKs. Those signals will tell you whether the split calcified a full two quarters before the market narrative decides what happened.

The question is not whether Base and Ethereum can agree on a transaction format. The question is whether anyone outside those two rooms has the tooling to verify that they did not.