threshold issuer

✔ PROVEN by executionproven

A signature/identity flaw: a proof or signature that should be unique or bound to a context can be replayed, forged, or malleated — authorising actions it never should.

The execution result

Exploit ran on a forked chain — proven by execution

✔ Clean control resisted — the same test passes on the patched version. Across the whole gym suite: 140 / 140 planted bugs caught, 0 false proofs.

What this class of bug is

A signature/identity flaw: a proof or signature that should be unique or bound to a context can be replayed, forged, or malleated — authorising actions it never should. This is the class behind real on-chain losses in this category.

The receipt

The verifiable artifact — the verdict, the class, the clean-control result, and the attribution — as a signed record. The exploit method itself is withheld (defensive); what you verify is that the proof is genuine and untampered.

↓ Download the receipt (JSON)

Verify this yourself

You don't have to trust us. Every receipt is a leaf in an append-only, hash-chained, Merkle-rooted log. Verify the chain and recompute the root — it must match what we publish on /stats:

curl -s https://omniguardlabs.com/proofs/verify_root.py -o verify_root.py
curl -s https://omniguardlabs.com/proofs/proof_log.jsonl | python3 verify_root.py -

Scope of claim. We execution-prove the class/mechanism — the exploit reproduced on a fork and the patched control resisted. A dollar figure appears only where we re-executed that specific historical incident ourselves; it is that incident's publicly reported loss, and it links to the re-proof. Classes with no figure caused real losses we have not re-run, so we do not put a number on them. No proof, no finding.

Get your own contract proven — not guessed

Static tools and LLM auditors ask “is there a check here?” and miss the check that exists but is wrong. We run the exploit on a fork and send you a signed pass/fail receipt. Request a proof-backed audit →