What Is EIP-8361? Ethereum Validity Proofs Explained

EIP-8361 focuses specifically on proof-carrying admission for EIP-8141 frame transactions. It does not replace Ethereum execution, introduce a new transaction type, deploy a smart contract, provide transaction privacy, alter validator rewards, or define an 18-month implementation period. Its practical purpose is narrower: reducing redundant computation during transaction validation while retaining safeguards against invalid or resource-intensive transactions.

The sections below explain how the proof-carrying process works, what nodes verify, how EIP-8361 differs from rollup validity proofs and transaction simulation, and which technical limitations remain unresolved.

Key Takeaways

• EIP-8361 standardizes transaction validity proof data for peer-to-peer propagation. A frame transaction may carry a STARK showing that its validation prefix reaches an approved state.

• Nodes verify the proof instead of replaying costly authorization logic. This separation of proving and verification may reduce repeated computation across Ethereum nodes.

• The proof remains outside consensus. It is transported with the transaction, used for mempool admission, and discarded when no longer needed.

• The design supports complex smart-account validation. Examples include multisignature rules, alternative signature systems, paymasters, and proof-heavy authorization.

• EIP-8361 remains a draft. It is not an activated upgrade and should not be confused with EIP-7701, EIP-7702, rollup validity proofs, or staking-reward proposals.

What Is EIP-8361?

EIP-8361, titled Transaction Validity Proofs, proposes a networking mechanism through which an Ethereum transaction can arrive with cryptographic evidence that its validation logic approves it. The draft acts as a networking counterpart to protocol-level changes proposed by EIP-8141, which defines frame transactions and programmable validation stages.

An Ethereum Improvement Proposal is a technical design document describing a potential standard, protocol feature, interface, or process for Ethereum. Publication as an EIP does not automatically mean that a proposal has been accepted or deployed. EIP-8361 remains a working draft whose specification, dependencies, and status may change.

The proposal addresses a specific question:

How can a node safely admit a transaction whose authorization is expensive to execute without requiring every peer to repeat that expensive computation?

Under EIP-8361, a prover runs the relevant transaction-validation logic off-chain and generates a STARK. A receiving node verifies that proof, checks its declared assumptions against current Ethereum state, and decides whether to place the transaction in its public mempool.

The transaction itself must still be valid under Ethereum’s execution rules when it is eventually included in a block. The proof supports admission policy; it does not replace protocol-level execution or consensus validation.

Why Complex Ethereum Transaction Validation Is Difficult

A conventional externally owned account, or EOA, is controlled through a private key and corresponding public key. The account authorizes a transaction with an ECDSA signature, while the transaction specifies fields such as the sender nonce, destination address, value, chain ID, gas limit, and gas price or EIP-1559 fee parameters.

These checks are relatively predictable. A node can verify the signature, confirm that the account holds enough funds to cover the value and maximum gas cost, check the nonce, and reject malformed or replayed transactions.

Smart accounts create a broader validation surface. Instead of relying only on one private key, a smart account may use:

• multiple public keys;

• spending limits;

• session keys;

• delegated contracts;

• paymaster rules;

• post-quantum signatures;

• recovery conditions;

• zero-knowledge proofs;

• application-specific authorization code.

Such logic may reside in an already deployed smart contract or in a new contract created during account deployment. Contract creation and contract deployment may also require validation of a factory, initialization code, or the address at which the new contract will exist.

Ethereum nodes cannot safely execute unlimited validation code for every unconfirmed transaction they receive. An attacker could submit fraudulent transactions that invoke expensive smart contracts, hash functions, storage reads, or proof systems but never authorize execution. Even though the transactions are invalid, verifying them would consume node resources.

EIP-8361 transaction validity proofs therefore shift the expensive work to a prover while keeping proof verification bounded.

How EIP-8361 Proof-Carrying Transactions Work

EIP-8361 proposes two paths for admitting an EIP-8141 frame transaction:

1. Simulated admission: the node executes the validation prefix directly.

2. Proof-carrying admission: the node verifies a STARK proving that the validation prefix approves.

The second path is intended for cases in which a normal call to the validation code would exceed the node’s permitted verification budget.

1. A Transaction Defines Its Validation Logic

An EIP-8141 frame transaction can divide its work into frames with different purposes. Some frames establish authorization, identify the payer, or prepare execution. A validation prefix runs before the transaction’s normal execution frames.

