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

Last week, at the Ethereum core developers meeting, EIP-8141 was formally discussed to determine whether it should be included in the Hegota upgrade. The result was unexpected: this proposal, personally endorsed by Vitalik, was not listed as a “headline feature” of Hegota, 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 its given hardware assumptions, its estimate of the physical quantum bits required to break ECDLP-256 has dropped by 20x compared with earlier estimates. While this doesn’t mean quantum attacks are right around the corner, it is nonetheless a concrete reminder that if, in the future, the account system cannot flexibly replace verification logic, then many of today’s discussions about wallet experience may ultimately evolve into security issues.

From the real-world perspective of protocol development, EIP-8141 is still too heavy at this point, especially given that there is not yet enough solid consensus on client implementation, transaction pool security, and verification complexity.

But at this moment in time, the parts of EIP-8141 that deserve discussion and serious review seem to be increasing, really more and more.

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

EIP-8141 is driven by Vitalik Buterin and key contributors such as timbeiko. Its official name is Frame Transactions.

If we summarize it in a simpler way, what it wants to do is not to add a single wallet feature in isolation. Instead, it attempts—at the protocol layer—to free any account from being constrained to a single ECDSA signature path, so that it can have more flexible verification and execution logic.

This also means that multisig, gas sponsorship, key rotation, social recovery, and even—eventually—integrating post-quantum signature schemes are no longer just an added capability bolted on outside the wallet. They now have the chance to become “native components” within Ethereum’s account system.

At face value, what EIP-8141 is discussing is a set of very specific capabilities: pay Gas with stablecoins, compose multi-step actions into a single transaction, support more flexible signature methods, and even reserve space for future post-quantum signatures. In other words, over the years—from ERC-4337 to EIP-7702—many improvements around wallet experience have fundamentally been making it so that an account is no longer only a private key, but an entry point where custom rules can be defined.

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

As everyone knows, in the current system, Ethereum accounts broadly fall into two categories. One is externally owned accounts (EOAs)—the one everyone is most familiar with—which are controlled by a private key. They can initiate transactions, but lack programmability. The other is contract accounts—i.e., the smart contracts themselves—which can execute complex logic but cannot initiate transactions on their own.

This results in the ability to initiate transactions being long bound to a single private-key signature. As long as that premise remains unchanged, many capabilities that users today think they should have by default—such as flexibly changing signing rules, having someone else pay Gas, recovering account control after losing a private key, or smoothly migrating to a new password system in the future—are difficult to truly become default account capabilities.

If you’ve used imToken or other Web3 wallets, you’ve likely encountered these pain points too—such as having a bunch of USDC in your wallet but being unable to send a transaction without ETH (because Gas can only be paid in ETH); losing the seed phrase means losing the funds for good with no recovery; and an action like “approve + swap” requiring signing twice and confirming twice, and so on.

These issues are not because the wallet product is “not good enough,” but because of the design outcomes of Ethereum’s account model itself.

From this perspective, the evolution of the past two years has already been very clear. ERC-4337 has run account abstraction at the application layer without modifying the protocol. EIP-7702 has further shown that EOAs are not completely unable to be extended—at least they can temporarily gain some capabilities that are close to smart accounts.

That is, Ethereum is not that it doesn’t want account abstraction—it has been approaching it in a more mild, more conservative way, gradually moving toward it. And the appearance of EIP-8141 means this path has reached a new node. It no longer is satisfied with stacking another layer of smart account capability outside the existing system; instead, it is trying to embed account abstraction directly into the transaction model itself, so that from the protocol layer onward, the account already has programmable verification and execution logic.

That’s also why EIP-8141 is being heated up again today. On the one hand, wallet experience at the application layer is getting closer and closer to native account abstraction, so 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 “whether accounts can flexibly change their signing method” from a distant technical topic into a real issue that must be seriously considered in advance.

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 core logic of traditional Ethereum transactions is that one transaction corresponds to one call, then what EIP-8141 wants to do is to break a single transaction into a set of “frames” that can be executed in a rule-based order, thereby separating the three things that were originally tied 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 opcode to authorize execution and specify a Gas limit.
• SENDER (sender frame): executes the actual actions, such as transfers and contract calls. The caller address is the transaction sender themselves.
• DEFAULT (entry frame): uses the system entry address as the caller, for scenarios such as deploying contracts, validating Paymasters, and so on;

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

