Frame Transactions: Setting Ethereum Transaction Free

Key Takeaways

• EIP-8141, known as "Frame Transaction," is currently under consideration for inclusion in the Hegota hard fork. It separates the authentication, payment, and execution of Ethereum transactions, making each independently programmable. This allows Ethereum transactions to freely choose their signature algorithm (passkeys, quantum-resistant signatures, etc.), and enables features like gas fee sponsorship and batched execution of multiple calls within a single transaction at the protocol level.

• Frame Transaction is more than a UX improvement. It is the foundation for Ethereum's broader direction, including quantum resistance, censorship resistance, and privacy, while also addressing the demands of an era defined by AI agent delegation. Vitalik described Frame Transaction as "an omnibus that wraps up and solves every remaining problem that AA was facing, and the culmination of nearly a decade of research."

• Frame Transaction creates the conditions for Ethereum to evolve on its own without hard forks. Just as the EVM made the execution layer programmable through smart contracts, allowing diverse programs to be added to Ethereum without hard forks, Frame Transaction makes the verification layer programmable, enabling authentication innovations, both present and future, to happen without protocol modifications. This maps directly to the Ethereum Foundation's "walkaway test" vision: a protocol that remains sustainable even without the Foundation.

0. Introduction

From Ethereum's birth in 2015 until now, every transaction on the network has been trapped within a single fixed mold. Authentication must use ECDSA signatures. Gas fees must be paid by the signer in ETH. A single transaction can only execute a single call.

Because these three constraints are hardcoded into the protocol, changing the signature scheme, having a third party cover gas fees, or bundling multiple actions into one transaction are all impossible. In an era where tens of millions of smart accounts operate onchain, AI agents execute transactions on behalf of users, and quantum computing threatens existing cryptographic schemes, this rigid transaction structure is becoming Ethereum's bottleneck. Can Ethereum transactions break free from these constraints?

Source: forkcast

On March 26, 2026, during the All Core Devs Execution (ACDE) call, a biweekly meeting where core developers discuss Ethereum protocol changes, EIP-8141, known as "Frame Transaction," was added as CFI (Considered for Inclusion) for the Hegota hard fork. It did not receive headliner status, which would mean the fork cannot ship without it, but the inclusion still matters: native Account Abstraction has officially entered the review pipeline at the protocol level.

EIP-8141 is a proposal initially drafted on January 29, 2026 by Vitalik Buterin and others. Its core purpose is to make the transaction validation stage programmable. Until now, every Ethereum transaction has been bound to a single authentication scheme: ECDSA signatures. Frame Transaction dismantles this fixed structure and allows validation logic itself to be freely programmed on top of the EVM. On February 28, Vitalik described the proposal on the Ethereum Magicians forum as "an omnibus that wraps up and solves every remaining problem that AA was facing, and the culmination of nearly a decade of research."

While proposals like ERC-4337 and EIP-7702 have implemented account abstraction as workarounds without modifying the Ethereum protocol, EIP-8141 is an attempt to enshrine AA into the protocol itself. The sections below trace how this connects with Ethereum's core directions of account abstraction, quantum resistance, censorship resistance, and privacy, as well as the shifting demands of an era defined by AI agents.

1. Technical Structure of Frame Transaction

The core idea is to decompose a single transaction into multiple stages.

Consider the structure of a current Ethereum transaction. Three things are bundled together in a single monolithic unit: "authenticate via ECDSA signature," "call a single target," and "sender pays gas in ETH." If you want to change even one of these, you need to modify the protocol itself. You cannot use a different signature scheme per transaction, a third party cannot sponsor gas fees, and you cannot batch multiple calls into one transaction.

Frame Transaction breaks this fixed monolith into a sequence of independent units called "frames." A single transaction contains multiple frames, each taking on a specific role such as "verify identity," "determine gas payment," or "execute the intended action." Once authentication, execution, and payment are separated, each can be programmed independently. Whether you want to use passkeys for Face ID authentication instead of ECDSA, pay gas in USDC, or sequentially call five contracts within a single transaction, you simply compose the right frames.

1.1 Transaction Format

Here is the payload structure of the EIP-1559 transaction (type 0x02), the most widely used transaction type on Ethereum today.

The v, r, s at the end are the ECDSA signature values. Ethereum nodes perform ecrecover on these values to derive the sender address. In other words, the sender's identity is not explicitly stated in the transaction but extracted from the signature. Each transaction can only call a single target via the to field, and gas fees are always deducted from the sender's ETH balance.

Compare that to the payload of the frame transaction (type 0x06) introduced by EIP-8141.

Comparing the two structures side by side makes the differences unmistakable. First, the ECDSA signature values v, r, s are gone. The protocol-level dependency on ECDSA has been removed entirely. Second, the sender, which was previously derived from the signature, has been promoted to an explicit field. The answer to "is this sender the real owner?" is no longer provided by signature values but by verification code within the frames. Third, the single call target to and value have been replaced by a frames array. Instead of one fixed call, a sequence of frames defines the transaction's behavior.

