Reference app 2 · the devnet, no value

A receipt any third party re-verifies.

A GPU-secured network for Ethereum-compatible applications and verifiable computation. Devnet, no value.

Paste a devnet transaction hash. This tab fetches the raw transaction, the including block's merkle path, every header up to the certified checkpoint and the certificate, then proves inclusion and finality itself. Download the receipt as JSON. Anyone checks it later with a one-file verifier, offline, with no node and no network. Test with the negative cases: tools/reference-apps/light-service/verify.test.mjs (eight payment cases, nine inclusion cases).

Which receipt this is

The page issues one of two receipts and names it on the result, in the file (field kind) and in the offline verifier's output: "transaction-inclusion receipt" wherever the execution status is node-reported, "payment receipt" only where the transfer is proven with asset, recipient and amount.
A transaction inclusion receipt authenticates that the signed transaction (recipient, amount and data as signed) is included in a block that is finalised. The execution result (status, gas, logs) is carried as the node reported it and labelled so; a transaction can be included and finalised and still have failed.
A payment receipt also proves the transfer (asset, recipient, amount) and its outcome: the transaction's receipt (status success, its logs) sits in the shard receipts trie whose root the proven segment's statement commits to (receipts = keccak over the shard roots, signed by the aggregator inside the carrier block, under the certificate). Asset, recipient and amount are the signed transaction's; the outcome is the authenticated receipt's. It is issued when the transaction executed at a paid segment's last block, which is where the statement commits that block's receipts; otherwise the page says why it issues the inclusion receipt. Per-shard records would cover every block and are the next step once they are paid again.

Proof boundary. A proof of execution is not a proof of authenticated consensus inputs, canonical history or data availability. Included, executed, proven and finalised are four states; a safe pause is shown as a pause.

Why this only works on a proven chain. Three boundaries hold wherever the proof architecture is explained: proven execution is not finality; EVM compatibility is not Ethereum security; ZK technology does not automatically make transactions private. A merchant's receipt is only worth something if the payment cannot be undone and the proof of that fits in a file: here the certificate is a weighted BLS signature by the miners over a checkpoint, and the block holding the payment hashes into that checkpoint's past. On a chain with probabilistic finality a receipt is a guess that ages well; here it is a fact that a file carries.

Source: site/lc/core.js (the checks), site/lc/app.js (this page), tools/reference-apps/receipt/verify-receipt.src.mjs (the one-file verifier, bundled to /lc/verify-receipt.js). Test with the negative cases: /lc/test in the browser, tools/reference-apps/light-service/verify.test.mjs under Node.

Get a receipt

Until the Igneum 2.0 devnet has its first finality certificate, this page answers: no finality certificate yet; the first lock comes when the weight window fills at DAA 7,200 (the live DAA is shown with the answer). A certificate naming any network other than the release manifest's (/release.json, network.id) is refused before any check runs.

Re-verify offline

The verifier is one file of plain JavaScript with the hashing and curve code inside it: verify-receipt.js. It runs under Node 18 or later (node verify-receipt.js receipt.json) and prints each check, then VERIFIED or REFUSED with the reason. It fetches nothing. Flip one byte of the file and it is refused: node verify-receipt.js receipt.json --tamper runs that case first so you see the refusal before the verdict.

What the receipts prove

The transaction hash is keccak256 of the raw signed transaction in the file, so the recipient, the amount and the data are the signed ones.
The transaction is a leaf of the including block's hash_merkle_root (BLAKE2b-256 keyed MerkleBranchHash up the path).
Every header from the including block to the certified checkpoint recomputes and links to the next by a direct parent.
The certificate over that checkpoint verifies: the aggregate BLS signature of the signers, the voter order, two thirds of active weight and two thirds of total weight.

The payment receipt adds: the record's carrier block up to the checkpoint, the segment record's signature, the shard receipts roots hashing to the statement's commitment, the shard's receipts rebuilding that root with this transaction's receipt at its position. Not proven by either file: the voter table with weights comes from the node (spec 10.1), and the SP1 proof behind the statement is verified by nodes, not here. In the four words below: the inclusion receipt authenticates included and finalised, reports executed and claims nothing about proven; the payment receipt authenticates included, executed, proven and finalised under the trust assumptions stated.

Data availability: how the state is obtained and reconstructed

Every block body (the coinbase and the raw EVM transactions) travels on the p2p network and is kept by full nodes; the execution state is not a separate publication. A node reconstructs the state by executing every chain block from genesis (the read service's reader does exactly that), or starts from an execution snapshot another node exported and replays forward; a snapshot is accepted only when its tip is a block the node holds. The pages here read headers, bodies and state proofs from one node and recompute every commitment; they do not check that every body is held by many nodes, and a block whose body no node serves cannot be re-executed or proven again.

Four words, used exactly

Included

The transaction is in a block's body: its hash is a leaf under the block header's hash_merkle_root. Proves the block carries it, nothing about what it did.

Executed

A node ran it at a chain block and reports a result (status, gas, logs). On these pages an execution result is reported by the node, not authenticated, unless the page says it is.

Proven

An aggregator's segment record, carried in a block's coinbase and signed with its vote key, commits to the state root after that chain block; nodes check the statement against their own execution before paying it. The SP1 proof behind the statement is verified by nodes, not in the browser or on Sepolia.

Finalised

A certified checkpoint has the block in its past: an aggregate BLS signature by voters holding two thirds of active weight and at least 17/30 of total weight over the checkpoint, checked here against the voter table the node supplies.

Recovery lock

Not a fifth state and never shown as finalised. After a full weight window with no lock, the finality rule accepts a checkpoint signed by more than half of the anchored weight (the recovery rule, Review B F04). The node reports each lock's kind beside its checkpoint (lockKind: final or recovery); the certificate bytes carry none, so the kind is the node's report. These pages print a recovery lock as recovery lock, not final on the result, in the receipt file (lock_state) and in the one-file verifier, and refuse a receipt that claims final under a reported recovery lock. On a node before the field nothing is shown. Devnet 3 and the 2.0 devnet, no value.

The same four definitions sit on /light, /receipt and /oracle (one source: site/partials/terms.html). The devnet, no value.

The devnet, no value. The chain may reset. A demonstration of the verification path, not a product.