Native account abstraction + resistance to quantum threats: Why hasn't EIP-8141 become Ethereum's flagship Hegotá yet?

Written by: imToken

Last week, at the Ethereum core developers meeting, there was an official discussion on whether EIP-8141 would be included in the Hegota upgrade. The outcome was unexpected: this proposal, which Vitalik himself endorsed, was not listed as Hegota’s “headline feature,” but instead received a “considered for inclusion” (CFI) status.

And this week, Google’s Quantum AI team released a new white paper stating that, under their given hardware assumptions, the estimated number of physical quantum bits required to crack ECDLP-256 has dropped by as much as 20 times compared to earlier estimates. Although this doesn’t mean quantum attacks are imminent, it very concretely reminds us that if, in the future, the account system can’t flexibly swap out verification logic, then many of today’s discussions about wallet experiences could ultimately evolve into security issues.

From the practical angle of pushing the protocol forward, EIP-8141 is still too heavy at the moment—especially in terms of client implementation, transaction pool security, and verification complexity—there is not yet enough solid consensus.

But at this particular point in time, it really seems that there are more and more places in EIP-8141 that are worth discussing and seriously examining.

1. What exactly is EIP-8141 trying to solve?

EIP-8141 is driven by Vitalik Buterin, along with core contributors such as timbeiko. Its official name is Frame Transactions.

If you summarize it in a simpler way, what it wants to do isn’t really to add a single new wallet feature by itself. Instead, it tries—at the protocol layer—to ensure that any account is no longer tightly bound to a single ECDSA signature path, but can have more flexible verification and execution logic.

This also means that multisig, Gas sponsorship, key rotation, social recovery, and even future support for anti-quantum signature schemes are no longer just capabilities bolted on outside the wallet. They now have a chance to become “native members” of Ethereum’s account system.

If you look only at the surface, the EIP-8141 discussion is about a set of very specific capabilities: paying Gas with stablecoins, combining multi-step actions into a single transaction, supporting more flexible signing methods, and even leaving room for future anti-quantum signatures. In a sense, over the years, many improvements around wallet experience—from ERC-4337 to EIP-7702—have fundamentally been pushing accounts to be not just a private key, but an entry point where custom rules can be defined.

The problem is that while these improvements do make wallets feel more and more like smart accounts, they still have never truly touched Ethereum’s lowest-level default account model.

As is well known, in the current system, Ethereum accounts broadly fall into two types. One is externally owned accounts (EOAs), which are what most people are most familiar with: controlled by private keys, able to initiate transactions on their own, but lacking programmability. The other is contract accounts, meaning the smart contract itself: it can execute complex logic, but it cannot initiate transactions on its own.

That leads to the power to initiate transactions being long tied to a single private-key signing flow. As long as that premise remains unchanged, many capabilities that many users today think they should logically have—such as flexibly changing signature rules, having others pay Gas on their behalf, recovering control of the account after a private key is lost, or smoothly migrating to a new cryptographic system in the future—are still difficult to become true default account capabilities.

If you’ve used imToken or other Web3 wallets, you’ve probably encountered these pain points too: for example, you have a bunch of USDC in your wallet but no ETH, so you can’t send a transaction (because Gas can only be paid with ETH); lose your seed phrase and you’ve effectively lost the funds with no way to recover; and an operation like “approval + swap” requires signing twice, confirming twice, and so on.

These problems aren’t because the wallet products aren’t “good enough.” They are the result of the Ethereum account model’s own design.

From this perspective, the evolution over the past two years has been quite clear. ERC-4337 has run account abstraction at the application layer without modifying the protocol. And EIP-7702 has further proven that EOAs are not completely unexpandable—at least temporarily, they can gain some capabilities close to smart accounts.

In other words, Ethereum isn’t unwilling to do account abstraction. It has been approaching the idea with a more gentle, more conservative strategy, gradually converging toward it. And the appearance of EIP-8141 means that this path has reached a new node: it no longer just stacks an account-abstraction-like smart capability around the existing system. Instead, it tries to embed account abstraction directly into the transaction model itself, so that from the protocol layer onward, the account has programmable verification and execution logic.

This is also why EIP-8141 is being reheated today. On one hand, wallet experience at the top layer is getting closer and closer to native account abstraction, so the protocol layer will inevitably need to catch up. On the other hand, the long-term pressure brought by quantum computing is also turning “whether accounts can flexibly change signature methods” from a distant technical topic into a real issue that must be seriously considered ahead of time.

2. How does EIP-8141 work?

At bottom, EIP-8141 introduces an entirely new type of transaction—Frame Transactions, with a transaction type identifier of 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 a transaction into a set of “frames” that can be executed in a rule-defined order, 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 whether the transaction is valid. It runs the account’s custom verification logic. If it passes, it calls a newly introduced APPROVE operation code to authorize execution and specify a Gas limit.