The validation prefix may call a smart contract associated with the sender or another delegated contract. That contract can check signatures, permissions, balances, expiry conditions, or other rules before invoking the proposed APPROVE operation.

EIP-8141 differs from a conventional transaction in which one protocol-recognized ECDSA signature directly determines the sender. Its programmable validation model is part of Ethereum’s broader movement toward native account abstraction. EIP-8141 also deliberately avoids relying on EIP-7702’s ECDSA-based authorization list because frame transactions target greater cryptographic flexibility.

2. A Prover Executes the Validation Prefix

The prover runs the transaction’s validation prefix against a declared set of inputs and state assumptions. This process may include verifying that:

• a signature matches the appropriate public key;

• a sender account has sufficient funds;

• a paymaster balance remains above a required value;

• a contract storage slot contains an expected permission;

• the chain ID matches the intended Ethereum network;

• a nonce prevents replay attacks;

• the validation code terminates with approval.

The prover then creates a STARK that commits to the relevant transaction, dependencies, assumptions, payer, and validity conditions.

3. The Proof Declares State Assumptions

A cryptographic proof cannot remain useful if it silently depends on state that has since changed. EIP-8361 therefore proposes an assumption vector describing the state facts used during proving.

An equality condition may state that a contract’s code hash, nonce, or storage value must exactly match a declared value. A greater-than-or-equal condition may state that an account balance must remain above a minimum.

These assumptions connect the proof to a previous valid state without requiring the proof to embed Ethereum’s complete state. When a new block changes relevant data, the node can recheck the assumption vector.

This mechanism is central to EIP-8361 mempool validation: the node does not blindly trust old proof merely because its cryptography remains valid.

4. Nodes Verify the STARK

A receiving node performs low-cost structural checks before spending resources on proof verification. It then verifies the STARK with the specified verification key and checks the declared dependencies and assumptions against its current view of Ethereum state.

Modern proof systems can produce proofs that are faster to verify than re-executing the original computation. A single proof can therefore replace repeated simulation by many peers, reducing redundant computation across the peer-to-peer network.

This does not mean that proof generation is cheap. Producing a STARK may require considerable processing, memory, and specialized software. The proposal moves computation rather than eliminating it.

5. The Transaction Enters the Mempool

When the proof and state checks succeed, the node may admit and propagate the transaction without rerunning the expensive validation prefix.

The proof remains peer-to-peer metadata. It is not added to transaction calldata, stored by a deployed smart contract, written into the account state, or included in the block’s Merkle root.

Once the transaction is included, Ethereum executes it under the applicable protocol rules. If the proof becomes stale or the transaction is removed, the networking metadata can be discarded.

What Does an EIP-8361 Validity Proof Prove?

An EIP-8361 validity proof is cryptographic evidence that a specific validation computation was executed correctly under declared assumptions and reached the required approval state.

It may demonstrate that the validation logic checked a valid signature, sufficient balances, correct nonce, permitted payer, or contract-defined authorization. However, it does not necessarily prove the correctness of every later EVM state transition produced by the transaction.

The distinction is important:

• EIP-8361 proves admission-related validation.

• A rollup validity proof proves one or more off-chain state transitions.

• A Merkle proof proves inclusion in an authenticated data structure.

• A zero-knowledge proof may hide information, but validity alone does not guarantee privacy.

A Merkle proof can show that a transaction belongs to a particular transaction batch, block, or state tree by connecting a leaf to a known Merkle root. In ZK rollups, Merkle proofs may establish that sender and receiver accounts existed in the previous valid state and that updated balances produce the new state root.

EIP-8361 uses a STARK as an efficient correctness proof, but the draft’s objective is not confidential execution. The transaction and its dependencies may remain visible to participating nodes.

EIP-8361 vs ZK-Rollup Validity Proofs

Layer 2 scaling solutions use validity proofs in a broader way. A ZK rollup executes a batch of transactions off-chain and submits a succinct proof to an Ethereum verifier contract. That proof demonstrates that the batch transformed the previous valid state into a correct new state according to the rollup’s rules.

Instead of re-executing every transaction on Ethereum, the verifier contract checks the proof and public inputs. This can reduce on-chain resource consumption and distribute fixed gas fees across many transactions. Recursive proof systems may also aggregate multiple proofs into a single proof.

