EIP-8141: Why Native Account Abstraction Is Not a Headline Feature in Ethereum's Hegota Upgrade

Written by: imToken

Last week, at the Ethereum core developers meeting, EIP-8141 was formally discussed for inclusion in the Hegota upgrade. The outcome was unexpected: the proposal, personally championed by Vitalik, was not designated as a "headline feature" of Hegota but instead received a "Consider for Inclusion" (CFI) status.

This week, Google’s Quantum AI team released a new white paper stating that, under their given hardware assumptions, the estimated number of physical qubits required to break ECDLP-256 has decreased by a factor of 20 compared to previous estimates. While this does not mean quantum attacks are imminent, it genuinely reminds us that if account systems cannot flexibly update their verification logic in the future, many of today’s discussions around wallet experiences may ultimately evolve into security issues.

From a practical standpoint of protocol advancement, EIP-8141 is still too heavy, particularly in terms of client implementation, transaction pool security, and verification complexity, and has not yet achieved sufficient consensus.

But at this point in time, the aspects of EIP-8141 worthy of discussion and careful examination seem to be increasing.

EIP-8141, spearheaded by Vitalik Buterin, timbeiko, and other core contributors, is officially named Frame Transactions.

In simpler terms, it’s not about adding individual features to wallets—it’s about changing the protocol so that any account is no longer locked into a single ECDSA signature path, but can instead use more flexible verification and execution logic.

This also means that multi-signature, gas sponsorship, key rotation, social recovery, and even future integration of quantum-resistant signature schemes are no longer just external add-ons to wallets, but have the potential to become native members of the Ethereum account system.

On the surface, EIP-8141 discusses a set of highly specific capabilities: paying gas in stablecoins, combining multiple operations into a single transaction, supporting more flexible signing methods, and even reserving space for future quantum-resistant signatures. Over the years, numerous improvements—from ERC-4337 to EIP-7702—have essentially aimed to transform accounts from mere private keys into customizable entry points.

The issue is that these improvements have indeed made wallets increasingly resemble smart accounts, but they have never truly addressed Ethereum’s most fundamental default account model.

It is well known that, under the current system, Ethereum accounts are broadly divided into two categories. One is externally owned accounts (EOAs), which are controlled by private keys and can initiate transactions autonomously but lack programmability; the other is contract accounts, which are smart contracts themselves—they can execute complex logic but cannot initiate transactions on their own.

This has resulted in the ability to initiate transactions being permanently tied to a single private key signature. As long as this assumption remains unchanged, many capabilities that users today take for granted—such as flexibly changing signature rules, allowing others to pay gas fees, recovering account control after losing a private key, or smoothly transitioning to new cryptographic systems in the future—will remain difficult to implement as default account features.

If you've used imToken or other Web3 wallets, you've likely encountered these pain points: having a bunch of USDC in your wallet but being unable to send transactions because gas can only be paid in ETH; losing your seed phrase means permanently losing your funds with no way to recover them; and having to sign and confirm twice for a single “approve + swap” operation.

These issues are not due to the wallet product being "not good enough," but rather a result of the Ethereum account model's inherent design.

From this perspective, the evolution over the past two years has become very clear: ERC-4337 enabled account abstraction to be implemented at the application layer without modifying the protocol; EIP-7702 further demonstrated that EOA accounts are not entirely incapable of extension—they can at least temporarily gain some capabilities similar to smart accounts.

In other words, Ethereum has never been unwilling to pursue account abstraction; rather, it has consistently taken a gradual, conservative approach to move closer to this goal. The emergence of EIP-8141 marks a new milestone on this path—it no longer seeks to simply add a layer of smart account functionality on top of the existing system, but instead aims to embed account abstraction directly into the transaction model itself, enabling accounts to possess programmable validation and execution logic from the protocol level onward.

This is also why EIP-8141 is regaining momentum today. On one hand, wallet experiences at the upper layer are increasingly approaching native account abstraction, and the protocol layer will eventually need to catch up; on the other hand, the long-term pressure from quantum computing is accelerating the question of “whether accounts can flexibly change signing methods” from a distant technical concern into an urgent practical issue that must be seriously considered.

Ultimately, EIP-8141 introduces a new type of transaction—Frame Transaction—with transaction type number 0x06.

If the fundamental logic of traditional Ethereum transactions is one transaction corresponding to one call, EIP-8141 aims to decompose a single transaction into a sequence of "frames" that can be executed in a defined order, thereby separating the previously bundled processes of validation, payment, and execution.

Each "frame" has three execution modes:

