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

Last week, at the Ethereum core developer meeting, the question of whether to formally include EIP-8141 in the Hegota upgrade was discussed in earnest. The result was unexpected: despite being a proposal personally endorsed by Vitalik, it was not listed as a Hegota “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 its given hardware assumptions, its estimate of the physical qubits required to crack ECDLP-256 has dropped dramatically—by 20x compared to earlier figures. While this does not mean quantum attacks are imminent, it is a concrete reminder that if the account system cannot flexibly swap out validation logic in the future, then many discussions today about wallet experiences could ultimately evolve into security issues.

From the realistic perspective of pushing protocol changes forward, EIP-8141 is still too heavy at this stage—especially because there is not yet enough solid consensus on client implementations, transaction pool security, and the complexity of validation.

But at this point in time, it seems there are genuinely more and more places where EIP-8141 deserves discussion and serious scrutiny.

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

EIP-8141 is driven by core contributors including Vitalik Buterin and timbeiko. Its formal name is Frame Transactions.

If we summarize it in a simpler way, what it’s trying to do is not to add a standalone wallet feature. Rather, it attempts—at the protocol level—to free any account from being locked into a single ECDSA signature path, so that it can have more flexible validation and execution logic.

This also means that multisig, gas sponsorship, key rotation, social recovery, and even future integration of anti-quantum signature schemes no longer would be merely add-on capabilities outside the wallet. Instead, they could have a chance to become “native members” of Ethereum’s account system.

If you look only at the surface, the EIP-8141 discussion concerns a set of seemingly very specific capabilities: paying Gas with stablecoins, combining multi-step actions into a single transaction, supporting more flexible signing methods, and even reserving space for future anti-quantum signatures. In a sense, many improvements over the years around wallet experience—from ERC-4337 to EIP-7702—essentially aim to make accounts no longer just a private key, but an entry point where customizable rules can be applied.

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

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

This leads to transaction initiation being long bound to a single private-key signing mechanism. As long as that premise does not change, many abilities that many users today consider “obvious”—such as flexibly changing signature rules, having others pay Gas, recovering account control after losing a private key, or smoothly migrating to a new key/password system in the future—are difficult to become default account capabilities in reality.

If you’ve used imToken or other Web3 wallets, you’ve likely 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); if you lose your seed phrase, you lose the funds permanently and can’t recover; and operations like “approve + swap” require signing twice and confirming twice, and so on.

These issues are not because wallet products aren’t good enough. They are the direct 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, without modifying the protocol, has already gotten account abstraction running at the application layer. EIP-7702 further shows that EOAs are not completely unable to be extended—at least they can temporarily gain some capabilities that are close to smart accounts.

In other words, Ethereum is not that it doesn’t want account abstraction, but that it has been approaching it in a more gentle, more conservative way—gradually moving closer to it. And the appearance of EIP-8141 means this path has reached a new node. It no longer just adds an additional layer of smart-account capability around the existing system; instead, it is trying to embed account abstraction directly into the transaction model itself, so that accounts already have programmable validation and execution logic starting from the protocol layer.

That’s also why EIP-8141 is heating up again today. On the one hand, the wallet experience at the upper layer is getting closer and closer to native account abstraction, so the protocol layer will eventually 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—earlier than before.

2. How does EIP-8141 work?

At bottom, EIP-8141 introduces a completely new type of transaction—frame transactions—with a transaction type number of 0x06.

If the basic logic of a traditional Ethereum transaction 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-based sequence—thereby splitting apart the three things that used to be bundled together: validation, payment, and execution.

Each “frame” has three execution modes:

• VERIFY (validation frame): responsible for verifying whether the transaction is valid. It runs the account’s customized validation logic; if it passes, it then 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 itself.
• DEFAULT (entry frame): uses the system entry address as the caller, for scenarios like deploying contracts and validating Paymasters;

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

After all, in the past, who validates the transaction, who pays Gas, and who performs the real action were basically all tied to the same account action. But 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, accounts are no longer limited to relying on a single private key to “sign everything as a whole,” but begin to take on a form that is closer to a programmable execution entity.

To give a concrete example: suppose you want to use USDC to pay Gas to complete a Swap. Under the framework of EIP-8141, 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 the conditions under which it is willing to cover the cost; next, the corresponding asset is paid the fee; 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 direct change is that many operations that previously had to be split into two or three steps—and had failure risk in the middle—can in the future feel like one complete action. That atomicity is also one of the key ways EIP-8141 aims to address the fragmentation of user experience.

So what does this mean for wallet users? From the outcome, the most direct changes amount to at least four layers:

• Gas payment is abstracted: having stablecoins in your wallet no longer means you must additionally prepare some ETH just to operate. In the future, Gas paid by a DApp, Paymaster, or other sponsor would become more native;
• Multi-step actions are merged: flows like “approve + Swap” and “approve + staking,” which often require multiple signatures today, could be packaged into a more complete single action;
• Account security rules are opened up: multisig, social recovery, daily limits, timelocks, key rotation—these are no longer just advanced features provided by a particular wallet product. They could begin to be built on top of more native account logic;
• Signing schemes no longer must be locked to a single ECDSA path: this gives accounts, for the first time, protocol-level possibility to migrate to different cryptographic systems, including post-quantum signature schemes;

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

A point that is easy to overlook but crucial for wallet users is: even if EIP-8141 ultimately becomes live, the existing account system will not be fully overturned.

Even if you are using existing Web3 wallets like imToken today, you don’t need to migrate. It is backward compatible: existing EOA addresses can continue to be used, and you only need to choose the upgraded account validation logic when the time is right.

But conversely, precisely because it changes things deeply enough, it didn’t directly become a Hegota headline feature in the latest round of discussions. Still, according to the 2026 EIP champion process, the meaning of CFI (Considered for Inclusion) is not rejection—it means it is entering a serious consideration phase, but it’s not yet time for a final go-ahead for rollout.

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

After all, native account abstraction cannot be gradually driven at the edges by a few wallets, infrastructure, and applications the way ERC-4337 can. Once it enters the protocol layer, it means all execution-layer clients must seriously implement it, test it, and coordinate with each other. That naturally raises the bar for adoption, and makes core developers more inclined toward being cautious when planning forks.

So what happens next? It can be viewed in two lines:

• Since EIP-8141 is in the CFI state, it means it is still being continuously evaluated. The proposal authors will keep filling in key details around transaction pool security, validation rules, and client implementations. Then, at subsequent ACD meetings, it will be revisited whether it meets conditions for further push-forward;
• If these uncertainties can be continuously narrowed down, it has a chance to move into a more substantive inclusion phase in later upgrades. If not, it could also be carried over to a later upgrade cycle entirely;

To be fair, EIP-8141 is not the only native account abstraction proposal. And it is not, in itself, some ready-made post-quantum signature scheme that can directly solve the quantum computing problem. But its importance is that for the first time, it provides an protocol-level exit for accounts to move away from a single ECDSA-only path.

From this angle, the true value of EIP-8141 is not whether it is the only correct answer, but that it is the first time the question of what the end-state of native account abstraction should actually look like has been laid out very comprehensively on the table for discussion within the Ethereum protocol.

It isn’t the only solution, but it is indeed one of the most ambitious proposals—and among the closest to the upper bound of the imagination for “full native AA” that is currently on the table.

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

Ethereum is not waiting on problems to fester in place—it is using a steady, step-by-step approach to pave the way for the next generation of account systems.