igneum-labs 7e78bb366b Reference apps: the payment receipt. The transaction's execution outcome is authenticated through the proven segment's receipts commitment: the segment record (BLS by its aggregator, carried under the certificate) commits keccak over the shard receipts roots, the shard's receipts rebuild its ordered trie root in the browser and offline, and the transaction's receipt sits in it (status, logs). Issued for a transaction executed at a paid segment's last block; otherwise the inclusion receipt, with the reason. Eight payment negative cases pass beside the nine inclusion ones; the page and the one-file verifier name which receipt they issue ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>		2026-10-08 15:06:21 +00:00
..
fixtures	Reference apps: the payment receipt. The transaction's execution outcome is authenticated through the proven segment's receipts commitment: the segment record (BLS by its aggregator, carried under the certificate) commits keccak over the shard receipts roots, the shard's receipts rebuild its ordered trie root in the browser and offline, and the transaction's receipt sits in it (status, logs). Issued for a transaction executed at a paid segment's last block; otherwise the inclusion receipt, with the reason. Eight payment negative cases pass beside the nine inclusion ones; the page and the one-file verifier name which receipt they issue	2026-10-08 15:06:21 +00:00
light-service	Reference apps: the payment receipt. The transaction's execution outcome is authenticated through the proven segment's receipts commitment: the segment record (BLS by its aggregator, carried under the certificate) commits keccak over the shard receipts roots, the shard's receipts rebuild its ordered trie root in the browser and offline, and the transaction's receipt sits in it (status, logs). Issued for a transaction executed at a paid segment's last block; otherwise the inclusion receipt, with the reason. Eight payment negative cases pass beside the nine inclusion ones; the page and the one-file verifier name which receipt they issue	2026-10-08 15:06:21 +00:00
oracle	Reference apps, the review's four orders: /receipt is a transaction inclusion receipt in title, copy, file and the offline verifier's output (a payment receipt authenticates the outcome and is named as the next step); /light states its trusted inputs in one block and reads as a verification path with stated trust assumptions; /oracle discloses the deployer-installed voter table and the unchecked aggregator signature on the page and in trust() (oracle redeployed on the shared verifier, 0x3ad71d46, chain id accepted before and after the class v5 floor); the four words included, executed, proven, finalised defined once in site/partials/terms.html and injected on the three pages	2026-10-08 14:48:23 +00:00
receipt	Reference apps: the payment receipt. The transaction's execution outcome is authenticated through the proven segment's receipts commitment: the segment record (BLS by its aggregator, carried under the certificate) commits keccak over the shard receipts roots, the shard's receipts rebuild its ordered trie root in the browser and offline, and the transaction's receipt sits in it (status, logs). Issued for a transaction executed at a paid segment's last block; otherwise the inclusion receipt, with the reason. Eight payment negative cases pass beside the nine inclusion ones; the page and the one-file verifier name which receipt they issue	2026-10-08 15:06:21 +00:00