A standing public dare
A simulation output is a claim. So prove you can’t quietly change ours.
We published a signed reactor calculation. Change the number and convince our verifier it is still ours. We don’t think you can, because the seal is cryptographic, not a claim we ask you to trust. The verifier is open and dependency-free, our key is cross-checkable out of band, and you can try it in your browser in a minute.
Not “trust us.” Break us.
verifier open · offline · zero dependencies signature from-scratch RFC 8032 Ed25519 key cross-checked from two channels attempts credited
An OpenMC criticality result on a homogeneous SMR slab (advisory, lab-escalation). The dare is about custody, not whether 1.00522 is a validated absolute. See what this proves below.
The challenge
One file to read, one record to attack, one key to cross-check. Everything runs on your machine, with nothing of ours imported.
A single standard-library-only file you can read in full.
$ curl -O https://gitlab.com/smrforge/evidence-verifier/-/raw/v0.3.8/evidence_verify.pyThe exact bundle shown above, frozen at cise-v3.
The fingerprint the verifier prints must match
smrforge.io/.well-known/smrforge-trust-root and the DNS
TXT record smrforge-trust-root.smrforge.io. Two channels, neither of them the
verifier itself.
It passes. Move one digit of k_eff and run again. It fails and names
the broken section, while the signature line still checks. Your challenge is to make an edited copy it
still reports as signed by our key.
The same record, twice · illustrative
Illustrative. The two panels show the shape of the verifier’s answer, not a captured transcript. Step 4 prints the real one on your machine. The behavior itself is real. The verifier names the section that broke, and a signature made over the original digest stays a valid signature of that digest whatever you do to the number beneath it.
record cise-v3 · commit 453b6a8 seal bundle_sha256 40a35716… verifier protected tag v0.3.8
The record’s integrity rests on its signature, not the URL, so bytes served under any other name
simply fail to verify. cise-v3 supersedes cise-v2. It is
the v0.14.0 re-mint of the same benchmark (same k_eff, 1.00522) that now also seals
the execution runtime, provenance.toolchain.machine and the OpenMC solver build,
under ADR-040. It is a fresh seal (new bundle_sha256, new signature over it);
both verify under the production key.
Prefer zero install? The same verifier runs live on the Check a bundle page, on this exact record, as a from-scratch RFC 8032 Ed25519 implementation with no crypto library behind it. Change a digit and watch the seal catch it, no download required.
The rules
The verifier’s own printed verdict is the judge. Move the value, keep the pass, under our pinned key. Everything else is a shortcut we already closed.
Using the unmodified public verifier, pinned to our production key (fingerprint cross-checked from the two channels above), produce a record whose k_eff is a genuinely different value from 1.00522 and that the verifier still reports as a pass signed by the pinned key.
1.0052200 is the same value as 1.00522; the verifier re-derives the number before hashing, so a reformat is not a changed result. A break has to move the value.
Run it unchanged; you can read every line. The key is pinned and cross-checkable from two channels precisely so a swapped verifier cannot help.
The verifier fails any record that is unsigned or signed by any key other than our pinned production key. That is not a pass under our key.
If you can do that, you have earned a far larger prize and should tell the world, not us.
A record whose asserted result genuinely differs yet still passes. If you find one, report it responsibly and it gets fixed in a release that names you.
Rewards
Every reproducing attempt is credited. A real flaw is fixed with your name on the release. A forged signature is a bigger story than this page.
Every confirmed break earns public credit, your name on the record as the person who tested it, on this page.
A confirmed, previously-unknown verifier or format vulnerability, reported privately first, is fixed in a release that names you and credited here. SMRFORGE may also offer a monetary reward for such a finding; write to support@smrforge.io before disclosing publicly.
If you produce a record our pinned key verifies with the number changed, that is a result of cryptographic significance.
Submit
Submissions are by email. If you think you found a genuine verifier or format flaw, not a reformatting of the same number, email that first too, so we can fix it before it is public.
Send your altered record and the exact command and output of the unmodified verifier reporting a pass to support@smrforge.io. Confirmed results are credited by name here.
Send your break →Trusting the key
A pass proves the record is unaltered and signed by this key. That the key is SMRFORGE’s rests on one fingerprint, published where we cannot quietly change it.
fingerprint ed25519:cfb88804…d69b52c
smrforge-trust-root.smrforge.io
The commit history of the open-source site on GitHub, where every change to that file is a timestamped, third-party-hosted commit you can audit.
Cross-check the fingerprint against all three, and don’t rely on a single server’s word, ours included.
Honest boundary
This challenge is about custody, whether a computed number can be quietly changed or forged on its way to a reviewer. It cannot. Whether the number is right is a different question.
Verification (the seal holds, the number re-derives) is not validation (the number matches a measured experiment). SMRFORGE results are screening-to-reference grade and advisory, labeled on every result. Nuclear data cited on this site is openly distributable (ENDF/B-VIII.0 and VIII.1).
