Coherence Energy Labs

The Gauntlet

Try to make it lie.

A real 500-drone swarm mission flies in your browser under the actual coordination law, and the decided state gets signed. Then you attack it: forge the call, rewrite the law, tamper the signature, or paste a receipt you built yourself. An independent verifier re-flies the entire mission from scratch and catches every lie - offline, on any device, with no trust in us.

attacks defeated: 0

Five layers below, each a different kind of proof you can break: 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 is open code, runnable by a person or a machine.

What this proves: the signed mission state really is what this coordination law produces from this mission order, 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). This is the real decision law, not a flight-dynamics simulator.

in

1. Mission order

You set the mission: fleet size, how many drones are spoofers, and how long they get to form the cordon.

ready
500
30
200
fx

2. Fly the mission (exact integers)

The real swarm coordination law runs the whole mission: every drone computes who-flies-where alone, the fleet forms the cordon, and every spoofer is caught by exact recompute. No floats, so the decided state is bit-identical on any CPU, GPU, or phone.

idle
#

3. Commit

SHA-256 binds the coordination law, the mission order, and the decided state 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 mission certificate

A self-contained receipt: the law, the mission order, the decided state, commit, public key, signature. Anyone can re-fly the mission and 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