Written by: imToken

Last week, the Ethereum core developer meeting formally discussed whether to include EIP-8141 in the Hegota upgrade. Surprisingly, this proposal, which was personally endorsed by Vitalik Buterin, was not listed as a "headline feature" of Hegota, but instead received a "Consideration 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 crack ECDLP-256 has decreased by 20 times compared to previous estimates. While this doesn't mean quantum attacks are imminent, it serves as a stark reminder that if account systems cannot flexibly change their verification logic in the future, many discussions about wallet experiences today could ultimately escalate into security issues.

From a practical standpoint regarding protocol implementation, EIP-8141 is still too cumbersome, especially in terms of client implementation, transaction pool security, and verification complexity, where a sufficiently robust consensus has not yet been reached.

However, at this point in time, there seem to be more and more aspects of EIP-8141 that deserve discussion and serious examination.

I. What exactly does EIP-8141 aim to solve?

EIP-8141, driven by core contributors such as Vitalik Buterin and timbeiko, is officially named Frame Transactions.

To put it simply, what it aims to do is not to add a single wallet function, but to allow any account to no longer be bound by a single ECDSA signature path, but to have more flexible verification and execution logic at the protocol layer.

This also means that multi-signature, Gas sponsorship, key rotation, social recovery, and even future integration with quantum-resistant signature solutions will no longer be just an external layer of capabilities on the wallet, but have the opportunity to become "native members" of the Ethereum account system.

On the surface, EIP-8141 discusses a set of seemingly very specific capabilities: paying gas with stablecoins, combining multi-step operations into a single transaction, supporting more flexible signature methods, and even reserving space for future quantum-resistant signatures. It can be said that many improvements to the wallet experience over the years, from ERC-4337 to EIP-7702, have essentially transformed an account from just a private key into an entry point with customizable rules.

The problem is that while these improvements do make wallets more like smart accounts, they never truly touch the default account model at the very bottom of Ethereum.

As is well known, under the current system, Ethereum accounts are broadly divided into two categories. One is the External Ownership Account (EOA), which is the most familiar one. It is controlled by a private key and can initiate transactions proactively, but it lacks programmability. The other is the contract account, which is the smart contract itself. It can execute complex logic, but it cannot initiate transactions proactively on its own.

This means that the ability to initiate transactions is tied to a single private key signature in the long term. As long as this premise remains unchanged, many capabilities that users take for granted today, such as flexibly changing signature rules, having others pay gas on their behalf, regaining account control after losing a private key, or smoothly migrating to a new cryptographic system in the future, will hardly become the default capabilities of an account.

If you've used imToken or other Web3 wallets, you've likely encountered these pain points as well. For example, you might have a lot of USDC in your wallet but no ETH, so you can't send transactions (because gas can only be paid with ETH); losing your mnemonic phrase means losing all your money, which is irrecoverable; and a single "authorization + exchange" operation requires two signatures and two confirmations, etc.

These problems are not because the wallet product is "not good enough," but rather a result of the design of the Ethereum account model itself.

From this perspective, the evolution over the past two years has become very clear. ERC-4337, without modifying the protocol, put account abstraction into operation at the application layer. EIP-7702 further proved that EOA is not entirely unscalable and can at least temporarily acquire some capabilities close to smart accounts.

In other words, Ethereum doesn't lack the desire to implement account abstraction; rather, it has been gradually approaching this goal in a more moderate and conservative manner. The emergence of EIP-8141 signifies that this path has reached a new milestone. It is no longer content with simply adding another layer of smart account capabilities to the existing system; instead, it attempts to embed account abstraction directly into the transaction model itself, enabling accounts to possess programmable verification and execution logic from the protocol layer onwards.

This is why EIP-8141 is gaining renewed attention today. On the one hand, the upper-layer wallet experience is becoming increasingly similar to the native account abstraction, and the protocol layer will need to catch up sooner or later; on the other hand, the long-term pressure brought by quantum computing is also turning the question of "whether an account can flexibly change its signature method" from a distant technical issue into a real problem that must be seriously considered.

II. How does EIP-8141 work?

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

If the basic logic of traditional Ethereum transactions is that one transaction corresponds to one call, then what EIP-8141 wants to do is to break down a transaction into a set of "frames" that can be executed in a certain order according to rules, thereby separating the three things that were originally bundled together: verification, payment, and execution.

Each "frame" has three execution modes:

