The Hegotá EIP stack, explained

The one idea everything hangs off

An ordinary Ethereum transaction proves who sent it with a single ECDSA signature. The protocol checks that signature, charges the sender for gas, and runs the call. Authentication is fixed, and the person who authenticates is always the person who pays.

Frame transactions replace that signature with a sequence of small execution steps called frames. Instead of the protocol verifying a signature, the transaction carries code that runs on-chain and calls an opcode, APPROVE, to say “yes, this is authorised, and here is who pays.”

Once authentication is a program rather than a fixed algorithm, three things fall out that were previously impossible:

• Any verification scheme works. A passkey, a multisig, a social-recovery rule, a zero-knowledge proof. If you can express it in EVM code, it can authorise a transaction.
• The sender and the payer can differ. One account proves identity, a different account settles the gas bill. This is what people mean by “sponsored” or “paymaster” transactions, done natively instead of bolted on.
• Several operations become one atomic unit. Approve a token and swap it in a single transaction that either fully happens or fully does not.

Everything else in this document is either an extension of that idea, a piece of plumbing it needs, or a rule about how the network is permitted to treat the result.

How they fit together

The eight EIPs are not a flat list. There is a base, a set of extensions that widen it, a separate axis about censorship resistance, and a layer of pre-existing machinery they all stand on.

Read it in four groups:

• The base. EIP-8141 defines the new transaction type. Nothing else in the stack means anything without it.
• The extensions. 8250, 8272 and 7906 each add a field or a frame kind to that base. 8312 does too, but on its own schedule.
• The other axis. 7805 and 8369 are about censorship, not authentication. They say what a builder must include and what happens when it does not.
• The ground. 7928, 8037 and 7843 already shipped in the previous fork. The stack borrows their machinery rather than reinventing it.

Frame Transactions

The problem: a transaction’s signature check is hard-coded, and whoever signs must also pay. The fix: a new transaction type whose authentication is a small program you supply.

What a frame transaction looks like

It is transaction type 0x06. Where a normal transaction has v, r, s, this one has a list of frames:

0x06 || rlp([chain_id, nonce, sender, frames, signatures,
             max_priority_fee_per_gas, max_fee_per_gas,
             max_fee_per_blob_gas, blob_versioned_hashes])

each frame = [mode, flags, target, gas_limit, value, data]

A frame is one execution step. It has its own gas limit and its own target, and the mode byte says what role it plays:

The validation prefix, and why it matters everywhere else

The leading VERIFY frames are called the validation prefix. This is the part that establishes two facts before any real work happens: that the transaction is authorised, and who the payer is.

The prefix must match one of exactly four recognised shapes. This restriction is not cosmetic; it is what lets a node reason about an unfamiliar transaction cheaply.

Remember the prefix. Nearly every hard question later in this document is really a question about it: how much gas it is allowed to burn, what state it is allowed to read, and whether a validator can afford to re-run it.

The opcodes it adds

Receipts change too

One frame transaction produces one receipt containing a receipt per frame, plus the payer’s address. So you can see that frame 1 succeeded, frame 2 reverted, and frame 3 never ran, all inside one transaction.

Keyed Nonces

The problem: one account has one nonce counter, so its transactions must execute in a strict line. The fix: give an account many independent counters.

A nonce stops replay attacks by forcing transaction n+1 to follow transaction n. That is fine for a personal wallet, and painful for anything shared. A sponsor paying for thousands of users, or a contract acting for many people, has one counter and therefore one queue: everything serialises behind everything else.

EIP-8250 replaces the single nonce field with two:

nonce_keys : 1..16 strictly increasing uint256   // which counters
nonce_seq  : u64                                 // the value they must all be at

Each key is its own independent replay domain. Two transactions from the same sender on disjoint key sets have no ordering relationship at all and can be included in either order, or simultaneously.

Note the address convention, which recurs: a predeploy for EIP-N lives at 0x…N. It makes the constants self-documenting.

Recent Roots