SENDER (sending frame): executes the actual action, such as transferring or calling a contract. The caller address is the transaction sender’s own address.

DEFAULT (entry frame): uses the system’s entry address as the caller, for scenarios like deploying contracts and validating a Paymaster;

The significance of this mechanism is not that transactions can become more complex. Rather, for the first time, it separates “verification, payment, execution” from account actions and lets the protocol natively dispatch them.

After all, in the past, who verifies the transaction, who pays Gas, and who performs the real operation were basically all bound to the same account action. Under the design of EIP-8141, these can be split into different frames, executed by the protocol in a clearly defined order. And precisely because of that, the account is no longer limited to relying on a single private key to “sign the whole thing,” and begins to take on a form closer to a programmable execution entity.

Take a concrete example: suppose you want to use USDC to pay Gas to complete a Swap. Within the framework of EIP-8141, in theory, this could be organized into a complete frame flow: first, the account verifies the signature and execution permissions; then, the payer or Paymaster verifies the conditions under which it is willing to cover the costs; afterward, the corresponding asset is used to pay the fees; and finally, the actual swap operation is executed.

With that, Gas payment and the main transaction can be included in the same atomic flow—either everything succeeds or everything rolls back.

For users, the most direct change is that many operations that previously had to be broken into two or three steps and had failure risk in the middle can in the future feel more like a single complete action. That atomicity is therefore also one of the key things EIP-8141 is trying to solve: the fragmentation of user experience.

So what does this mean for wallet users? In terms of results, the most direct changes are at least four layers:

Gas payment is abstracted: having stablecoins in your wallet no longer means you must prepare extra ETH just to operate. In the future, Gas covered by a DApp, Paymaster, or other sponsor will become more native.

Multi-step operations are merged: processes like “approval + Swap” and “approval + staking,” which often require multiple signatures today, have the chance to be packaged into a more complete single operation.

Account security rules are opened up: multisig, social recovery, daily limits, time locks, key rotation—these are no longer only advanced features provided as an extra by a particular wallet product. They now have a chance to be built upon more native account logic.

Signature schemes are no longer forced to be locked to a single ECDSA path: this gives accounts the first protocol-layer possibility to migrate to different cryptographic systems, including post-quantum signature schemes.

3. Why didn’t it become Hegota’s headline feature?

A point that’s easy to overlook, but crucial for wallet users, is this: even if EIP-8141 ultimately lands, the existing account system won’t be completely overthrown as a whole.

Even if you’re using existing Web3 wallets like imToken, you don’t need to migrate, because it’s backward compatible. Existing EOA addresses can continue to be used; you only need to choose, at the appropriate time, to “upgrade” the account’s verification logic.

But conversely, precisely because it changes things deeply enough, it did not become a headline feature of Hegota directly in the latest round of discussion. However, according to the 2026 EIP champion process, the meaning of CFI (Considered for Inclusion) is not a denial—it means entering a serious consideration stage, but not yet reaching the point of a final decision and go-live.

In other words, the core developers aren’t saying they don’t recognize EIP-8141’s direction. They are acknowledging its value while also believing it is still too “heavy” at the moment.

After all, native account abstraction can’t be gradually pushed by just a small number of wallets, infrastructure, and applications the way ERC-4337 can. Once it enters the protocol layer, it means that all execution-layer clients must take it seriously—implement it, test it, and coordinate it. That naturally raises the bar for moving forward, and it will likely make core developers lean toward being more cautious when planning forks.

So what happens next? You can look at it as two tracks:

Since EIP-8141 is in a CFI state, it indicates that it is still being continuously evaluated. The proposal authors will continue to fill in key details around transaction pool security, verification rules, and client implementation. Later ACD meetings will also reassess whether it has the conditions to move forward further.

If these uncertainties can be continuously compressed, it has a chance to enter a more substantive inclusion stage in subsequent upgrades. If not, it could completely be pushed back to a later upgrade cycle.

To be frank, EIP-8141 isn’t the only native account abstraction proposal, and by itself it’s not even some ready-made anti-quantum signature scheme. It can’t directly solve the problem of quantum computing. But its importance is that for the first time, it provides an important protocol-layer exit route for accounts to get away from a single ECDSA path.

From this perspective, the true value of EIP-8141 isn’t whether it’s the only correct answer. It’s that it, for the first time, brings the question of what the end state of native account abstraction should really look like onto the table in Ethereum protocol discussions in a very complete way.

It isn’t the only option, but it is indeed one of the most ambitious proposals today and one that comes closest to the upper limit of the imagination for a “complete native AA.”

Whether EIP-8141 will eventually catch up to Hegota or not, this discussion itself has already shown at least one thing:

Ethereum is not waiting in place for problems to ferment. Instead, it is paving the way for the next generation of account system step by step, one brick at a time.