SKIP TO CONTENT
ETHEREUM STANDARDS6 minSmart Accounts / Ep. 1 · Stage 1-2

EIP-8141 Frame Transactions: What Would Change for Gas?

Your account approves, a sponsor pays your gas, your call runs: in the EIP-8141 draft, all of it would ride in one transaction. What is left for bundlers?

XIN
Pixel-art night harbor: a crane lifts glowing modular cargo crates from an old floating barge onto a new stone pier built into the harbor wall. Most crates glow teal as they cross; one dim crate stays behind on the barge.

IN 30 SECONDS

A frame transaction is the transaction type EIP-8141 proposes: one list of calls that carries the account check, the gas payment and the actions. It is a Draft with no confirmed date. In it, paymasters need no stake, and the word “bundler” never appears.

KEY TAKEAWAYS · 3

  • In the EIP-8141 draft, one transaction holds 1 to 64 frames: the account approves, someone agrees to pay, the calls run.
  • The draft has no UserOperation, no EntryPoint contract and no paymaster staking. The word “bundler” doesn’t appear.
  • In the public mempool, only the canonical paymaster, matched by its exact code, can keep several transactions pending at once. Any other gets one.
On this page

What does an EIP-8141 frame transaction change?

IN SHORT In the 8141 draft, one transaction does the whole job: the account approves, someone agrees to pay, then the actions run.

WORDS TO KNOW

Frame transaction
The transaction type EIP-8141 proposes: a list of calls, called frames, that covers validation, gas payment and execution.
Paymaster
A contract that agrees to pay the gas (the network fee) for someone else’s transaction.
Mempool
The waiting room of pending transactions. Nodes check them there before a block includes them.

EIP-8141 is a Draft, scheduled for Hegota, a mainnet upgrade with no confirmed date (each L2 has its own calendar). Names and rules can still change.

A Frame transaction The transaction type EIP-8141 proposes: a list of calls, called frames, that covers validation, gas payment and execution. See the glossary (type 0x06) is a list of 1 to 64 frames, each a call with a mode.

IN PLAIN WORDS

A VERIFY frame only reads, and acts only through APPROVE, a new opcode (a basic machine instruction). A SENDER frame runs as the account. A DEFAULT frame runs as a protocol address, 0xaa, named ENTRY_POINT.

APPROVE can approve execution, payment or both, as flags for the whole transaction. No payment approval by the end, no valid transaction. A native batch flag can also make the actions all succeed, or none.

STEP BY STEP

Sequence diagram: 5 participants: Ethereum itself, Your account, Gas sponsor, Fee token, The appSequence diagram: 5 participants: Ethereum itself, Your account, Gas sponsor, Fee token, The app. Step 1: Ethereum itself to Your account, Check the signature, approve. Step 2: Ethereum itself to Gas sponsor, Check the refund, agree to pay. Step 3: Your account to Fee token, Send the fee to the sponsor. Step 4: Your account to The app, The user’s call. Step 5: Ethereum itself to Gas sponsor, Settle up: refund or convert.ETHEREUM ITSELF > YOURACCOUNTCheck the signature, approveETHEREUM ITSELF > GAS SPONSORCheck the refund, agree to payYOUR ACCOUNT > FEE TOKENSend the fee to the sponsorYOUR ACCOUNT > THE APPThe user’s callETHEREUM ITSELF > GAS SPONSORSettle up: refund or convert

Step 1. Frame 0: account check. VERIFY: the account checks the signature and approves.

Pick a step to see it move
  1. Frame 0: account check VERIFY: the account checks the signature and approves.
  2. Frame 1: sponsor check VERIFY: the sponsor checks that frame 2 sends it the right token amount, then approves payment. The spec notes it accepts some front-running risk.
  3. Frame 2: pay the sponsor SENDER: the account pays the fee in the token.
  4. Frame 3: the real call SENDER: the call the user wanted.
  5. Frame 4: settle up DEFAULT: the sponsor refunds or converts, like the old postOp.
