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

EIP-8141 is an attempt to bring account abstraction, gas payment, and signing flexibility directly down into the protocol layer.

By: imToken

Last week, at the Ethereum core developers meeting, the question of whether EIP-8141 should be included in the Hegota upgrade was discussed in a formal way. To everyone’s surprise, the proposal—personally endorsed by Vitalik—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, their estimate of the number of physical qubits needed to break ECDLP-256 has dropped by 20 times compared with earlier estimates. While this doesn’t mean quantum attacks are imminent, it is a very real reminder that if the account system in the future can no longer flexibly swap verification logic, then many of today’s discussions about wallet experiences may ultimately turn into security issues.

From the practical standpoint of protocol progress, EIP-8141 is still too heavy right now—especially in terms of client implementation, transaction pool security, and verification complexity, where there is still not enough solid consensus.

But at this point in time, the aspects of EIP-8141 that are worth discussing and scrutinizing seem to be growing more and more.

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

EIP-8141 is driven by Vitalik Buterin and other core contributors such as timbeiko, and its official name is Frame Transactions.

If we summarize it in a more easily understood way, it’s not really about adding a single wallet feature. Rather, it tries—starting from the protocol layer—to ensure that no account has to be locked into a single ECDSA signing pathway, and that accounts can instead have more flexible verification and execution logic.

This also means that multisig, gas sponsorship, key rotation, social recovery, and even future integration of post-quantum signing schemes are no longer just capabilities bolted on outside the wallet. Instead, they may have the opportunity to become “native members” of Ethereum’s account system.

If you look only at the surface, EIP-8141 is discussing a set of very specific capabilities: paying gas with stablecoins, combining multi-step operations into a single transaction, supporting more flexible signing methods, and even reserving room for post-quantum signing in the future. In other words, over the years—from ERC-4337 to EIP-7702—many improvements around wallet experience in essence have been making it so that an account is no longer just a private key, but an entry point with customizable rules.

The problem is that while these improvements do make wallets increasingly resemble smart accounts, they have never truly touched Ethereum’s underlying default account model.

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

This leads to the ability to initiate transactions being long bound together with a single private-key signature. As long as this premise doesn’t change, many capabilities that users today assume they should have—such as flexibly changing signing rules, having someone else pay gas on their behalf, recovering control of the account after losing the private key, or smoothly migrating to a new cryptographic system in the future—are difficult to truly become default account capabilities.

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

These issues are not because wallet products are “not good enough,” but because of the design outcome of the Ethereum account model itself.

From this perspective, the evolution of the past two years has already been very clear. ERC-4337, without changing the protocol, runs account abstraction in the application layer first. EIP-7702 further proves that EOAs are not completely unable to be extended; at least they can temporarily gain some capabilities approaching those of smart accounts.

In other words, Ethereum is not that it doesn’t want account abstraction—it has been pursuing it in a more gentle, more conservative way, progressively inching toward it. The emergence of EIP-8141 means that this path has reached a new node. It no longer settles for adding 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, accounts have programmable verification and execution logic.

That’s also why EIP-8141 is getting re-heated today. On the one hand, the upper-layer wallet experience has increasingly moved closer to native account abstraction, and the protocol layer will eventually need to catch up. On the other hand, the long-term pressure brought by quantum computing is also turning the question of whether accounts can flexibly change signing methods—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 transaction type—Frame Transactions—whose transaction type ID is 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 one transaction into a set of “frames” that can be executed in a rule-defined order. This separates 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 the newly introduced APPROVE opcode to authorize execution and specify a gas limit.
• SENDER (sender frame): executes the actual operation, such as transferring funds or calling a contract. The caller address is the transaction sender itself.
• DEFAULT (entry frame): uses the system entry address as the caller, for deploying contracts, verifying Paymasters, and other scenarios.

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 hands their scheduling to the protocol natively.

After all, in the past, who verifies the transaction, who pays gas, and who executes the real operations were basically all tied to the same account action. But under the design of EIP-8141, these things can be split into different frames, which the protocol executes in a clearly defined order. And precisely because of that, the account is no longer limited to signing everything as a whole with a single private key—it begins to take on a shape that is much closer to a programmable execution主体.

Let’s give a concrete example. Suppose you want to pay gas with USDC to complete a swap. Under the EIP-8141 framework, in theory, this can be organized into a complete frame flow: first, the account verifies the signature and execution permissions; then, the payer or Paymaster verifies conditions under which it is willing to bear the cost; next, the corresponding asset fee payment is completed; 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 rolls back.

For users, the most intuitive change is that many operations that previously had to be split into two or three steps—with failure risk in between—can in the future feel more like a single complete action. That atomicity is also one of the key things EIP-8141 aims to solve regarding fragmented user experience.

So what does this mean for wallet users? Judging from the outcome, the most direct changes come in at least four layers:

• Gas payment is abstracted: having stablecoins in your wallet no longer means you must also prepare a little ETH to operate. In the future, gas sponsored by a DApp, Paymaster, or other sponsor can become more native;
• Multi-step operations are merged: processes like “approval + swap” and “approval + staking,” which often currently require multiple signatures, 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 just advanced features provided by a particular wallet product. Instead, there is an opportunity to build them on top of more native account logic;
• Signing schemes are no longer forced to be locked down to a single ECDSA path: this gives accounts, for the first time, protocol-layer meaningful possibilities to migrate to different cryptographic systems, including post-quantum signing schemes.

3. Why didn’t it become Hegotá’s top pick?

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

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

But on the flip side, precisely because it changes things deeply enough, it didn’t become a headline feature for Hegotá in the latest round of discussion. However, following the EIP champion process for 2026, the meaning of CFI (Considered for Inclusion) is not rejection—it means it has entered a serious consideration stage, but it hasn’t yet reached the point where a final decision is made for a launch.

In other words, the core developers are not saying they don’t recognize the direction of EIP-8141. At the same time they acknowledge its value, they also believe it is still too “heavy” right now.

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

So what happens next? We can look at it in two lines:

• Since EIP-8141 is in CFI status, it indicates that it is still being continuously evaluated. The proposal authors will keep filling in the key details surrounding transaction pool security, verification rules, and client implementation. Later, the ACD meetings will also reassess whether it has the conditions to be pushed further;
• If these uncertainties can be continuously reduced, it has a chance to enter a more substantive inclusion stage in subsequent upgrades. If not, it can also be completely possible for it to be deferred to a later upgrade cycle.

To be fair, EIP-8141 is not the only native account abstraction proposal. And more importantly, it is not itself some ready-made post-quantum signing scheme. It can’t directly solve the quantum computing problem. What makes it important is that, for the first time, it provides an protocol-layer exit for accounts to get out of a single ECDSA path.

From this perspective, the real value of EIP-8141 isn’t whether it’s the only correct answer. It’s that it puts, for the first time, the question of what “the end state of native account abstraction” should actually look like squarely on the table for Ethereum protocol discussion.

It is not the only方案, but it is indeed one of the most ambitious—also among the closest—to the maximum imagination for a complete native AA.

No matter whether EIP-8141 will ultimately catch up to Hegotá, this discussion itself has at least already shown one thing:

Ethereum is not waiting in place for problems to ferment. It is paving the way in advance for the next generation of account systems, one step at a time.