Written by: imToken

Last week, at the Ethereum core developer meeting, the inclusion of EIP-8141 in the Hegota upgrade was officially discussed. Surprisingly, this proposal, which Vitalik personally supported, was not listed as a "headline feature" of Hegota but was given a "Considered for Inclusion" (CFI) status.

This week, the Google Quantum AI team released a new white paper stating that under their given hardware assumptions, the physical qubit estimates needed to break ECDLP-256 have decreased by 20 times compared to previous estimates. While this does not mean that quantum attacks are imminent, it serves as a reminder that if the account system cannot flexibly change verification logic in the future, many discussions about wallet experiences today may ultimately evolve into security issues.

From the perspective of protocol advancement, EIP-8141 currently still seems too heavy, especially regarding client implementation, transaction pool security, and verification complexity, where a solid consensus has not yet been formed.

However, at this moment, there seem to be increasingly more aspects of EIP-8141 worth discussing and examining seriously.

1. What exactly does EIP-8141 aim to solve?

EIP-8141 is promoted by Vitalik Buterin and core contributors like timbeiko, officially named Frame Transactions.

To summarize in simpler terms, it is not aiming to merely add a specific wallet feature but is trying to allow any account to be free from the constraints of a single ECDSA signature path from the protocol layer, enabling more flexible verification and execution logic.

This also means that multi-signatures, Gas sponsorship, key rotation, social recovery, and even future integration of quantum-resistant signature solutions may no longer just be capabilities externally attached to the wallet, but could become "native members" of the Ethereum account system.

On the surface, EIP-8141 discusses a set of seemingly concrete capabilities: paying Gas with stablecoins, consolidating multiple operations into a single transaction, supporting more flexible signature methods, and even reserving space for future quantum-resistant signatures. Over the years, many improvements related to wallet experiences, from ERC-4337 to EIP-7702, have essentially aimed to turn accounts from merely a private key into an entry point with customizable rules.

The problem is that these improvements have made wallets increasingly resemble smart accounts but have never truly touched upon Ethereum's fundamental default account model.

As is well-known, Ethereum accounts are generally divided into two categories under the existing system. One category is externally owned accounts (EOAs), which are familiar to everyone; they are controlled by private keys, can actively initiate transactions, but lack programmability. The other category is contract accounts, which are smart contracts themselves; they can execute complex logic but cannot independently initiate transactions.

This has resulted 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 take for granted today—such as flexibly changing signature rules, allowing others to pay Gas, recovering account control after losing private keys, or smoothly transitioning to new cryptographic systems in the future—are unlikely to genuinely become the default capabilities of accounts.

If you've used imToken or other Web3 wallets, you've likely encountered these pain points, such as having a lot of USDC in your wallet but not being able to send a transaction without ETH (because Gas can only be paid with ETH); losing your mnemonic phrase resulting in permanently losing money; needing to sign twice and confirm twice for an "authorization + swap" operation, etc.

These issues are not due to wallets being "not good enough," but rather are a result of the design of the Ethereum account model itself.

From this perspective, the evolution over the past two years has been quite clear; ERC-4337 has initiated account abstraction at the application layer without modifying the protocol. EIP-7702 further demonstrated that EOAs are not entirely non-extensible and can at least temporarily achieve some capabilities close to those of smart accounts.

In other words, Ethereum does not ignore account abstraction but has been gradually approaching it in a more gentle and conservative manner. The emergence of EIP-8141 signifies that this path has reached a new milestone. It no longer contents itself with simply layering smart account capabilities on the existing system but attempts to embed account abstraction directly into the transaction model itself, enabling accounts to possess programmable verification and execution logic from the protocol layer onward.

This is also why EIP-8141 has gained renewed attention today. On one hand, the upper-layer wallet experience has increasingly approached 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 prompting the question of whether accounts can flexibly change signature methods to transition from a distant technical topic to a pressing real issue that needs serious consideration.

2. How does EIP-8141 work?

Ultimately, EIP-8141 introduces a brand new transaction type—Frame Transaction, with the transaction type number 0x06.

If the basic logic of traditional Ethereum transactions is that one transaction corresponds to one call, then what EIP-8141 aims to do is break down a transaction into a set of "frames" that can be executed in a rule-based sequence, thus decoupling the originally bundled verification, payment, and execution tasks.

Each "frame" has three execution modes:

• VERIFY (Verification Frame): Responsible for validating whether the transaction is legitimate; it will run the account's custom validation logic, and if valid, it calls the newly introduced APPROVE opcode to authorize execution and specify the Gas limit.
• SENDER (Sending Frame): Executes actual operations, such as transferring funds or calling contracts. The caller address is the transaction sender themselves.
• DEFAULT (Entry Frame): Uses the system entry address as the caller, used for deploying contracts, validating Paymasters, and other scenarios;