• VERIFY (Verification Frame): Responsible for verifying whether a transaction is valid; it executes account-specific validation logic and, if successful, invokes the newly introduced APPROVE opcode to authorize execution and specify a gas limit.
• SENDER: Performs actual operations such as transfers or contract calls. The caller address is the transaction sender themselves.
• DEFAULT (Entry Point): Uses the system entry point address as the caller, for scenarios such as contract deployment and Paymaster verification;

The significance of this mechanism is not that transactions become more complex, but that it separates "verification, payment, and execution" from account actions for the first time, entrusting them to native protocol scheduling.

In the past, verifying transactions, paying for gas, and executing actual operations were all bundled into a single account action. Under the design of EIP-8141, these tasks can be separated into distinct frames and executed by the protocol in a defined sequence. As a result, accounts are no longer limited to relying on a single private key for an "all-or-nothing" signature, but instead begin to take on a more programmable, execution-oriented form.

For a concrete example, suppose you want to use USDC to pay for gas to complete a swap. Under the EIP-8141 framework, this could theoretically be organized as a complete frame flow: first, the account verifies the signature and execution permissions; then, the payer or Paymaster verifies their willingness to cover the fees; next, the fee payment in the corresponding asset is processed; finally, the actual swap operation is executed.

This allows the Gas payment and the main transaction to be included in a single atomic process—either both succeed or both are rolled back.

For users, the most intuitive change is that many operations previously requiring two or three separate steps—with risks of failure in between—will now function more like a single, unified action. This atomicity is one of the key aspects EIP-8141 aims to address in resolving the fragmentation of user experience.

What does this mean for wallet users? In practice, the most direct changes are at least fourfold:

• Gas payment is abstracted: Having stablecoins in your wallet no longer means you must additionally hold some ETH to perform transactions; in the future, gas fees will be more natively covered by DApps, Paymasters, or other sponsors.
• Multiple steps have been combined: workflows that previously required multiple signatures, such as "Approve + Swap" or "Approve + Stake," now have the opportunity to be bundled into a single, more streamlined operation;
• Account security rules are now enabled: multi-signature, social recovery, daily limits, time locks, and key rotation are no longer just advanced features offered by certain wallet products—they are beginning to be built into more native account logic.
• The signature scheme is no longer locked into a single path requiring ECDSA: this, for the first time, enables protocol-level possibilities for accounts to migrate to different cryptographic systems, including post-quantum signature schemes.

A point that is easily overlooked but crucial for wallet users is that even if EIP-8141 is ultimately implemented, the existing account system will not be entirely overturned.

Even if you are currently using an existing Web3 wallet like imToken, there is no need to migrate, as it is backward compatible—your existing EOA address can continue to be used, and you only need to select "upgrade" to update your account's verification logic when appropriate.

Conversely, precisely because the changes were so extensive, it did not immediately become the flagship feature of Hegotá in the latest round of discussions. However, under the 2026 EIP champion process, CFI (Considered for Inclusion) does not mean rejection—it signifies entry into serious consideration, but not yet final approval for implementation.

In other words, core developers do not reject the direction of EIP-8141; rather, while acknowledging its value, they believe it is still too "heavy" at this stage.

After all, native account abstraction cannot be gradually adopted by a small number of wallets, infrastructure providers, and applications as ERC-4337 can; once it enters the protocol layer, it requires all execution-layer clients to genuinely implement, test, and coordinate, naturally raising the barrier to adoption and making core developers more inclined toward cautious fork planning.

What happens next? It can be viewed along two lines:

• Since EIP-8141 is in CFI status, it remains under active evaluation; the author will continue to address critical details regarding transaction pool security, validation rules, and client implementations, and the ACD meeting will reassess whether it meets the criteria to advance further.
• If these uncertainties can be consistently resolved, there is an opportunity for it to advance to a more substantive inclusion phase in future upgrades; if not, it may simply be deferred to a later upgrade cycle;

To be frank, EIP-8141 is not the only native account abstraction proposal, nor is it a ready-made post-quantum signature scheme capable of directly solving quantum computing threats; however, its significance lies in providing, for the first time, a protocol-level pathway for accounts to move beyond the sole reliance on ECDSA.

From this perspective, the true value of EIP-8141 lies not in whether it is the only correct answer, but in that it is the first time the question—“What should the ultimate form of native account abstraction look like?”—has been presented comprehensively on the table for Ethereum protocol discussion.

It is not the only solution, but it is one of the most ambitious and closest to the upper limit of the vision of "complete native AA" currently available.

Regardless of whether EIP-8141 ultimately catches up to Hegotá, this discussion itself has at least demonstrated one thing:

Ethereum has not stood still while issues festered; instead, it has been steadily paving the way for the next-generation account system.