The problem: verification code often needs to check a proof against a recent commitment, but reading another contract’s mutable storage during validation is dangerous. The fix: declare the commitment in the signed envelope instead.

Consider a privacy protocol. To spend, you prove membership in a Merkle tree whose root lives in some contract’s storage. Your validation code needs that root.

Reading it directly creates a problem the whole network feels. That storage slot is shared: it changes whenever anyone else uses the protocol. So a single change can invalidate every pending transaction that read it at once, which is exactly the mass-invalidation behaviour a mempool cannot tolerate.

EIP-8272 lets the transaction carry the roots it depends on, as signed data:

recent_root_references : [ (source_id, slot, root), ... ]   // up to 16

The protocol validates these against the RECENT_ROOT_ADDRESS predeploy at 0x…8272, which keeps a ring buffer of recent commitments. A reference is valid while its slot is within roughly the last 8191 slots. Validation code reads its own envelope with RECENTROOTREFLOAD (0xB5) and never touches shared storage.

Transaction Assertions

The problem: you cannot tell what a transaction actually did until it is already mined. The fix: attach a check that runs afterwards and can undo the work.

A wallet simulates a transaction, sees a fair-looking swap, and submits it. Between simulation and inclusion the world moves, and what lands is worse. Or a contract sneaks in a token approval the user never intended.

EIP-7906 adds POST_TX frames (mode 3): trailing frames that run read-only after the transaction body, can inspect everything it did, and can revert it.

Three opcodes let them see the result:

UTXO Frames

The problem: paying someone who has no account yet costs a permanent account entry in the world state. The fix: a one-shot payment object that leaves almost nothing behind.

Ethereum uses accounts. Bitcoin uses UTXOs: discrete coins that are created once and spent once. EIP-8312 adds a UTXO-shaped payment primitive alongside the account model.

You deposit to a vault at 0x…8312 naming a recipient. The protocol assigns an index and, at the end of the block, commits that block’s creations into a Merkle root. Spending is a new frame mode that runs no EVM code at all: the frame carries Merkle proofs, and the protocol checks them, flips an irreversible spent bit, and pays out.

So the complete create-and-spend cycle is about 2.2× cheaper in gas than a single ordinary transfer to a new account, and hundreds of times cheaper in permanent state. The state gap matters more than the gas gap, because under two-dimensional gas it is the state dimension that fills a block first.

The value is concentrated rather than general. This is a payments primitive, strongest for one-shot, high-volume payouts to recipients who do not exist on chain yet. It is not a replacement for accounts.

Fork-Choice Enforced Inclusion Lists

The problem: a block builder can quietly refuse to include your transaction forever. The fix: let a committee publish a list of transactions the next block must contain.

Everything above this point is about the execution layer. FOCIL is about the consensus layer, and it answers a different question: not “is this transaction valid” but “is the network allowed to ignore it”.

Each slot, a committee of 16 includers each publish an inclusion list. The next block builder is expected to include those transactions. Attesters check afterwards, and a builder that left one out without a good reason does not get their votes.

“Without a good reason” is the whole design. An omission is excused when the transaction genuinely could not have been added: it would not fit in the remaining gas, its nonce is wrong, its balance is too low. Those checks are cheap for ordinary transactions, which is why FOCIL works today.

VOPS Profiles for FOCIL Eligibility

The problem: checking whether a frame transaction was unfairly excluded could cost more work than validators can afford. The fix: only enforce the subset that is cheap enough to check.

The answer is to sort transactions into profiles. If a transaction fits a profile, its omission is enforceable. If it does not, it can still be listed and included, but nobody is punished for leaving it out.

The three limits that make it affordable

A bounded state surface. A qualifying validation prefix may read the sender’s and payer’s balance and nonce, and only their first few storage slots, a count called AA_VOPS_SLOT_COUNT. Reading anything else does not make the transaction expensive, it makes it ineligible. That numeric bound is also what excludes mapping entries, whose slots are keccak hashes and therefore enormous numbers.

