Receipt Verifier — IronBridge

Re-walk the live LAW-25 window

A receipt is a small record of one paid agent call — what was asked, what was paid, what came back. Paste one below and your own browser re-does the math; you run the check, not us. No login, no key.

Paste a receipt reference.

Your browser re-computes the linkage in the rows returned by the public endpoint, link by link.

The page says plainly which part is proven and which part you still take on trust.

Read this first — honest status This is a demo to show how receipt verification works. We only show what we can prove.

Two public chains: this page walks /api/law25/verify (LAW-25 hash-chain; leaves withheld; HMAC authorship). The public seal chain is /api/chain/page (much shorter tip, disclosed genesis break). They are not the same ledger. /receipt currently describes the seal/EAS story; this page is LAW-25.
Historical v1 damage: GET /api/law25/verify?row=1 returns leaf_integrity: false (row dated 2026-05-13). A clean recent-window re-walk does not prove the full history is intact. Do not treat raw row count as a cleanliness proof.
What you prove vs what you trust: the returned linkage window is re-walkable in your browser (each row's chainlink_prev must equal the prior row's chainlink_row — pure SHA-256, no trust). The row leaf contents are withheld, so leaf integrity and authorship are operator-attested (server recompute + per-row HMAC seal). We do not claim the rows are stranger-reproducible from scratch.
No verified outside sales are reported. Sample receipts here are lab/self-test data.
The audit chain is tamper-evident; nightly on-chain anchoring is active and must be verified date by date: any edit breaks a link, and on successful nights the chain’s head SHA is committed to a Base L2 contract (0xa938754d9a9b6ec2f4533ddbc0fdade7fc2eb80b) — read a given night’s committed head by calling getAnchor(unixDay) on that contract (unixDay = floor(unix seconds / 86400)); a non-zero return is the anchored head SHA for that day, so altering sealed history would mismatch the public on-chain anchor. Earlier days (before the cron went live) are not back-anchored, and rows added since the last nightly anchor aren’t anchored yet.
Only the returned-window LINKAGE check runs fully in your browser; the public endpoint currently caps a response window at 100 rows, so this page does not claim full-history replay. UNDER-CAP and DID-WHAT-CLAIMED need the gate attestation + per-row pre-image, which aren't publicly exposed yet — they're marked demo, not claimed as proven.
Partner data shown by lattice apps belongs to those partners, not IronBridge.

Step 1 · the receipt

Paste a receipt hash or an agent action

A receipt is one row in the public chain. It references the row's chainlink_row hash. Paste a chainlink_row from the live chain, or just use a sample — either way we re-walk the live chain and locate it.

Receipt input

Receipt reference (chainlink_row hash) — or any agent action text

No account, no key, no wallet. The re-walk is read-only and runs entirely in your browser via crypto.subtle. The spot-check asks the live endpoint to recompute one row's leaf — that part is operator-attested, and we say so.

real · client-side

○

LINKAGE RE-WALKABLE

Not run yet.

demo

○

UNDER-CAP

Not run yet.

demo

○

DID-WHAT-CLAIMED

Not run yet.

live — press “Verify this receipt” to fetch and re-walk the real chain

# This terminal shows real responses from ironbridge.foundation/api/law25/verify
# The returned-window linkage check runs locally with your browser's crypto.subtle; row preimages and authorship remain operator-attested.

Check a hash yourself

Your text

Fingerprint (digest)

idle

No signup. No API key. Prefill is a public example — it should PASS. Change one character in Your text → FAIL. This is not the unique proof; the two public books are.

What each check means

Real vs demo — stated plainly

LINKAGE RE-WALKABLE

REAL — runs in your browser. Every receipt is a row in a SHA-256 hash-chain. Your browser fetches the live window and confirms each row's chainlink_prev equals the previous row's chainlink_row, and that the server's reported head matches the row we walked to. A clean re-walk proves only that the fetched window is internally continuous; it does not prove the endpoint returned every historical row. What this does NOT prove on its own: that any payment cleared (that is an assertion in the row — check the txHash on Base yourself), and that the withheld leaf contents are authentic (see below).

LEAF + AUTHORSHIP

OPERATOR-ATTESTED. Each row's hash is computed over a canonical leaf whose contents are withheld to protect internal operations, and each row carries a keyed HMAC authorship seal held server-side. You can ask the endpoint to spot-recompute one row's leaf integrity (?row=N) — but that recompute happens on our server, so it is attested by us, not reproduced by you. We label it operator-attested and never call it stranger-reproducible.

UNDER-CAP

DEMO. The off-LLM capability gate decides per-action whether a money move is below the trusted per-move / daily cap (caps come from a trusted registry, never the request). That gate attestation is not yet exposed on the public endpoint, so we cannot prove it client-side today. Shown for shape only.

DID-WHAT-CLAIMED

DEMO. Proving the served result matches the claimed action needs each row's hash pre-image (the full action payload), which the public surface intentionally does not expose yet. We show the linkage we can prove and mark the rest honestly as coming.