Base-Ethereum Account Abstraction Collaboration Broke Down, Developer Says

Ethlabs’ Derek Chiang, who founded ZeroDev, said a collaboration to reconcile Base-led EIP-8130 with Ethereum’s EIP-8141 Frame Transactions ended last week, leaving the two sides to pursue separate native account-abstraction standards.

The official Ethereum Improvement Proposal registry lists both EIP-8130 and EIP-8141 as drafts. Ethlabs backs Frame Transactions for Hegotá, which it describes as an upcoming Ethereum hard fork, and says it intends to work with Layer 2s and wallets on a rollout.

In practical terms, incompatible native transaction types would shift more integration work to wallet and application developers. Chiang said the failed effort was “putting the burden on wallets to deal with the fragmentation that ensues,” although he argued that software could still hide those differences from users.

How the Designs Differ

Account abstraction allows smart-contract accounts to define their own validation logic rather than relying only on fixed rules for externally owned accounts. The final ERC-4337 standard provides account abstraction without changing Ethereum’s consensus rules: users submit `UserOperation` objects to a separate mempool, and bundlers package them into transactions for an EntryPoint contract.

Both new drafts move account-abstraction functions into native transaction handling, but they use different control points.

EIP-8130 combines a new typed transaction with an onchain keystore and account-configuration system. It supports custom authentication, batched calls and gas sponsorship. Because each transaction declares its authenticator, nodes can identify the required validation work and reject unknown authenticators before executing arbitrary wallet code.

The 8130 draft defines an L1 profile with permissive authenticator acceptance and an L2 profile that limits its native transaction path to a canonical authenticator set. That structure is intended to give high-throughput chains predictable validation costs while preserving a common baseline for wallets.

EIP-8141 instead divides a transaction into a sequence of “frames,” or contract calls that validate the transaction, approve gas payment and execute user operations. Its design lets accounts use EVM code to define validation and gas-payment rules, with support for features including key rotation, batched calls and alternative fee payments.

Ethlabs has described the central tradeoff: permissionless, EVM-based validation gives Frame Transactions flexibility for privacy and future signature systems, but dynamic validation costs can create challenges for high-throughput Layer 2s. EIP-8130 prioritizes more predictable validation by making the authenticator explicit before execution.

Portability Moves Up the Stack

EIP-8130’s draft still calls portability a top concern. It says accounts can function on EVM chains that do not support the 8130 transaction type by using ERC-4337 or another transport mechanism. It also requires compliant chains to accept a shared canonical authenticator set.

The reported split therefore would not necessarily make an 8130 account unusable on another EVM chain. It would, however, end the effort to establish one shared native transaction format for Ethereum and Base if the two drafts advance separately. Wallets and apps would need to select the appropriate transaction transport and validation rules for each chain.

Chiang outlined two possible responses: broaden coordination over resources shared by Ethereum and Layer 2s, or accept protocol differences and build wallets and applications that abstract them from users. For now, the official EIP registry lists both designs as drafts.