A gas budget. Each transaction may declare at most 2²⁰ gas of validation work, and each inclusion list may hold 2²⁰ in total. Across 16 includers that is about 16.8M gas of replay per slot, roughly 28% of a 60M block. The EIP states that figure and openly flags that it is not yet a settled number.

A named index. Instead of forcing builders into a quadratic “try appending at every position” loop, the builder simply commits to a position and attesters check there. If the builder names nothing, the default is the end of the block.

EIP-8369 is Informational, which means it describes the model but binds nobody. Actual enforcement needs a further Standards Track EIP that does not exist yet, and AA_VOPS_SLOT_COUNT has no agreed value.

The machinery underneath

These arrived in the previous fork. The stack leans on them heavily, and several things above only make sense once you know they exist.

EIP-7928 — Block Access Lists

Every block carries a structured record of the state it touched: which accounts, which storage slots, what changed. It was built for parallel execution and stateless clients. FOCIL reuses it for something else entirely: reconstructing what the world looked like at a given position inside a block, which is exactly what judging an omission at a named index requires.

EIP-8037 — Two-dimensional gas

Gas splits into an execution dimension and a state-growth dimension, each with its own limit. This is why EIP-8312’s tiny state footprint matters so much: a block runs out of state room before it runs out of compute, so the cheap-in-state option raises real throughput rather than just saving fees.

EIP-7843 — Slot number

The execution layer can read the current consensus slot. EIP-8272’s expiry window is expressed in slots, so recent roots depend directly on this.

One transaction, end to end

Here is a sponsored, passkey-authenticated, privacy-preserving payment that uses five of the eight at once. Follow the ordering, because the ordering is the design.

type 0x06 frame transaction
  nonce_keys  [0x9f3a…]        ← 8250: an independent replay lane
  recent_root_references [(…)] ← 8272: the commitment its proof needs

  frame 0  VERIFY  only_verify   ← the validation prefix
  frame 1  VERIFY  pay             establishes authorisation + payer
  ──────────────────────────────
  frame 2  SENDER                ← the body: the actual transfer
  frame 3  POST_TX               ← 7906: check nothing unexpected happened

1. Before any code runs, the protocol checks the keyed nonces (8250) and validates the recent-root references (8272). Both are decided up front, not during execution.
2. Frame 0 verifies the passkey signature. It reads its proof material from the envelope with RECENTROOTREFLOAD, never from shared storage, so no other user’s activity can invalidate it.
3. Frame 1 runs the sponsor’s logic and calls APPROVE. The sponsor is now the payer and is charged the maximum possible cost.
4. Frame 2 does the real work as the sender.
5. Frame 3 inspects the finished result with TXDIFF. If an invariant broke, it reverts frame 2 — but frames 0 and 1 stay committed and the sponsor still pays.
6. Separately, FOCIL (7805) may have listed this transaction. Whether a builder can be punished for omitting it is decided by 8369: frames 0 and 1 must fit the bounded state surface and the gas budget.

Notice that the validation prefix, frames 0 and 1, is doing three jobs at once. It authenticates, it decides who pays, and it is the thing FOCIL has to be able to afford to re-run. Every difficult constraint in the stack lands on those two frames.

What this branch changes

These are all draft EIPs, so parts collide or are simply blank. hegota-devnet records every place it had to decide something the specs do not settle.

Two of these are worth understanding as a pattern rather than trivia. The mode 3 collision happens because two draft EIPs picked the same byte without a shared registry. The blank AA_VOPS_SLOT_COUNT happens because the spec author correctly refused to guess a number that needs measurement. Both are the ordinary texture of implementing drafts, and writing the decision down is what keeps the divergence honest.

How it switches on

Almost everything here activates together at the Hegotá fork, using one timestamp. Two things do not.

A useful habit

Giving a feature its own future timestamp, rather than folding it into a fork, means every block already produced re-executes identically. A running chain can adopt the feature without starting over. That is why EIP-8312 could be added to a live devnet, and it is a technique worth reaching for whenever a change is not yet certain.