Since the signature scheme is no longer hardcoded into the protocol, each account can freely choose which signature scheme to use in its VERIFY frame. Accounts can continue using ECDSA as before, switch to post-quantum signatures like CRYSTALS-Dilithium if quantum resistance is needed, or adopt passkeys (P256 curve-based WebAuthn) for general user onboarding. Using passkeys means device-native authentication such as Face ID, fingerprint recognition, or hardware security keys can be directly linked to transaction signing. All of this is determined solely by the code in the VERIFY frame, without any protocol changes.

Each frame is composed of [mode, target, gas_limit, data]. mode determines whether the frame is for verification, execution, or deployment. target is the address to be called, and gas_limit is the gas budget allocated to that frame. Gas is independent per frame, meaning unused gas does not carry over to the next frame.

1.2 Three Frame Modes

As mentioned above, each frame has a mode field that determines its role. There are three modes: VERIFY (verification), SENDER (execution), and DEPLOY (deployment).

1.2.1 VERIFY (Verification)

This is the frame that answers the question: "Did this person really send this transaction?" Previously, the protocol had the ECDSA ecrecover logic hardcoded, but within a VERIFY frame, any verification code can be freely executed.

The protocol demands exactly one thing from a VERIFY frame: if verification passes, call the new opcode APPROVE (0xaa). If APPROVE is not called, the entire transaction is invalidated. APPROVE has a scope parameter that allows fine-grained control over what is being approved. 0x0 approves execution rights only, 0x1 approves gas payment rights only, and 0x2 approves both. This separation of execution and payment rights is what enables sponsored transactions, where the user approves execution while a third party approves gas payment, at the protocol level.

For safety, VERIFY frames operate in read-only mode, similar to STATICCALL. Since they cannot modify onchain state, unintended side effects during the verification process are prevented.

1.2.2 SENDER (Execution)

SENDER is the frame where users perform what they actually want to do. ETH transfers, contract calls, and similar operations happen here. SENDER frames only execute after APPROVE has been called in a VERIFY frame, and from the perspective of the receiving contract, the call appears as if sender made it directly. Placing multiple SENDER frames in sequence allows batching multiple calls within a single transaction. Using the atomic batch flag ensures that if any one of them fails, the entire batch is rolled back.

1.2.3 DEPLOY (Deployment)

This frame is used when creating a new smart account for the first time. It allows account code deployment, verification, and execution to be processed atomically within a single transaction.

1.3 What About Existing EOA Users?

Once Frame Transaction is introduced, will the vast number of existing Ethereum account (EOA, Externally Owned Accounts) users need to migrate to smart accounts? The short answer is no.

When a VERIFY frame's target points to an address with no deployed code, i.e., a regular EOA, the EVM automatically executes built-in default verification code embedded in the protocol. This default code reads the approval scope and signature algorithm type from frame.data to perform verification, supporting ECDSA (secp256k1) and P256 (the curve used for passkeys) by default.

In other words, existing EOA users receive the benefits of Frame Transaction without doing anything. Their addresses do not change, and no migration is required. On a block explorer, you would simply see the VERIFY frame running default code to verify the ECDSA signature and calling APPROVE.

All previous AA proposals assumed that "users must first migrate to a smart account." EIP-8141 flips this assumption: the upgrade happens at the protocol level, and users discover it naturally.

2. Ethereum's Direction and Frame Transaction

2.1 Native Account Abstraction

What Frame Transaction changes at the deepest level is who gets to define "transaction validity." That authority moves from the protocol's fixed rules down to the application layer. Vitalik compared this to the EVM's own general-purpose programmability. What made the EVM such a powerful platform for Ethereum is that it allowed users to program the execution stage directly. Frame Transaction extends that same generality to the verification stage, making verification logic directly programmable.

Before EIP-8141, the verification stage was limited to hardcoded ECDSA. After it, any verification logic, whether multisig, passkeys, social recovery, session keys, or spending limits, can be freely defined in account code. From a developer's perspective, "write whatever logic you want, and call the APPROVE opcode at the end" is all there is to it.

2.2 Quantum Resistance: An Escape Route from ECDSA

Frame Transaction's VERIFY frame decouples transaction authentication from the ECDSA signature scheme. This provides a native pathway to upgrade accounts to quantum-resistant signature algorithms (such as CRYSTALS-Dilithium) that can replace the quantum-vulnerable ECDSA. Users can swap out their signing scheme without changing their wallet address.

As quantum computing research accelerates, quantum resistance on the execution layer (EL) has become just as critical a challenge as on the consensus layer (CL). Ethereum Foundation researchers have argued that if post-quantum security matters on the consensus layer, it must equally be addressed on the execution layer.

