igneum/tools/reference-apps
2026-10-08 15:49:34 +00:00
..
compat Igneum 2.0, compatibility as a product deliverable: /compatibility (docs/build/compatibility.md rendered by the builder programme's shell, its rows from tools/reference-apps/compat/results.json), the runner tools/reference-apps/compat/run.mjs with every row as a test against the devnet (representative contracts, wallet fee estimation, indexing, failed transactions, receipts, application assumptions, the measured differences: block context, randomness, two-dimensional fees), every row served untested until the 2.0 devnet answers; the positioning line and the three boundaries on /light, /receipt and /oracle; the Build group's nav entry 2026-10-08 15:49:34 +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