Validity proofs help prevent a ZK rollup from finalizing an invalid state transition, assuming that its proof system, circuit, verifier contract, and data-availability model are secure. They also permit faster L2-to-L1 finality than systems that require a dispute window.

EIP-8361 does something different. It does not prove an entire computation batch, update an L2 Merkle root, or trigger a withdrawal. It proves that one frame transaction meets a node’s proposed admission requirements.

EIP-8361 Validity Proofs vs Fraud Proofs

Optimistic rollups generally assume submitted state updates are valid unless challenged. Fraud proofs require observers to detect a disputed transition and provide evidence during a challenge period. An invalid claim may therefore remain provisionally accepted until the challenge process resolves it.

Validity-proof systems take the opposite approach: a new state commitment is accepted only after the verifier confirms cryptographic evidence of correct execution. This commonly enables faster withdrawals because users do not need to wait through a fraud-proof challenge period.

However, saying that validity proofs are universally “more secure” than fraud proofs is too broad. The key differences include prover complexity, verifier security, data availability, trusted setups where applicable, challenge assumptions, and implementation maturity.

EIP-8361 is not itself a rollup security model. Its proof is checked before mempool admission, while rollup fraud proofs and validity proofs protect off-chain scaling systems.

EIP-8361 vs EIP-7702 Account Delegation

EIP-7702 allows existing EOAs to set a delegation indicator in their code field so calls to the account execute code from a designated smart contract. It introduced a type-4 transaction containing an authorization_list.

Each authorization tuple includes:

• chain_id;

• delegated contract address;

• account nonce;

• signature fields.

The authorization is signed by the EOA’s private key. The signer can differ from tx.origin, and one transaction can carry authorizations from multiple EOAs. Each authorization can update the corresponding account’s delegation indicator before normal transaction execution.

This means users can delegate execution capabilities to smart contracts with signed authorizations without permanently converting the account into a conventional deployed smart contract. The delegated code can support batching, gas sponsorship, permissions, or other smart-account behavior.

EIP-7702 also creates security considerations. A chain ID of zero may make an authorization valid across chains, while nonces and signed fields help limit replay attacks. Delegated code can affect assumptions involving tx.origin, pending transactions, storage, and account balances.

EIP-8361 neither replaces nor extends the authorization_list. It addresses how nodes could admit transactions containing complex validation logic. The key differences between EIP-8361 validity proofs and transaction simulation concern mempool computation, not EOA code delegation.

EIP-8361 vs EIP-7701 Native Account Abstraction

EIP-7701 was created on May 1, 2024, as a proposal for native account abstraction. It split transaction processing into validation, execution, and post-operation stages and proposed a new EIP-2718 transaction type.

Its design used the protocol-native entry-point address 0x7701, role-based opcodes, separate sender and paymaster validation, and contract-controlled gas payment. The proposal did not require the separate ERC-4337 bundler flow for its native transaction type.

EIP-7701 has since been withdrawn because it was superseded by EIP-8141—not merely marked “Stagnant.” Its published specification lists the withdrawal reason directly. The claim that EIP-7701 currently requires EOF-formatted contracts is also not part of its final published specification.

EIP-8361 builds around EIP-8141’s newer frame-transaction model. In that sense, it supports a possible protocol-level account-abstraction path by making expensive programmable validation easier to propagate safely.

EIP-2718 provides the typed transaction envelope used by proposals such as EIP-7701, EIP-7702, and EIP-8141. It defines a transaction as TransactionType || TransactionPayload, with the transaction type identifying how the opaque payload should be interpreted. Including the type in signed data also reduces cross-type signature-replay risk.

Practical Impact on Wallets, Nodes, and Developers

Wallet developers could use proof-carrying admission when a smart account’s authorization is too expensive for ordinary mempool simulation. A wallet might request a proof from a local prover, wallet service, or distributed proving network before submitting the transaction.

Node developers would need to implement:

• proof transport across peer-to-peer connections;

• versioned verification keys;

• proof-size limits;

• assumption and dependency checks;

• per-peer rate limits;

• stale-proof eviction;

• fallback simulation behavior.

Smart-contract developers could retain application-specific validation without requiring all nodes to execute its full cost. This may support post-quantum signatures, multiple-key policies, complex paymasters, or proof-based permissions.