• VERIFY (Verification Frame): Responsible for verifying the legitimacy of a transaction. It runs the account's custom verification logic. If the transaction passes, it calls the newly introduced APPROVE opcode to authorize execution and specify the gas limit.
• SENDER (Send Frame): Performs the actual operation, such as transferring funds or invoking a contract. The caller's address is the sender of the transaction.
• DEFAULT (entry frame): Uses the system entry address as the caller, and is used for scenarios such as deploying contracts and verifying Paymaster;

The significance of this mechanism is not that transactions can be made more complex, but that for the first time, the three things of "verification, payment, and execution" are separated from account actions and handed over to the native scheduling of the protocol.

In the past, who verified transactions, who paid for gas, and who performed the actual operations were all basically tied to the same account action. However , under the design of EIP-8141, these tasks can be broken down into different frames and executed sequentially by the protocol in a clear order. As a result, accounts no longer have to rely on a single private key to "sign the whole thing" and have begun to take on a form that is closer to a programmable execution entity.

For a concrete example, suppose you want to use USDC to pay for gas to complete a swap. Under the EIP-8141 framework, this can theoretically be organized into a complete frame process: first, the account verifies the signature and execution authority; then, the payer or Paymaster verifies its willingness to bear the fees; then, the corresponding asset fee payment is completed; and finally, the actual swap operation is executed.

In this way, gas payments and the main transaction can be incorporated into the same atomic process, either all succeeding or all being rolled back.

For users, the most intuitive change is that many operations that previously had to be broken down into two or three steps and had the risk of failure can now be performed more like a single, complete action. Therefore, this atomicity is one of the key aspects of EIP-8141's solution to the problem of fragmented user experience.

So what does this mean for wallet users? Looking at the results, there are at least four key changes:

• Gas payments are being abstracted: having stablecoins in your wallet no longer means you need to prepare extra ETH to make a transaction. In the future, gas payments will be handled by DApps, Paymaster, or other sponsors, becoming more native.
• Multi-step operations are being merged: Processes that often require multiple signatures, such as "authorization + swap" and "authorization + staking," can be packaged into a more complete operation.
• Account security rules have been opened up: multi-signature, social recovery, daily limits, time locks, and key rotation are no longer just advanced features provided by a wallet product, but have the opportunity to be built on more native account logic;
• The signature scheme is no longer necessarily locked to a single ECDSA path: This makes it possible for the first time, in a protocol-level sense, for accounts to migrate to different cryptographic systems in the future, including post-quantum signature schemes.

3. Why didn't she become Hegotá's top star?

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

Even if you are currently using an existing Web3 wallet such as imToken, you do not need to migrate, because it is backward compatible and your existing EOA address can continue to be used. You only need to choose to "upgrade" the account verification logic when appropriate.

Conversely, it is precisely because its changes were so thorough that it didn't become Hegotá's flagship feature in the latest round of discussions. However, according to the 2026 EIP champion process, the meaning of CFI (Considered for Inclusion) is not that it has been rejected, but rather that it has entered a stage of serious consideration, but it is not yet time for a final decision.

In other words, the core developers do not disagree with the direction of EIP-8141, but while acknowledging its value, they also believe that it is still too "heavy" at present.

After all, unlike ERC-4337, which can be gradually promoted by a few wallets, infrastructures and applications, native account abstraction, once it enters the protocol layer, means that all execution layer clients must carefully implement, test and coordinate. This will naturally raise the threshold for promotion and make core developers more cautious when planning forks.

So what will happen next? We can break it down into two lines:

• Since EIP-8141 is in CFI status, it means that it is still under continuous evaluation. The proposal authors will continue to supplement key details surrounding trading pool security, verification rules, and client implementation. Subsequent ACD meetings will also re-examine whether it is ready for further advancement.
• If these uncertainties can be continuously reduced, it has the opportunity to enter a more substantial inclusion phase in subsequent upgrades; if not, it may very well be postponed to a later upgrade cycle.

To be realistic, EIP-8141 is not the only native account abstraction proposal, nor is it a ready-made post-quantum signature scheme that can directly solve quantum computing problems. However, its importance lies in the fact that it provides, for the first time, a protocol-level exit for accounts to break free from the single path of ECDSA.

From this perspective, the true value of EIP-8141 lies not in whether it is the only correct answer, but in the fact that it has, for the first time, brought the question of "what the end result of the native account abstraction should look like" to the table of Ethereum protocol discussion in a very complete way.

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

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

Ethereum did not stand still and wait for the problems to fester, but instead paved the way for the next generation of account systems step by step.