Base-Ethereum Account Abstraction Collaboration Broke Down, Developer Says
A joint effort to reconcile Base-led EIP-8130 with Ethereum’s EIP-8141 Frame Transactions collapsed last week, leaving the two camps to advance separate native account-abstraction proposals. The divergence could shift more cross-chain integration work onto wallets and applications because the drafts define different native transaction formats and validation approaches.
Why It Matters
If the two designs advance independently, there may not be a single native transaction format shared across Ethereum and Layer 2s, increasing the engineering burden on wallets and apps to handle chain-specific transports and validation rules. That outcome affects compatibility and developer effort across the EVM ecosystem.
Key Facts
- Who reported the split: Derek Chiang of Ethlabs, founder of ZeroDev, said the collaboration ended last week.
- EIPs involved: EIP-8130 (Base-led) and EIP-8141 (Ethereum Frame Transactions) are both listed as drafts in the official EIP registry.
- Ethlabs position: Ethlabs backs Frame Transactions for Hegotá, which it describes as an upcoming Ethereum hard fork, and plans to coordinate with Layer 2s and wallets on rollout.
- EIP-8130 key features: Introduces a new typed transaction, an onchain keystore and account-configuration system; supports custom authenticators, batched calls and gas sponsorship; defines L1 (permissive) and L2 (canonical authenticator set) profiles.
- EIP-8141 key features: Splits a transaction into 'frames' (contract calls) that perform validation, gas approval and execution, allowing EVM code to implement validation and gas-payment rules, plus key rotation, batched calls and alternative fee payment.
A planned collaboration to reconcile two competing native account-abstraction drafts — Base-led EIP-8130 and Ethereum's EIP-8141 Frame Transactions — ended last week, according to Ethlabs’ Derek Chiang. With the coordination effort stalled, both proposals remain listed as drafts in the EIP registry and appear set to move forward on separate tracks.
The two drafts take distinct technical approaches to bringing account abstraction into native transaction processing. EIP-8130 pairs a new typed transaction format with an onchain keystore and account-configuration system. It makes authenticators explicit in the transaction so nodes can determine validation requirements before running wallet code, and it specifies L1 and L2 profiles to balance permissiveness with predictable validation costs. By contrast, EIP-8141 breaks a transaction into sequential "frames" — contract calls that validate the transaction, approve gas payment and execute user operations — letting EVM code handle validation and payment logic dynamically.
Ethlabs has framed the trade-offs around flexibility versus predictability: Frame Transactions’ permissionless, EVM-based validation allows more adaptability for privacy and future signature schemes but can produce variable validation costs that challenge high-throughput Layer 2s. EIP-8130 aims to limit that variability by surfacing the authenticator ahead of execution, which can help chains that need predictable validation budgets.
The practical consequence of divergent native formats is greater work for wallets and application developers. Both drafts say portability is a concern — EIP-8130, for example, notes accounts could fall back to ERC-4337 or other transport mechanisms on chains that do not accept the 8130 transaction type — but a split would end efforts to create a single shared native transaction standard for Ethereum and Base. Chiang suggested two responses: expand coordination on shared resources across Ethereum and Layer 2s, or accept protocol differences and build wallet and application layers that abstract those differences away from users.
Keep Reading
Even if Clarity fails, Wall Street’s crypto push is unlikely to stop
Bitcoin slips to $77,800 as Senate Clarity Act vote nears and oil prices climb
U.S. House panel shares crypto tax bill ahead of hearing later this week
