Ethereum core developers and the team behind Base, the Coinbase-backed Layer 2 network, have abandoned efforts to create a single account abstraction standard. The collaboration, centered on aligning EIP-8141 and EIP-8130, broke down last week after both sides concluded that available technical options would force unacceptable compromises on core goals.

Ethlabs researcher Derek Chiang confirmed the split, stating that the networks are now moving forward with distinct approaches to native account abstraction features such as gasless transactions, passkey-based authentication and transaction batching.

Differing Priorities Drive the Separation

Account abstraction aims to make blockchain interactions more flexible by allowing smart-contract-controlled accounts to behave like traditional externally owned accounts. This enables features including sponsored gas payments, alternative authentication methods and multi-step actions within a single transaction.

While both teams shared these high-level objectives, their design priorities diverged. Ethereum Layer 1 developers prioritize censorship resistance, privacy, openness and long-term security for the settlement layer. Base focuses on scalability, configurability and compliance requirements suited to commercial and enterprise environments.

Chiang noted that engineers spent weeks examining possible shared designs. Every pathway would have required one network to adjust key requirements, which neither side accepted. As a result, Base is advancing EIP-8130 while Ethereum proceeds with EIP-8141, also known as Frame Transactions.

Technical Approaches of the Two Proposals

EIP-8141 structures transactions as a sequence of programmable frames. One frame can handle validation of the sender, another can authorize gas payment, and subsequent frames can execute the requested actions. This design allows the account initiating an action and the account paying for it to differ. It also supports transaction batching, alternative signature systems, key rotation and improved readiness for post-quantum cryptography.

Ethereum Foundation protocol researchers have classified EIP-8141 as a must-ship item for the planned Hegotá upgrade. Core developers moved it to scheduled-for-inclusion status during an All Core Developers Execution call, giving the proposal a formal place in the 2027 upgrade roadmap even while its specification remains in draft form.

EIP-8130, developed with Base and other OP Stack networks in mind, combines a new transaction type with an onchain keystore. Accounts register approved signers and authenticator contracts. Transactions identify the authentication method in use, enabling the network to determine validation requirements before executing wallet code. The design supports custom authentication, call batching and gas sponsorship while accommodating programmable compliance controls.

Both proposals seek to reduce friction for users who currently must hold ETH solely to pay network fees. Under the new models, applications could sponsor transactions or allow payment in other assets while validators still receive fees in ETH.

Implications for Developers and Wallets

The separation places additional responsibility on wallet providers and application builders. If both standards reach production, teams will need to support two native transaction formats across Ethereum Layer 1 and Base. Users may experience a consistent interface only if wallet developers successfully abstract the underlying differences.

Chiang outlined two possible responses for the broader ecosystem. One involves expanding governance processes for shared infrastructure such as the EVM to include greater Layer 2 input. The other accepts fragmentation and relies on wallets to bridge the standards. He described the second path as more optimistic, noting that capable teams can deliver strong user experiences despite technical divergence.

Previous shared standards, including externally owned accounts and EIP-1559 fee markets, previously allowed seamless operation across Ethereum and its Layer 2 networks. Evolving requirements around compliance, scalability and security have widened the gap sufficiently that further joint standardization is no longer feasible at this stage.

Coordination may continue in areas that do not require either network to alter its fundamental priorities. Both EIP-8130 and EIP-8141 remain under active development, and their final technical details will determine the precise workload for infrastructure providers.

Ethereum Layer 1 continues to emphasize designs that preserve decentralization and security properties. Base continues refining its approach for high-throughput environments that also require clear distinctions between permitted and restricted actions. The two paths reflect the distinct roles the networks occupy within the broader Ethereum ecosystem.