igneum-labs 8cc205abff Site 2.0 wipe: merge the moved master (the 2.0 plan, counter-asic-4, enforced proving, reference apps, pool vote key, tn-land); the reference-app pages take master's note with the positioning line, no devnet number, 24 px blocks; /bench and /journey stay removed; the public ledger regenerated from the 2.0 source; the grants lead names the devnet ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>		2026-10-08 16:11:14 +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	Site reset to Igneum 2.0, second pass: the reference apps and the deploy smoke pins follow the Igneum 2.0 devnet	2026-10-08 15:42:20 +00:00