A collaboration aimed at reconciling Base-led EIP-8130 with Ethereum’s EIP-8141 Frame Transactions ended last week, according to Derek Chiang, the founder of ZeroDev and a developer at Ethlabs. With that effort over, the two sides are now set to pursue separate native account abstraction standards.
Ethereum’s 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 practice, incompatible native transaction types would push more integration work onto wallet and application developers. Chiang said the failed effort was “putting the burden on wallets to deal with the fragmentation that ensues,” while also arguing that software could still hide those differences from users.
How the two proposals diverge
Account abstraction lets smart-contract accounts define their own validation logic instead of relying only on the fixed rules that apply to externally owned accounts. The final ERC-4337 standard already enables account abstraction without changing Ethereum consensus rules: users submit UserOperation objects to a separate mempool, and bundlers package them into transactions sent to an EntryPoint contract.
The two newer drafts both move account abstraction functions into native transaction handling. They do not do it the same way.
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 determine what validation work is required and reject unknown authenticators before executing arbitrary wallet code.
The 8130 draft also defines an L1 profile and an L2 profile. The L1 profile accepts authenticators more permissively, while the L2 profile limits its native transaction path to a canonical authenticator set. The goal is to give high-throughput chains more predictable validation costs while preserving a common baseline for wallets.
EIP-8141 takes a different route. It breaks a transaction into a sequence of “frames,” meaning contract calls that validate the transaction, approve gas payment, and execute user operations. Under that design, accounts can use EVM code to define validation and gas-payment rules, with support for key rotation, batched calls, and alternative fee payments.
Ethlabs has framed the tradeoff this way: permissionless, EVM-based validation gives Frame Transactions more flexibility for privacy and future signature systems, but dynamic validation costs can create challenges for high-throughput Layer 2s. EIP-8130 puts the emphasis on more predictable validation by making the authenticator explicit before execution.
Portability remains, but at a higher layer
The EIP-8130 draft still treats portability as a major concern. It says accounts can operate 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.
That means the reported split would not necessarily make an 8130 account unusable on another EVM chain. Even so, if EIP-8130 and EIP-8141 advance on separate tracks, the effort to establish one shared native transaction format for Ethereum and Base would come to an end. Wallets and apps would then need to choose the right transaction transport and validation rules for each chain.
Two possible responses
Chiang outlined two responses. One is to expand coordination around resources shared by Ethereum and Layer 2s. The other is to accept protocol differences and build wallets and applications that abstract those differences away from users.
For now, Ethereum’s official EIP registry still lists both EIP-8130 and EIP-8141 as drafts.