The Gauntlet

Try to make it lie.

A real computation runs in your browser, gets committed, and is cryptographically signed. Then you become the attacker. Tamper with the result, the signature, the program, or the proof itself. An independent verifier re-runs everything from scratch and catches every lie. Download the proof and it re-checks offline, on any device, with no server and no trust in us.

This is the first of five layers, and each is a different kind of proof you can attack: a signed computation, a succinct proof that never re-runs the work, a provenance receipt, the compiler's own certificate, and an autonomous agent's decision ledger. Every verifier below is open code, runnable by a person or a machine, and each one is yours to try to break.

What this proves: the signed result really is what this program computes from these inputs, in exact integer arithmetic that is identical on every machine, and any tampering is detected. What it does not prove: who signed it. The signing key is generated in your browser for this demo; in production the signer is the lab's registered key. Nothing here is a lending or financial decision.

attacks defeated: 0
in

1. Input

You control the inputs. This is the honest, visitor-supplied source.

ready
62
38
71
fx

2. Compute (exact integers)

A deterministic integer engine. No floats, so the result is bit-identical on any CPU, GPU, or phone.

idle
#

3. Commit

SHA-256 binds the program, the inputs, and the result into one hash. Change any of them and this hash changes.

idle
key

4. Sign (Ed25519 / P-256)

The machine that computed it signs the commit. The private key never leaves this run and is not in the receipt.

idle

5. Portable proof

A self-contained receipt: program, inputs, result, commit, public key, signature. Anyone can re-check it, offline.

idle

Layer 2

Verify a result you never watched compute.

The proof above hands you the entire program to re-run. This one does not run the computation for you at all. A prover executed a chain of squarings and produced a short cryptographic proof, a STARK, that the public output is genuinely correct. Your browser checks that proof from scratch: it recomputes every Fiat-Shamir challenge, tests an out-of-domain algebraic identity, and runs a real low-degree (FRI) test, all in a few milliseconds, without re-executing the chain and without the prover ever transmitting its execution trace. Then serve it a real forged proof and watch the low-degree test reject it.

forgeries rejected: 0
zk

Witness-free STARK verifier

A trace-hiding squaring STARK over the BabyBear field. The verifier trusts nothing in the proof but the committed roots; it re-derives every challenge and selector itself. This is a byte-identical browser port of the reference zk_stark checker.

idle

What this proves: the public output really is correct and the proof is internally sound, checked without re-running the computation, and no forged proof passes. What it does not prove: this is not a secrecy claim. It is a sound, trace-hiding STARK under active development, not a proven zero-knowledge system (there is no simulator), and in this public-seed fixture the input is not secret. We call it “verified without re-execution,” never “zero-knowledge.”

Layer 3

A signature is not a certificate.

This is a real provenance receipt for a Coherence Language computation, a Laplacian smoothing kernel that ran on a specific input and produced a specific output. Your browser checks three independent things: that the claim was not altered, that the signature is valid, and, kept deliberately separate, whether the signer's key is one we actually pinned. A mathematically perfect signature from a key we do not recognise is shown honestly as UNTRUSTED, never green. Then forge a receipt with your own freshly minted key: the math checks out, and it is still untrusted.

forgeries rejected: 0
sig

Obsign provenance receipt

A signed, content-bound receipt (Obsign, a C2PA-style provenance scheme). The verifier is a byte-identical port of the reference checker, with canonical JSON that matches the Python signer exactly.

integrityidle signatureidle signeridle

What this proves: the receipt's claim is unaltered, the signature is valid, and the signer either is or is not a key we pinned, reported as three separate facts. What it does not prove: the trusted key here is a demo signing key we pin for this page; real provenance uses the lab's registered key on a published trust list. A valid signature only proves the holder of some key signed it, which is exactly why the key must be pinned.

Layer 4

The compiler certified itself, bugs and all.

Coherence Language compiles through many backends: a bytecode VM, native code, WebAssembly, a GPU path, and more. This is a signed certificate of how each one compares, bit for bit, against the reference interpreter across a corpus of 120 differential programs. Most agree perfectly, and it is honest to a fault about the one that did not: WebAssembly miscompiled a single program, so it is recorded as unsound and left out of the trusted set. Verify the Ed25519 signature, then try to quietly upgrade the broken backend, or inflate the corpus, and watch the signature break.

forgeries rejected: 0
cc

Proof-carrying build certificate

Signed over a canonical digest of the entire verdict. Your browser recomputes that digest and checks the signature against a pinned key. This is a byte-identical port of the reference verifier.

signatureidle issueridle corpusidle

What this proves: the certificate was signed by the pinned key, and every field, each backend's soundness and the exact corpus it covers, is bound by that signature, so it cannot be edited without detection. What it does not prove: the browser is not re-running the compiler here; it is re-verifying a signed attestation. Re-running the full cross-backend differential is the referenced, offline procedure that produced this certificate.

Layer 5

Put the autonomy on trial.

An autonomous detector watched a system and made a sequence of security calls. Each one was written into an append-only ledger, hash-chained to the last, and signed with ECDSA P-256. Nothing here rests on anyone's word: your browser re-derives every digest, checks every signature against a pinned key, and walks the chain link by link. Then downgrade a critical alert, or quietly delete an entry from the ledger, and watch the proof catch it. In production the detector signs with a hardware TPM of the same scheme; this public ledger uses a software key and carries no data from a real machine.

forgeries rejected: 0
gh

Hash-chained, signed decision ledger

Each entry binds the whole finding plus a link to the entry before it, signed with ECDSA P-256. A byte-identical port of the reference verifier; every signature is checked against a pinned key, never the key the entry carries.

chainidle signaturesidle signeridle

What this proves: every decision in the ledger is bound to its evidence and to the entry before it, and signed by the pinned key, so a single alert cannot be relabeled and no entry can be removed without breaking the chain. What it does not prove: the browser verifies a signed, chained ledger; it does not re-run the detector. This public ledger is synthetic and software-signed; the production detector signs with a non-exportable hardware TPM, and catching a full local rollback (truncating the ledger and replaying an old signed high-water marker) needs an external monotonic anchor, which the engine supports and which is beyond this in-browser check.

Everything above runs locally with the Web Crypto API and exact integer arithmetic; there is no server call and no external script. The integer engine and the verifier are the same code you can read in this page's source. Program: -. These are five layers of one idea, trust nothing and verify everything: computation, succinct proof, provenance, compilation, and autonomy, each attackable and each independently verifiable. Back to demos