EIP-8224: Counterfactual Transaction
Author: Ben Adams (@benaadams) Status/Category: Draft, Standards Track (Core) Created: April 12, 2026 Requires: EIP-196, EIP-197, EIP-1559, EIP-2718, EIP-2780, EIP-3529, EIP-4788, EIP-6780, EIP-7708, EIP-7904 Latest spec: ethereum/EIPs PR #11518
At a Glance
What it is. A new EIP-2718 transaction type (0x08) that lets a fresh, unfunded EOA pay gas by presenting a ZK proof (fflonk over BN254) that it owns an unspent private fee note in a canonical fee-note contract, rather than by holding a visible ETH balance.
Problem it solves. The "bootstrap problem": a brand-new EOA cannot pay gas privately, because receiving ETH from any funding source (exchange withdrawal, faucet, another wallet) creates a traceable on-chain link between the new address and its funder. EIP-8224 lets the EOA fund itself from a shielded pool instead.
Why an EIP-8130 reader should care. EIP-8130 authenticates and authorizes accounts through actor scopes and a payer/payer_auth model, but every path in that model, self-pay, self-pay-via-gas-key, sponsorship, assumes the payer address is already visible and funded on-chain. EIP-8224 does not compete with that model; it answers a question EIP-8130 does not address at all: how does an account acquire its first gas without a traceable funding transaction. The two are designed to compose, with EIP-8224 as a one-shot bootstrap step ahead of an EIP-8130 (or EIP-8223) payer relationship.
Overview
EIP-8224 is authored by Ben Adams (@benaadams), the same author as EIP-8223 (Contract Payer Transaction), and is explicitly framed as part of the same lineage: narrow, complementary infrastructure rather than a general account-abstraction framework. Where EIP-8223 solves recurring sponsored gas via a canonical payer registry, EIP-8224 solves the one-time problem of getting a fresh account its very first unit of gas without leaving a traceable deposit trail.
The mechanism is a shielded pool pattern familiar from privacy-preserving payment systems, applied narrowly to gas funding rather than general value transfer. A user deposits ETH into a canonical fee-note contract instance (identified by EXTCODEHASH, not a single fixed address) and receives a private Poseidon commitment in return. Later, from any fresh EOA, the user submits a counterfactual transaction carrying an fflonk ZK proof that they hold an unspent note covering the transaction's gas cost. The protocol verifies the proof, consumes the note's nullifier so it cannot be spent twice, settles gas from the note's value, and sends any leftover ETH to a gas_refund_recipient. The transaction body then executes normally against any target contract.
Core Design
Fee-note deposit and proof flow. (1) The user deposits ETH into a canonical fee-note contract instance and receives a private Poseidon commitment representing an unspent note. (2) From a fresh EOA, the user submits a counterfactual transaction carrying an fflonk proof, over the BN254 curve, that they own an unspent note covering the gas requirement. (3) The protocol verifies the proof, no EVM execution involved, consumes the note's nullifier, settles gas, and routes any leftover ETH to gas_refund_recipient. (4) The transaction body executes as a normal call against any contract.
Proof system choice. fflonk over BN254 reuses the existing powers-of-tau ceremony (a universal setup, no circuit-specific trusted setup), verifies with a 2-pair pairing check, and costs roughly 176,000 gas to verify.
Censorship resistance via append-only roots. Accepted roots are append-only and never revoked, so old proofs remain valid forever. This is a deliberate anti-censorship design: a validator cannot retroactively invalidate a user's proof by forcing a root rotation.
Arbitrary note values. Notes are not restricted to fixed denomination tiers, and chain_id is bound directly into the proof as cross-chain replay protection.
Gas cost breakdown. Intrinsic gas is dominated by proof verification: base cost (EIP-2780) 4,500; fflonk verification 176,346; fee-note state access 6,800; fee-note state mutation 22,500; ETH transfer logs (EIP-7708) 3,512, for a fixed subtotal of 213,658 gas, plus roughly 8,192 gas for proof calldata (approximately 512 bytes), for a typical minimum total near 222,000 gas.
One-shot bootstrap pattern. EIP-8224 is intended to be used once per account: fund a fresh smart account, register it in EIP-8223's payer registry (or an EIP-8130 payer relationship), and let all subsequent transactions use cheap, non-shielded sponsored gas. It is not designed as a repeated payment rail.
Mempool Strategy
Validation is bounded cryptographic computation, an fflonk proof check, plus a canonical code-hash check (EXTCODEHASH against the known fee-note contract bytecode) plus fixed storage reads. There is no EVM execution in the validation path at all. This places EIP-8224 firmly in the minimal-mempool-complexity tier alongside EIP-8223's static payer-registry reads and EIP-8141's self-relay validation-prefix shapes: no banned-opcode lists, no arbitrary-gas simulation, and a deterministic, boundable worst-case verification cost per transaction.
By contrast, EIP-8130's mempool acceptance for a sponsored transaction is also comparatively cheap, an actor_config SLOAD plus authenticator-allowlist check, but that cost is amortized across every ordinary sponsored transaction. EIP-8224 is a heavier one-time cost (fflonk verification dominates at ~176K gas) paid exactly once at bootstrap, in exchange for breaking the on-chain link between funder and new account. The two are not really substitutes: EIP-8130 optimizes recurring sponsored-transaction validation, EIP-8224 optimizes for privacy at the single funding event.
Key Differences from EIP-8130
| Aspect | EIP-8224 | EIP-8130 |
|---|---|---|
| Transaction type | New EIP-2718 type 0x08 | New EIP-2718 type 0x79 (AA_TX_TYPE) |
| Problem addressed | Funding a fresh EOA privately (the bootstrap problem) | General account abstraction: custom authentication, batching, gas sponsorship |
| Core mechanism | fflonk ZK proof of an unspent fee-note commitment | Actor authorization via authenticator contracts, scope bits, actor_config storage |
| Validation model | Bounded crypto (proof verify) + fixed storage reads, no EVM | Authenticator STATICCALL (or native ecrecover for k1) + actor_config SLOAD, no arbitrary wallet-code execution during validation |
| Gas sponsorship | Not modeled directly; produces funded ETH for the receiving account to spend | Native payer/payer_auth fields with SELF_PAYER/SPONSOR_PAYER scope grants |
| Privacy properties | Shielded: funding source unlinkable to the funded account via Poseidon commitments and nullifiers | None: sender, payer, and actor identities are all visible on-chain |
| New cryptographic primitives | fflonk over BN254 (reuses EIP-196/197 pairing precompiles) | None beyond existing secp256k1/P-256/WebAuthn authenticators |
| Replay protection | chain_id bound into the proof; nullifier consumption prevents double-spend of a note | Nonce sequence (standard/2D) or expiry + replay_id dedup (nonce-free mode) |
| Scope of change | Narrow, single-purpose, complementary | Broad: new transaction type, system contract, authenticator interface, nonce manager, lock mechanism |
| Cross-chain design | chain_id binds proof to one chain per spend | Accounts and account_changes explicitly portable across EVM chains via CREATE2 derivation and multichain change sequencing |
| PQ / signature-agility story | Not a signature-scheme proposal; ZK proof system is for privacy, not authentication agility | Canonical authenticator set is extensible (companion ERC) to add new signature schemes, including future PQ authenticators |
Activity
EIP-8224 has one PR: ethereum/EIPs#11518, opened April 12, 2026 by benaadams. As of this site's research date (July 15, 2026), it is very early stage, no merge, no review cycle, and no recorded community consensus. A Magicians discussion thread exists at https://ethereum-magicians.org/t/eip-8224-counterfactual-transaction/28205, though the proposal itself is young enough that substantive review activity has not yet accumulated.
Strengths
- Solves a real, specific gap (the bootstrap problem) that no other proposal in this comparison set, including EIP-8130, addresses at all.
- No EVM execution in the validation path: bounded, deterministic gas cost makes mempool acceptance cheap to reason about.
- Universal-setup proof system (fflonk over BN254) avoids a circuit-specific trusted-setup ceremony, reusing existing powers-of-tau infrastructure.
- Append-only, never-revoked accepted roots remove a censorship vector: a validator cannot invalidate a user's already-generated proof.
- Explicitly designed to compose with other proposals (EIP-8130, EIP-8175, EIP-8223) as a one-shot bootstrap step, not a competing general framework.
- Arbitrary note values avoid the anonymity-set fragmentation that comes with fixed denomination tiers.
Weaknesses
- Very early stage: a single open PR with no review cycle, no merged status, and no accumulated community feedback as of this site's sync.
- ~222,000 gas typical minimum cost is substantially heavier than an ordinary sponsored transaction under EIP-8130 or EIP-8223; it is only economical as a one-time bootstrap, not a repeated payment rail.
- Adds a new cryptographic dependency (fflonk verification) and a new system contract (canonical fee-note instances) that must themselves be trusted and audited.
- Privacy guarantees depend on anonymity-set size in practice: a note pool with few participants offers weaker unlinkability than the proof system alone suggests.
- Does not address gas sponsorship or general account authorization; it is strictly complementary and needs a payer/authorization layer, EIP-8130, EIP-8223, or otherwise, to be useful beyond the first transaction.
Continue with Competing Standards for the comparative analysis, or return to the Home page.