After all, in the past, who verifies a transaction, who pays Gas, and who executes the real actions were basically bound to the same account action. But under EIP-8141’s design, these can be split into different frames, and the protocol will execute them in a clearly defined sequence. And precisely because of that, an account is no longer limited to “sign everything as a whole” with a single private key, and instead begins to take on a shape closer to a programmable execution主体.

Here’s a concrete example. Suppose you want to use USDC to pay Gas to complete a Swap. Under EIP-8141’s framework, this theoretically 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 cost; next, the corresponding assets are used to pay the fees; and finally, the actual swap operation is executed.

In this way, Gas payment and the main transaction can be included in the same atomic flow—either everything succeeds or everything reverts.

For users, the most intuitive change is that many operations that previously had to be split into two or three steps and had failure risk in between can, in the future, feel more like a single complete action. So this atomicity is also one of the key aspects that EIP-8141 aims to address the fragmentation of user experience.

What does that mean for wallet users? In terms of outcomes, the most direct changes are at least four layers:

• Gas payment is abstracted: having stablecoins in the wallet no longer means you must also prepare a bit of ETH to operate. In the future, Gas paid on your behalf by a DApp, Paymaster, or other sponsor becomes more native;
• Multi-step operations are combined: flows like “approve + Swap” and “approve + staking,” which currently often require multiple signatures, have a 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 by a particular wallet product. They now have a chance to be built on more native account logic;
• The signing scheme no longer has to be locked into a single ECDSA path: this gives accounts, for the first time, protocol-layer meaningfully possible options to migrate into different cryptographic systems, including post-quantum signature schemes.

3. Why didn’t it become Hegotá’s headline act?

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

Even if you are using an existing Web3 wallet like imToken today, you don’t need to migrate. It’s backward compatible: existing EOA addresses can continue to be used, and you only need to choose the upgraded account verification logic at the appropriate time.

But conversely, it’s also precisely because it changes things deeply enough that it didn’t directly become a Hegotá headline feature in the latest round of discussion. Still, following the EIP champion process in 2026, the meaning of CFI (Considered for Inclusion) is not a rejection—it means it has entered serious consideration, though it has not yet reached the point of a final approval to go live.

In other words, core developers are not saying they don’t recognize the direction of EIP-8141. Rather, while acknowledging its value, they also believe it is still too “heavy” at this time.

After all, unlike ERC-4337, native account abstraction can’t be pushed first gradually by only a few wallets, infrastructure, and applications. Once it enters the protocol layer, it means that all execution-layer client implementations have to seriously accept it, test it, and coordinate. This naturally raises the bar for adoption, and makes core developers more inclined to be cautious when planning forks.

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

• Since EIP-8141 is still in CFI status, it means it is still under continuous evaluation. The proposal authors will continue to fill in key details around transaction pool security, verification rules, and client implementation. In later ACD meetings, it will be revisited to see whether it meets the conditions for further advancement;
• If these uncertainties can be continuously reduced, it has a chance to enter a more substantive inclusion stage in subsequent upgrades. If they cannot, it could also be postponed to a later upgrade cycle.

To be fair and honest, EIP-8141 is not the only native account abstraction proposal, and it is not, by itself, some ready-made post-quantum signature solution that can directly solve the quantum computing problem. But its importance lies in the fact that for the first time, it provides an protocol-layer exit for accounts to get away from the single-path ECDSA model.

From this perspective, the true value of EIP-8141 is not whether it is the only correct answer, but that it, for the first time, brings a very complete version of the question “what should the end state of native account abstraction look like” onto the table for Ethereum protocol discussions.

It isn’t the only proposal, but it is indeed one of the most ambitious options available today—and also one of the closest to the imaginative upper limit of “complete native AA.”

No matter whether EIP-8141 can ultimately catch up to Hegotá, this discussion at least already shows something:

Ethereum is not waiting for problems to fester in place. It is laying groundwork for the next-generation account system, one step at a time.