EIP-8361 allows an EIP-8141 frame transaction to submit a succinct STARK alongside its peer-to-peer payload, enabling nodes to confirm that the validation prefix approved the transaction under declared state assumptions. Rather than repeatedly executing the same mechanism, nodes check a single proof, its dependencies, and the relevant state conditions, which may lower verification cost for complex account logic. The sections below trace how valid transactions obtain proofs, how nodes detect stale or fraudulent transactions, why the proof refers to the previous valid state without becoming a Merkle root, and why it disappears after block inclusion.
The explanation also distinguishes EIP-8361 from the two main types of rollup security: ZK proofs, which establish correctness before acceptance, and fraud proofs, which require a challenge process to show that an invalid transition occurred. It also clarifies limits involving ECDSA signatures, quantum safety, possible quantum-computer risks, and the proposal’s narrower role compared with scaling solutions. This technical breakdown is intended for wallet teams, client developers, prover operators, and users evaluating how proof-carrying transactions could enable more complex Ethereum validation while EIP-8361 remains a draft networking proposal rather than an active consensus rule.
Key Takeaways
-
EIP-8361 allows an EIP-8141 frame transaction to carry an admission proof as off-chain transport metadata.
-
An off-chain prover executes the validation prefix against declared assumptions and produces a STARK tied to the transaction, payer, dependencies, and validity conditions.
-
A receiving node performs stateless checks, verifies the proof and dependencies, and compares the assumptions with its current Ethereum state.
-
A valid proof permits mempool admission without repeating the complete validation-prefix simulation.
-
The proof does not determine block validity, alter execution, or become part of Ethereum’s permanent state. It is discarded after inclusion or removal from the mempool.
What Are EIP-8361 Transaction Validity Proofs?
EIP-8361 defines a proposed admission method for transactions created under EIP-8141. Its purpose is narrow: make certain computationally expensive transactions cheap enough for nodes to assess before forwarding them through the public mempool.
An EIP-8141 frame transaction can contain programmable logic that determines whether the sender authorizes the transaction, who will pay for execution, and whether specified conditions are satisfied. This logic appears in a validation prefix that runs before the transaction’s ordinary execution frames.
Under normal simulated admission, every receiving node may need to execute that prefix to determine whether the transaction should enter its mempool. EIP-8361 adds another option. A prover executes the prefix once off-chain and creates a cryptographic proof showing that it terminates with an APPROVE result and an identified payer.
The transaction and proof then travel together. The node verifies the proof rather than reconstructing the entire validation process.
The broader EIP-8361 framework is therefore concerned with proof-carrying mempool admission, while the EIP-8361 mempool validation process determines how receiving nodes decide whether to accept, retain, park, or remove these transactions.
As of August 6, 2026, EIP-8361 is presented in draft pull request #12075 as a Standards Track Networking proposal. It does not introduce a new transaction type or change Ethereum consensus by itself.
How Does the EIP-8361 Cryptographic Proof Work?
The proof covers a specific statement rather than claiming that every future execution outcome is known.
In simplified form, the prover must demonstrate that:
The validation prefix of transaction T, when evaluated under the declared assumptions and dependencies, follows the EIP-8141 trace rules and terminates with APPROVE and payer P, subject to the declared conditions.
The proposed public inputs bind the proof to five elements:
| Public input |
What it represents |
| sig_hash(T) |
A hash identifying the frame transaction |
| H(A) |
A commitment to the assumption vector |
| H(D) |
A commitment to declared proof or signature dependencies |
| P |
The account identified as the transaction payer |
| C |
Conditions governing when the approval remains applicable |
This binding matters because a valid proof for one transaction cannot simply be attached to another transaction with different data, dependencies, conditions, or payer information.
The private witness includes the information required to evaluate the prefix, including the contents of the declared dependency list. The resulting proof demonstrates the correctness of that computation without forcing every receiving node to repeat it.
EIP-8361 currently proposes reusing the proof format and ingress-verification machinery associated with EIP-8288. The EIP names STARKs because they can represent a large computation with a comparatively succinct proof and do not require every verifier to reproduce the original workload.
How Is the Assumption Vector Used in Transaction Validation?
A cryptographic proof can show that a calculation was correct for particular inputs, but a mempool node must still determine whether those inputs match the current Ethereum state.
EIP-8361 addresses this with an assumption vector, represented as A. It lists every state value read by the validation prefix. Proposed entries include an address, a storage key or balance reference, a comparison type, and a value.
Two comparison types are defined:
An exact EQ entry may be appropriate for a code hash, nonce, or storage branch whose meaning changes whenever the underlying value changes. A GEQ entry is more useful for monotonic requirements such as checking that a payer has at least enough funds to cover a prefund.
For example, suppose a smart account’s validation prefix approves a transaction only when a paymaster balance is at least 0.2 ETH. The prover can record a GEQ assumption with a threshold of 0.2 ETH. A node may continue treating the proof as applicable while the balance is 0.2 ETH or higher. It does not need a new proof every time the balance increases or changes above that threshold.
This design avoids anchoring the proof to a complete state root or requiring a large Merkle proof for the entire Ethereum state. The circuit evaluates the validation prefix against declared values, while the node checks those values against its own current state.
How Do Transaction Validity Proofs Work Under EIP-8361?
The proposed transaction validation process follows an ordered series of checks.
-
Run stateless checks. The node checks intrinsic transaction validity and confirms that the dependency or signature list is well formed. A malformed transaction is rejected before expensive proof verification.
-
Verify the admission proof. The node verifies the STARK against the designated verification key. Failure means the claimed validation computation has not been established.
-
Verify external dependencies. The proof may assume that signatures or other declared dependencies are valid. The node verifies those dependencies separately and confirms that their list matches the committed dependency hash.
-
Check validity conditions. The node evaluates the declared conditions, which may include deadlines, slot or epoch windows, expiry ranges, or nonce requirements.
-
Compare assumptions with live state. Each EQ entry is checked for equality, while each GEQ entry is tested against its threshold.
-
Admit the transaction. When every check succeeds, the node may accept and propagate the transaction without simulating its complete validation prefix.
This sequence prevents a proof from bypassing ordinary structural, signature, state, or timing checks. It changes the computational method used to reach an admission decision, not the transaction’s underlying validity requirements.
What Happens When Ethereum State Changes?
Mempool admission is not a permanent guarantee because Ethereum state continues changing after a transaction enters the pool.
Under EIP-8361, a node rechecks the validity conditions and assumption vector when a new block changes the chain head. It does not need to regenerate the proof, rerun the validation prefix, or verify the same proof again. The previously verified proof remains a cached result about the validation function under its declared inputs.
An EQ failure normally invalidates the proof because an exact input has changed. The node must evict the transaction unless the sender creates a new proof or the transaction qualifies for ordinary simulated admission.
A failed GEQ condition can be handled differently. The node may park the transaction instead of removing it completely. If the payer or paymaster later receives sufficient funds, the node can reactivate the transaction by checking the threshold again.
This distinction makes the assumption vector more than a Merkle-style commitment to one historical state. It defines which state changes actually invalidate the approval and which changes remain compatible with it.
Why Is the Proof Discarded After Block Inclusion?
The EIP-8361 proof is needed only for public-mempool admission and propagation. It is not the authoritative proof that the included transaction produced the correct state transition.
Once a validator includes the transaction in a block, Ethereum processes it through ordinary protocol execution. The EVM executes the validation prefix and the remaining frames according to the canonical block state. Consensus clients determine whether the block is valid using normal Ethereum rules.
Consequently, the admission proof:
-
is not placed in the block;
-
is not added to transaction calldata;
-
does not appear in the receipt;
-
does not become part of a Merkle tree or state root;
-
does not create a permanent on-chain state change;
-
does not need to be retained after the transaction is included or dropped.
Discarding it avoids permanent calldata cost and state growth for information that has already served its networking purpose. The transaction itself remains on-chain, but its temporary proof envelope does not.
EIP-8361 Proof System vs. ZK-Rollup Validity Proofs
EIP-8361 uses cryptographic proof technology, but its admission proof should not be confused with the validity proofs used by ZK rollups.
| Dimension |
EIP-8361 admission proof |
ZK-rollup validity proof |
| Main purpose |
Decide whether a transaction may enter and propagate through a public mempool |
Prove that a batch of Layer 2 state transitions is correct |
| Scope |
One frame transaction’s validation prefix |
A batch of L2 transactions and its resulting state transition |
| Verifier |
Receiving network nodes |
Usually an L1 verification contract |
| On-chain submission |
No |
Yes |
| Permanent protocol role |
None after admission or removal |
Authorizes or confirms an L2 state update |
| Privacy requirement |
Not inherently required |
May or may not provide privacy |
| Challenge period |
None |
Validity rollups do not rely on an optimistic challenge period |
ZK rollups commonly use ZK-SNARKs or ZK-STARKs to prove the correctness of transaction batches. Once the proof is accepted by the Layer 1 contract, the rollup can finalize the associated state transition without waiting for the fraud-proof challenge period used by optimistic rollups.
EIP-8361 does not prove an L2 batch, authorize immediate rollup withdrawals, or guarantee that an L2 chain can never enter an invalid state. Its proof is a temporary networking artifact about pre-inclusion validation.
Similarly, although zero-knowledge proofs can verify a statement without revealing all underlying witness data, EIP-8361 is not primarily a privacy proposal. “Succinct proof” and “zero knowledge” are related but not interchangeable properties.
Withdrawals from Layer 2 to Layer 1 can be faster with validity proofs because ZK rollups do not require the fraud-proof challenge period used by optimistic rollups. Final withdrawal time still depends on proof generation, Layer 1 verification, bridge rules, and Ethereum finality. EIP-8361 does not provide this withdrawal mechanism; its proof supports the mempool admission of an individual EIP-8141 frame transaction rather than the settlement of a Layer 2 transaction batch.
How Do Fraud Proofs Work in Optimistic Rollups?
Fraud proofs rely on a different security mechanism. An optimistic rollup initially accepts a proposed state transition and allows challengers to demonstrate fraud during a dispute period. Depending on the implementation, resolving a dispute can require multiple rounds or a narrowed execution proof.
EIP-8361 attempts to establish the required admission statement before the transaction is accepted into the relevant mempool class. There is no post-admission challenge period in which another participant proves that the prefix result was fraudulent.
The key difference is timing and scope:
-
A validity proof demonstrates a specified claim before acceptance.
-
A fraud proof permits an optimistic claim unless it is successfully challenged.
-
An EIP-8361 admission proof concerns mempool policy.
-
A rollup fraud proof concerns the correctness of an L2 state transition.
The technical trade-offs between repeated EVM execution and succinct verification are addressed in EIP-8361 versus transaction simulation, including where proof generation cost replaces node-side simulation cost.
EIP-8361, Complex Account Validation, and Post-Quantum Security
Programmable accounts may use multisignature authorization, key rotations, recovery rules, non-standard signature schemes, post-quantum signature candidates, spending policies, or gas-heavy zero-knowledge checks. Some of this logic may be valid but too expensive for every mempool node to simulate safely.
EIP-8361 tries to preserve public transaction propagation for these accounts by making validation expensive for the prover but comparatively cheap for each verifier. It may also reduce pressure to move complex authorization into the execution phase, where a failed check could become a paid and publicly recorded reverted transaction.
This mechanism does not make every smart contract secure or establish complete post-quantum security. A STARK may avoid some assumptions associated with elliptic-curve-based proof systems, but the transaction can still depend on public keys, signature schemes, client implementations, wallet code, or verification keys with separate security properties.
The resulting responsibilities for transaction creators, wallets, provers, and clients differ substantially, as summarized in the EIP-8361 wallet, node, and developer impact.
For example, a trader assessing whether Ethereum account-abstraction developments are influencing market sentiment can compare proposal milestones with the ETH/USDT market chart, although price action cannot confirm that a draft EIP has been implemented or adopted.
Risks and Limitations
EIP-8361 remains an early draft, so its proof format, limits, dependencies, terminology, and implementation details may change before standardization.
The mechanism also introduces several technical risks:
Proof-generation concentration: Producing a STARK can require specialized software and substantial computation. If only a few services can generate proofs efficiently, wallets may become dependent on centralized prover infrastructure.
Denial-of-service pressure: Proof verification is cheaper than repeating the original computation, but it is not free. Clients need consistent proof-size limits, peer rate limits, and failure attribution to prevent attackers from flooding nodes with invalid or oversized proofs.
Assumption completeness: The proof is only meaningful when the assumption vector contains every state read used by the validation prefix. A circuit or client bug that omits a dependency could produce incorrect admission decisions.
State staleness: A proof may remain cryptographically correct while its declared conditions no longer match current state. Nodes must continue rechecking A and C while the transaction remains pooled.
No execution guarantee: Mempool admission does not guarantee block inclusion or successful final execution. Another transaction may change the sender’s nonce, balance, code, storage, or other relevant state before inclusion.
Implementation complexity: Clients, wallets, and prover systems must agree on proof encoding, verification keys, dependency handling, peer behavior, and revalidation rules. Inconsistent implementations could fragment transaction propagation.
Is EIP-8361 Also the Tapered Issuance Burn Proposal?
Some early discussions associated the EIP-8361 number with a separate Ethereum monetary-policy proposal called Tapered Issuance Burn. That proposal was subsequently identified as EIP-8363, while EIP-8361 refers to Transaction Validity Proofs in the networking category. The two proposals are unrelated: EIP-8361 addresses proof-based mempool admission, whereas Tapered Issuance Burn changes consensus-layer reward economics according to the active staking balance.
Conclusion
EIP-8361 transaction validity proofs shift the expensive part of programmable transaction validation away from every receiving node and toward an off-chain prover. The resulting STARK binds an EIP-8141 transaction to its approval result, payer, dependencies, conditions, and state assumptions, allowing nodes to verify a concise claim before mempool admission.
The mechanism is most useful when a smart account has legitimate validation logic that exceeds practical simulation limits. Its principal constraint is equally important: the proof applies only to networking-layer admission. Ethereum still executes the transaction normally at inclusion, and the temporary proof is discarded because it has no consensus or on-chain role afterward.
FAQ
How do ZK rollups use validity proofs?
ZK rollups process transactions off-chain, group them into batches, and compute a validity proof for each batch. The proof, often built with ZK-SNARKs, ZK-STARKs, or polynomial commitments, lets an Ethereum contract verify that the resulting state transition is correct without replaying every transaction.
Do validity proofs guarantee that an L2 chain cannot become invalid?
Validity proofs prevent an L1 verifier from accepting an invalid state transition when the circuit, verifier contract, cryptography, and implementation work correctly. They do not eliminate risks involving faulty code, data availability, bridges, sequencers, governance, or upgrade controls.
Why are ZK-rollup withdrawals usually faster?
ZK rollups can finalize withdrawals after the validity proof is submitted and verified, without waiting through the fraud-proof challenge period used by optimistic rollups. Withdrawals may still depend on proof generation, batch submission, bridge rules, and Ethereum finality, so “immediate” does not always mean instant.
How do validity proofs differ from fraud proofs?
Validity proofs establish transaction correctness before a state transition is accepted. Fraud proofs work through an optimistic model in which a transition may be accepted temporarily and challenged later; many optimistic rollups use a challenge period of about seven days, although the exact duration varies.
Do zero-knowledge proofs always hide transaction data?
No. Zero-knowledge proofs can verify a statement without revealing its private witness, but privacy depends on which inputs remain hidden. Many ZK rollups use ZK proofs mainly for scalable transaction verification rather than fully private transactions.
What is the difference between ZK-SNARKs and ZK-STARKs?
ZK-SNARKs generally produce small proofs with low verification cost, although many designs require a trusted setup. ZK-STARKs require no trusted setup and are commonly considered more resistant to future quantum-computer attacks, but their proofs are often larger.
What does a Merkle proof verify?
A Merkle proof confirms that specific data belongs to a dataset represented by a Merkle root without revealing or downloading the full dataset. It proves inclusion or exclusion, not the correctness of an entire transaction batch or state transition.
Do validity proofs reduce on-chain resource consumption?
Yes, they can compress a large off-chain computation into a single proof that is cheaper to verify on-chain than replaying every transaction. The actual savings depend on proof verification cost, batch size, calldata or blob usage, and the rollup’s implementation.
Do validity proofs reduce the risk of a 51% attack?
Not directly. Validity proofs protect the correctness of verified Layer 2 state transitions, while a 51% attack concerns control over Ethereum’s consensus and fork choice. The two mechanisms address different security risks.
Are EIP-8361 proofs the same as ZK-rollup proofs?
No. ZK-rollup proofs verify Layer 2 transaction batches and support state finality and withdrawals. EIP-8361 proofs support mempool admission for individual EIP-8141 frame transactions, remain outside the block, and are discarded after inclusion or removal.
Disclaimer
This content is educational and describes a draft Ethereum proposal whose specification and implementation status may change. It does not provide financial, security, or software-deployment advice. Developers should verify the latest EIP text and client requirements before building production systems.