Example 3 of EIP-8141, redrawn: the user pays a sponsor in an ERC-20 token (the standard token format). Draft as of 7 October 2026: names and rules can still change. Frames 0 and 1 are the validation prefix.

My mapping for ERC-4337 users: validation becomes VERIFY frames, postOp a DEFAULT frame, and the EntryPoint contract protocol logic. The UserOperation disappears.

ITEM GET

The transaction is the operation

In the draft, the account check, the payment and the calls ride in one transaction.

An address with no code gets “default code”. It approves with the secp256k1 signature an EOA key already makes, so it can batch and be sponsored without delegating. A frame aimed at a 7702 account runs its delegate’s code.

There is no 7702 authorization list, on purpose: the rationale says it “heavily relies on ECDSA cryptography”, which misses the post-quantum goal.

What happens to bundlers and paymasters?

IN SHORT The 8141 draft never mentions bundlers, and it turns paymasters into pay frames with no staking or reputation.

Frame transactions go straight into the node’s public Mempool The waiting room of pending transactions. Nodes check them there before a block includes them. See the glossary. It simulates (test-runs) only the validation prefix: the frames up to and including the one that sets the payer. What follows is outside those rules, but may not hold another VERIFY frame.

SPONSORED VALIDATION PREFIX
Flow diagram: 5 stepsFlow diagram: 5 steps. Create the account (optional), then The account approves. The account approves, then The sponsor agrees to pay. The sponsor agrees to pay, then The user’s calls. The user’s calls, then The sponsor settles up (optional).1Create the account(optional)2The account approves3The sponsor agrees to paySimulation stops here4The user’s calls5The sponsor settles up(optional)
A DEFAULT frame that calls a factory, such as the EIP-7997 factory the spec suggests. A VERIFY frame on the paymaster. The cap is MAX_VERIFY_GAS.
One of the four shapes the public mempool accepts: the account approves alone or with a sponsor, each with or without a create step first. Validation work is capped at 100,000 gas in the draft.

Paymasters change the most. ERC-4337 keeps a Paymaster A contract that agrees to pay the gas (the network fee) for someone else’s transaction. See the glossary’s deposit in the EntryPoint, asks it to limit its storage use or stake, and says bundlers should use a reputation system. The 8141 draft “removes staking and reputation entirely”.

Instead, a paymaster that wants several pending transactions at once in the public mempool must be the canonical one. Nodes recognize it by its exact code, built so ether only leaves as gas payment or after a delay.

1

pending transaction at a time for any other paymaster, in the public mempool

Source: EIP-8141, Draft as of 7 October 2026.

My read, not the spec’s: what’s left for a bundler is relaying what the public mempool won’t take, such as a non-canonical paymaster with several pending transactions. The draft says such transactions “may be accepted into a local or private mempool”.

The canonical paymaster has a single secp256k1 signer and takes no contract signatures. In the prefix, validation may only read the sender’s storage (SLOAD). TIMESTAMP, BALANCE, SELFBALANCE and SSTORE are banned.

Carve-outs: SSTORE to the sender’s storage in the first deploy frame, TIMESTAMP only in the protocol’s expiry check frame, and the canonical paymaster code, admitted by code match.

Sources: EIP-8141 (Draft), ERC-4337, ethereum.org, Hegota.

STAGE CLEAR

What you now know

  • How a frame transaction splits one job into frames: the account approves, a sponsor agrees to pay, then the calls run.
  • What a paymaster needs to keep several transactions waiting, and what the draft leaves for bundlers, in my reading.

Check yourself

Tap or click a question to see the answer.

A paymaster that isn’t the canonical one wants five sponsored transactions waiting in the public mempool at once. Can it?

No. In the draft it gets one pending transaction at a time there. The rest may go through a local or private mempool.

Next stage:Do ERC-7579 modules keep working under native account abstraction?6 min
Adam Boudjemaa
Adam Boudjemaa

Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.

Have a project to ship or a role to fill?

Discuss your project or role

My work at the web3 x AI intersectionOpen-source tools I build

LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.