Ethereum’s debate over how to implement native Account Abstraction is taking a new turn. According to a discussion thread on the Ethereum Magicians forum, the original core proposal, EIP-8130, is being restructured into three composable Ethereum Improvement Proposals: EIP-8398, EIP-8399, and EIP-8400.
Two competing approaches shaped the dispute
Account Abstraction is designed to make smart contract accounts first-class citizens on Ethereum. That would let accounts define their own validation logic and support features such as social recovery, gas sponsorship, and batched transactions. Today, the most widely used approach is ERC-4337, which relies on off-chain bundlers. Native AA, by contrast, aims to move support into the protocol itself.
The disagreement has centered on what that protocol-level support should look like. One camp, represented by EIP-8130, has pushed a keystore-based model. It uses a whitelist of trusted validators to manage signature verification. Its main appeal is that verification costs stay predictable and capped, which is seen as especially friendly to Layer 2 networks. It also includes an account standard with policy and session key support, with a focus on simplicity and lower fragmentation.
The other camp has backed Frame Transactions, or EIP-8141. That model allows unstructured validation using arbitrary EVM code at any stage of a transaction. It opens the door to designs such as accounts with no ETH that obtain funds partway through execution. The tradeoff is broader flexibility and room for innovation without a hard fork, but also a greater risk of fragmentation. Some advanced use cases would also require a private mempool.
Ethlabs’ Derek Chiang previously compared the two approaches in an article titled 8130 vs Frame Transactions, framing the issue as a choice between controllable simplicity and maximum flexibility.
EIP-8130 is being broken into EIP-8398, 8399, and 8400
On Aug. 27, developer Pedro UID proposed what was described as composable native Account Abstraction. A corresponding GitHub PR, #12248, was opened the same day. The structure splits the feature set into three core EIPs that can be layered together.
- EIP-8398 defines the portable account keystore layer, including actors, validators, account configuration, account creation, and cross-chain portability.
- EIP-8399 builds on 8398 and introduces native AA transactions under transaction type 0x79, while adding batching, transaction sponsorship, and ordered nonces.
- EIP-8400 depends on the first two proposals and adds policy support, account locking, and nonce-free transactions that use the same transaction envelope.
The original EIP-8130 remains intact in the discussion, but is now treated as the predecessor to these three complementary specifications.
A modular design offers a middle path
Breaking one large proposal into three composable modules changes the adoption model. Different chains or development teams could choose only the layers they need, rather than taking an all-or-nothing route.
One interpretation inside the community is that the flexibility-focused Frame approach has broadly gained ground, while the keystore ideas favored by the Layer 2 camp have also been folded into the design. In that reading, neither side fully lost. The split proposal works more like a framework that absorbs both sets of priorities.
The proposals are still under discussion
For now, the shift remains at the EIP proposal and community discussion stage. It has not become Ethereum’s final approach to native Account Abstraction. What happens next will depend on whether core developers move these three specifications into a formal upgrade path.