This is not simply about future-proofing. It is already becoming a practical requirement. As institutional adoption of blockchain becomes a reality, hybrid authentication schemes and enterprise-grade security using quantum-resistant signatures are emerging as increasingly concrete demands.

2.3 Censorship Resistance: How FOCIL and Frame Transaction Work Together

FOCIL (Fork-Choice Enforced Inclusion List, EIP-7805), the headliner proposal for Hegota, is a mechanism that allows 17 randomly selected participants per slot to enforce transaction inclusion. Even if a single block proposer intentionally excludes a transaction, it can still be included within 1-2 slots through other includers. Inclusion remains possible even if 100% of slots are sold to adversarial builders through PBS. Of the changes in Hegota, FOCIL does the most for Ethereum's censorship resistance.

The combination of EIP-8141 and FOCIL matters because Frame Transaction allows smart account and privacy protocol transactions to be submitted directly to the public mempool without wrappers. Previously, smart account transactions had to go through intermediaries called bundlers, creating potential points of censorship along the way. Once Frame Transaction makes smart account transactions first-class at the protocol level, FOCIL can receive and include them onchain directly. With no intermediary required, Ethereum achieves protocol-level censorship resistance.

2.4 Privacy: Protocol-Level Support

In a March 23, 2026 post on X, Vitalik emphasized that EIP-8141 "makes privacy protocols much more first-class." Current Ethereum privacy protocols must use wrapper transactions or relayers to conform to the standard transaction format, and this intermediary layer itself becomes a vulnerability for privacy.

Frame Transaction increases the degrees of freedom in verification logic, allowing privacy protocols to perform their own zero-knowledge proof (ZKP) based verification directly within a VERIFY frame. They can submit to the public mempool without wrappers and be included without censorship through FOCIL. The need for a separate infrastructure stack for privacy disappears. Through Frame Transaction, Ethereum can implement selective privacy at the protocol level.

This is why Vitalik called Frame Transaction a "powerful omnibus." Just as the EVM became a powerful omnibus by granting general-purpose programmability to the execution stage, Frame Transaction extends that same generality to the verification stage, which had been limited to hardcoded ECDSA.

2.5 AI Agents: Programmable Delegation

Frame Transaction's programmable verification also matters for the age of AI agents. For an AI agent to act onchain on behalf of a user, there must be precise control over "how much authority to grant this agent." Under the current structure, the only options are handing over the entire private key to the AI or adding a separate smart contract layer.

The VERIFY frame provides a protocol-level solution. Because the authentication process itself is programmable, limited permissions can be granted to an agent using a session key approach, and conditional delegation logic such as "allow swaps of up to 1,000 USDC on Uniswap for 24 hours" can be implemented directly in the VERIFY frame's verification code. If the AI agent's key attempts a transaction outside this scope, APPROVE is not called and the transaction is invalidated. Constraints such as spending limits, allowed contract lists, and validity periods can be enforced at the verification layer.

Gas sponsorship through Frame Transaction also maps well to the AI agent workflow. Agent accounts do not need to hold ETH directly. Instead, the service provider or the user who owns the agent can sponsor gas through the APPROVE scope separation. Complex agent workflows that sequentially call multiple DeFi protocols can also be batched into a single transaction using SENDER frame atomic batches, with the entire batch rolling back if any intermediate step fails, allowing onchain financial activities to be safely delegated to agents.

3. Conclusion

Frame Transaction extends the programmability that the EVM granted to the execution layer to the verification layer.

The core difference between Ethereum and Bitcoin is that the EVM made general-purpose programming possible on the execution layer. This is what enabled the onchain innovations we see today: DeFi, NFTs, DAOs. Frame Transaction does the same for the verification layer. More than a UX improvement, this is a redefinition of "validity," the most basic concept of a transaction.

From a longer-term perspective, this change is connected to Ethereum's vision of self-sustainability. On March 13, 2026, the Ethereum Foundation published the 38-page EF Mandate, declaring: "We were Ethereum's first steward. Now we are one of many, and when we are gone, we hope the principles here will continue on without us." This philosophical direction, which Vitalik also calls the "walkaway test," is the principle that Ethereum must function perfectly even if the Foundation and its current developers vanished tomorrow.

Yet new security threats driven by technological advances, such as quantum computing, will always emerge. If a hard fork is required every time a new signature algorithm is needed or a new account feature is demanded, the protocol will forever depend on centralized governance coordination. If EIP-8141 makes verification logic programmable, quantum-resistant signatures or authentication methods not yet invented can be introduced at the account code level without modifying the protocol. Just as new DeFi protocols do not require an Ethereum hard fork thanks to the EVM, Frame Transaction opens the door for future authentication changes to happen without hard forks. If the protocol is to remain sustainable even after the Foundation disappears on its own terms, it must be able to evolve on its own.

If EIP-8141 ships in Hegota alongside FOCIL, Ethereum gets censorship resistance and native AA with quantum resistance in a single fork. That would make Hegota the most cypherpunk upgrade Ethereum has ever had.