The significance of this mechanism is not that transactions can become more complex, but rather that it is the first time to decouple the "verification, payment, and execution" into distinct frames, managed natively by the protocol.

After all, in the past, who validates the transaction, who pays Gas, and who performs the actual operation have all been tied to the same account action, whereas under EIP-8141's design, these tasks can be separated into different frames executed sequentially by the protocol, allowing accounts to rely on more than just a single private key for a "whole signature," moving them closer to a programmable execution entity.

For example, let's say you want to use USDC to pay Gas for a swap transaction; under the EIP-8141 framework, this can theoretically be organized into a complete frame process: first, the account verifies the signature and execution permissions, then the payer or Paymaster verifies their willingness to cover the costs, followed by completing the corresponding asset payment, and finally executing the actual swap operation.

Thus, Gas payment and the main transaction can be included in the same atomic process, where either everything succeeds, or everything rolls back.

For users, the most intuitive change is that many operations that previously had to be broken into two or three steps, with intermediate failure risks, can now resemble a single complete action. Therefore, this atomicity is also one of the key aspects EIP-8141 aims to resolve in terms of fragmented user experiences.

So what does this mean for wallet users? Observably, at least four significant changes emerge:

• Gas payment is abstracted: Having stablecoins in your wallet no longer means you must additionally prepare some ETH to operate; in the future, DApps, Paymasters, or other sponsors covering Gas will become more native;
• Multi-step operations are consolidated: Processes like "authorization + swap" and "authorization + staking," which currently often require multiple signatures, may have the opportunity to be bundled into a more complete operation;
• Account security rules are opened up: Multi-signature, social recovery, daily limits, time locks, key rotation, etc., will no longer be just advanced features provided by certain wallet products but start to have the potential to be built on more native account logic;
• Signature schemes are no longer locked to a single ECDSA path: This allows accounts to transition to different cryptographic systems in the future, including post-quantum signature schemes, for the first time offering a possibility at the protocol layer.

3. Why did it not become the headline feature of Hegotá?

One easily overlooked yet crucial point for wallet users is: Even if EIP-8141 is eventually implemented, the existing account system will not be entirely overthrown.

Even if you are currently using existing Web3 wallets like imToken, there is no need to migrate, as it is backward compatible; existing EOA addresses can continue to be used, and you only need to choose to "upgrade" the verification logic of the account at the appropriate time.

However, conversely, it is precisely because it is modified deeply enough that it did not directly become the headline feature of Hegotá in the latest discussions. However, according to the EIP champion process for 2026, the meaning of CFI (Considered for Inclusion) is not a denial but an entry into serious consideration, although it has not reached the point of final decision for implementation.

In other words, core developers recognize the direction of EIP-8141, but while acknowledging its value, they also feel it is still too "heavy" at present.

After all, native account abstraction cannot be driven progressively by a few wallets, infrastructure, and applications like ERC-4337. Once it enters the protocol layer, it entails that all execution layer clients must seriously implement, test, and collaborate, which naturally raises the bar for advancement and leads core developers to be more cautious in fork planning.

So, what will happen next? We can look at it from two lines:

• Since EIP-8141 is in CFI status, it indicates that it is still under ongoing evaluation. The proposal authors will continue to supplement critical details concerning transaction pool security, verification rules, and client implementation. Follow-up ACD meetings will also reassess whether it meets the conditions for further advancement;
• If these uncertainties can be continuously mitigated, it may have the opportunity to enter a more substantive inclusion phase in the upcoming upgrades; if not, it may very well be postponed to a later upgrade cycle.

To be pragmatic, EIP-8141 is not the only native account abstraction proposal and, in itself, is not a ready-made post-quantum signature solution; it cannot directly solve the quantum computing problem. However, its significance lies in the fact that it provides the first protocol-level exit for accounts to break free from the single path of ECDSA.

From this perspective, the true value of EIP-8141 does not lie in whether it is the only correct answer but in that it has placed the question of "what should the end goal of native account abstraction look like" very comprehensively on the discussion table of the Ethereum protocol for the first time.

It is not the only solution, but it is indeed one of the most ambitious and closest proposals to the "complete native AA" imaginative limit.

Regardless of whether EIP-8141 can ultimately keep pace with Hegotá, this discussion has at least indicated one thing:

Ethereum is not waiting idly for problems to brew; it is laying the groundwork for the next generation of account systems step by step.