Author: imToken
Last week, the Ethereum core developers' meeting formally discussed whether to include EIP-8141 in the Hegota upgrade. The result was unexpected. This proposal, personally endorsed by Vitalik, was not listed as the "headline feature" of Hegota but instead received a "Considered for Inclusion" (CFI) status.
This week, Google's Quantum AI team published a new whitepaper, stating that under their given hardware assumptions, the estimated number of physical qubits required to crack ECDLP-256 has been significantly reduced by 20 times compared to previous estimates. While this doesn't mean a quantum attack is imminent, it serves as a real reminder that if the account system cannot flexibly change its verification logic in the future, then many of today's discussions about wallet experience could ultimately evolve into security issues.
Although, from a practical protocol advancement perspective, EIP-8141 is still too heavy, especially regarding client implementation, transaction pool security, and verification complexity, and a sufficiently solid consensus has not yet been formed.
But standing at this point in time, there seem to be more and more aspects of EIP-8141 worth discussing and scrutinizing seriously.
I. What Problem Does EIP-8141 Actually Aim to Solve?
EIP-8141, promoted by Vitalik Buterin, timbeiko, and other core contributors, is formally named Frame Transactions.
To put it in simpler terms, its goal isn't merely to add a specific wallet feature. Instead, it attempts, at the protocol level, to free any account from being bound to a single ECDSA signature path, allowing for more flexible verification and execution logic.
This also means that multisig, gas sponsorship, key rotation, social recovery, and even future integration of quantum-resistant signature schemes are no longer just external capabilities bolted onto the wallet but have the opportunity to become "native members" within the Ethereum account system.
On the surface, EIP-8141 discusses a set of very specific capabilities: paying gas with stablecoins, bundling 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 around wallet experience over the years, from ERC-4337 to EIP-7702, have been essentially making accounts more than just a private key, but an entry point with customizable rules.
The problem is, these improvements do make wallets increasingly resemble smart accounts, but they have never truly touched the most fundamental default account model of Ethereum.
As is well known, under the current system, Ethereum accounts are broadly divided into two types. One is Externally Owned Accounts (EOAs), the most familiar type, controlled by a private key, capable of initiating transactions actively, but lacking programmability. The other is Contract Accounts, which are smart contracts themselves; they 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 this premise remains unchanged, many capabilities that users today take for granted—such as flexibly changing signature rules, having others pay gas, recovering account control after losing a private key, or smoothly migrating to a new cryptographic system in the future—are difficult to truly become default capabilities of an account.
If you have used imToken or other Web3 wallets, you have likely encountered these pain points: for example, having a bunch of USDC in your wallet but being unable to send a transaction without ETH (because gas can only be paid with ETH); losing your seed phrase means permanently losing your funds, with no recovery option; an "approve + swap" operation requiring two signatures and two confirmations, etc.
These problems are not because wallet products are "not good enough," but are a result of the design of the Ethereum account model itself.
From this perspective, the evolution over the past two years has actually been very clear: ERC-4337 got account abstraction running at the application layer without modifying the protocol; EIP-7702 further proved that EOAs are not entirely unexpandable, at least they can temporarily gain capabilities similar to smart accounts.
In other words, Ethereum does want account abstraction, but has been approaching it gradually in a more gentle and conservative manner. The emergence of EIP-8141 means this path has reached a new node. It is no longer satisfied with adding another layer of smart account capabilities on the periphery of the existing system, but instead attempts to embed account abstraction directly into the transaction model itself, allowing accounts to possess programmable verification and execution logic from the protocol level.
This is also why EIP-8141 is gaining renewed attention today. On one hand, the upper-layer wallet experience is getting closer to native account abstraction, and the protocol layer will eventually need to catch up. On the other hand, the long-term pressure from quantum computing is turning "whether an account can flexibly change its signature method" from a distant technical topic into a practical issue that must be seriously considered sooner rather than later.
II. How Does EIP-8141 Work?
Ultimately, EIP-8141 introduces a completely new transaction type—the Frame Transaction, with transaction type number 0x06.
If the basic logic of a traditional Ethereum transaction is one transaction corresponding to one call, what EIP-8141 aims to do is decompose a transaction into a set of "frames" that can be executed sequentially according to rules, thereby separating the three traditionally bundled actions: verification, payment, and execution.
Each "frame" has three execution modes:
- VERIFY (Verification Frame): Responsible for verifying whether the transaction is legal. It runs the account's custom verification logic. If it passes, it calls the newly introduced APPROVE opcode to authorize execution and specify the gas limit.
- SENDER (Sender Frame): Executes the actual operation, such as transferring funds or calling a contract. The caller address is the transaction sender themselves.
- DEFAULT (Entry Frame): Uses the system entry address as the caller, used for scenarios like deploying contracts or verifying Paymaster;
The significance of this mechanism is not that transactions can become more complex, but that it decouples the three actions—"verification, payment, execution"—from the account actions for the first time and entrusts their scheduling natively to the protocol.
After all, in the past, who verifies the transaction, who pays the gas, and who executes the real operation were basically tied to the same account action. Under the design of EIP-8141, these tasks can be split into different frames and executed sequentially by the protocol in a clear order. Precisely because of this, accounts are no longer limited to relying on a single private key for a "holistic signature" and begin to take on a form closer to a programmable execution entity.
Take a concrete example: suppose you want to use USDC to pay gas for a Swap. Under the EIP-8141 framework, this could theoretically 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; subsequently, the corresponding asset is used to pay the fee; and finally, the actual swap operation is executed.
In this way, gas payment and the main transaction can be incorporated into the same atomic process—either all succeed or all roll back.
For users, the most直观的变化 (intuitive change) is that many operations that previously had to be split into two or three steps, with failure risks in between, can in the future更像一次完整动作 (more resemble a single complete action). Therefore, this atomicity is also one of the keys EIP-8141 aims to use to solve the problem of fragmented user experience.
So what does this mean for wallet users? Looking at the outcomes, the most直观的变化 (intuitive changes) are at least fourfold:
- Gas Payment is Abstracted: Having stablecoins in your wallet no longer means you must additionally prepare some ETH to operate. In the future, having DApps, Paymasters, or other sponsors pay gas on your behalf will become more native;
- Multi-step Operations are Merged: Processes like "approve + Swap" or "approve + stake," which often require multiple signatures now, have the opportunity to be packaged into a more complete operation;
- Account Security Rules are Opened Up: Multisig, social recovery, daily limits, timelocks, key rotation—these are no longer just advanced features provided additionally by a specific wallet product but begin to have the potential to be built upon more native account logic;
- Signature Schemes are No Longer Necessarily Locked into the Single Path of ECDSA: This gives accounts the protocol-level possibility for the first time to migrate to different cryptographic systems in the future, including post-quantum signature schemes;
III. Why Didn't It Become the Headliner of Hegotá?
A point that is easily overlooked but crucial for wallet users is: even if EIP-8141 is eventually implemented, the existing account system will not be completely overturned.
Even if you are currently using existing Web3 wallets like imToken, you will not need to migrate because it is backward compatible. Existing EOA addresses can continue to be used, only needing to "upgrade" the account's verification logic when appropriate.
But conversely, it is precisely because it changes things deeply enough that it did not directly become the headliner feature in the latest round of discussions for Hegotá. However, according to the 2026 EIP champion process, CFI (Considered for Inclusion) does not mean rejection but rather entry into a serious consideration stage, not yet the final decision for launch.
In other words, the core developers do not disapprove of the direction of EIP-8141; while acknowledging its value, they also believe it is currently still too "heavy."
After all, native account abstraction is not like ERC-4337, which could be gradually promoted first by a few wallets, infrastructures, and applications. Once it enters the protocol layer, it means all execution layer clients must seriously implement, test, and coordinate it. This naturally raises the barrier to advancement and makes core developers prefer caution during fork planning.
So what happens next? It can be viewed along two lines:
- Since EIP-8141 is in CFI status, it means it is still under continuous evaluation. The proposal authors will continue to supplement key details surrounding transaction pool security, verification rules, and client implementation. Subsequent ACD meetings will also re-examine whether it meets the conditions for further advancement;
- If these uncertainties can be continuously reduced, it has the opportunity to enter a more substantial inclusion stage in subsequent upgrades; if not, it could well be postponed to a later upgrade cycle;
To be realistic, EIP-8141 is not the only native account abstraction proposal, and it is itself not a ready-made post-quantum signature scheme—it cannot directly solve the quantum computing problem. But 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 is not whether it is the only correct answer, but that it places the question of "what should the final form of native account abstraction actually look like" very completely on the table of Ethereum protocol discussion for the first time.
It is not the only solution, but it is currently one of the most ambitious and closest to the imaginative upper limit of "complete native AA."
Regardless of whether EIP-8141 ultimately makes it into Hegotá, this discussion itself at least illustrates one thing:
Ethereum is not idly waiting for problems to ferment but is paving the way for the next-generation account system step by step, in a daily, gradual effort.