The wallet, node, and developer impact of EIP-8361 will ultimately depend on proving latency, client adoption, interoperability, and the final EIP-8141 specification.

For example, a trader assessing market reaction on exchange like Gate to a future Ethereum upgrade can compare network announcements with the ETH/USDT market chart. Market price, trading volume, or gas fees cannot establish whether a draft EIP has been technically accepted or activated.

Security Considerations and Limitations

EIP-8361 introduces several security considerations.

First, proof soundness depends on the correctness of the STARK circuit and verification key. A circuit bug could prove a statement that does not faithfully represent the intended validation rules.

Second, proof verification still consumes computation and bandwidth. Attackers may send malformed or oversized proofs, making low-cost preliminary checks, size limits, and peer attribution necessary.

Third, assumptions can become stale. A valid proof generated against one account balance, storage value, contract code hash, or nonce may no longer apply after a new block changes that state.

Fourth, inconsistent node policies could fragment transaction propagation. Different clients may choose different proof-size caps, validation limits, or admission defaults.

Fifth, proof generation can create centralization pressure if only a small number of services possess sufficient hardware or optimized software.

EIP-8361 also does not remove ordinary transaction costs. If a transaction reaches block execution, its sender or payer remains responsible for the applicable gas cost. A validity proof may reduce redundant off-chain node computation, but it does not eliminate Ethereum gas fees.

What EIP-8361 Does Not Propose

Several supplied claims belong to unrelated proposals and should not be attributed to EIP-8361.

EIP-8361 does not:

• specify an 18-month transition period;

• remove a staking yield floor;

• cap validator rewards;

• deduct rewards as staking approaches 50%;

• create a market-driven staking equilibrium;

• introduce EIP-7702’s authorization list;

• introduce EIP-7701’s native entry point;

• create a new EIP-2718 transaction type;

• guarantee privacy;

• settle ZK-rollup batches;

• replace fraud proofs;

• waive users’ contractual or related rights.

The draft’s copyright section may state that copyright and related rights are waived under CC0, as is common for EIPs. That legal notice concerns the proposal document itself, not user funds, transaction rights, or smart-contract permissions.

Conclusion

EIP-8361 proposes proof-carrying transaction admission for Ethereum’s public mempool. A prover would execute a complex EIP-8141 validation prefix once, generate a STARK, and allow multiple nodes to verify the result without reproducing the same expensive computation.

Its strongest use case is programmable authorization that exceeds ordinary mempool validation limits, including advanced smart accounts, alternative signature systems, paymasters, and proof-heavy contracts. The design may reduce redundant node computation while keeping current-state assumptions visible and recheckable.

EIP-8361 should not be confused with ZK-rollup settlement, fraud-proof challenges, EIP-7702 account delegation, or the withdrawn EIP-7701 design. It remains a draft networking proposal whose security, proving economics, interoperability, and dependencies require further development before any potential Ethereum deployment.

FAQs

Does EIP-8361 create a new transaction type?

No. It applies proof-carrying admission to EIP-8141 frame transactions. EIP-2718 provides the general typed-transaction framework, but EIP-8361 does not introduce another transaction envelope.

Are EIP-8361 proofs zero-knowledge proofs?

The draft proposes STARK-based validity proofs, but validity does not necessarily mean privacy. The proof establishes correct validation under declared assumptions rather than hiding all transaction data.

Can a single proof cover multiple transactions?

Proof systems can aggregate computations or use recursive proofs, and rollups may compress multiple transaction proofs into one proof. The current EIP-8361 design focuses on the admission of a particular frame transaction rather than standardizing arbitrary transaction-batch aggregation.

Does EIP-8361 reduce gas fees?

Not directly. The proposal may reduce repeated off-chain computation by nodes, but an included transaction still pays the gas required by Ethereum execution.

How is EIP-8361 different from EIP-7702?

EIP-7702 lets EOAs delegate code execution through signed authorization tuples. EIP-8361 proposes a proof-based way for nodes to admit transactions with expensive programmable validation.

Disclaimer

This content is educational and describes draft technical proposals rather than guaranteed Ethereum upgrades. Specifications, implementation plans, security assumptions, and network support may change. Protocol developments and historical market data do not predict future ETH performance.