Break the seal.
Coriqo seals governance records so they can't be changed afterwards. Download a sealed bundle and the verifier that checks it. Change what the bundle says, get the verifier to pass anyway, and we'll publish it under your name.
The verifier runs on your machine, needs no network, and imports nothing from Coriqo. There's no prize money — none, not a token payment. We're a small company and we'd rather be straight about that than advertise a pot we can't cover. What a break earns you is the write-up, under your name, with the last word on it.
One zip: a sealed record, its checkpoint, and the verifier.
Inside are a signed Merkle checkpoint, the events it seals, an inclusion proof, the Ed25519 public key, and the verifier source. The format specification is in the archive alongside the code, so you can read what each field is supposed to mean before you try to make it mean something else.
Nothing in the archive calls home. There is no Coriqo import, no package to install from us, and no server that has to be up for the check to run. If the verifier only works while we're watching, that's a finding in itself.
Loading the published checksum…
Check it yourself before you unzip anything: shasum -a 256 coriqo-bundle-v1.zip on macOS or Linux, certutil -hashfile coriqo-bundle-v1.zip SHA256 on Windows. If your output and this line disagree, the file you have isn't the file we published.
Three things worth reporting.
The claim under test is narrow, which is what makes it testable: a bundle that passes verification says the same thing it said when it was sealed. Anything that puts a dent in that sentence is worth sending to us.
A forged bundle that passes
You produce a bundle the verifier accepts, where the sealed content differs in meaning from the original. Changing a rejection to an approval counts. Flipping whitespace does not, unless you can show the change alters what a reader would understand the record to say.
An assumption we didn't state
A break that only works if some assumption we never wrote down turns out to be false. If the guarantee quietly depends on a signer's clock, on the order files land in the archive, or on a canonicalisation nobody specified, we want to know before a customer's examiner does.
A defect in the verifier
The verifier reports PASS on input it should reject, or FAIL on a bundle we genuinely sealed. The second direction matters as much as the first: a checker that fails honest records is a checker nobody will trust when it matters.
Your name on the write-up, and the last word on it.
-
We publish it under your name
The write-up goes on this site, credited to you, with your text and our response side by side. If you'd rather stay anonymous, say so and we'll publish it without a name.
-
You keep full publication rights
You can publish first, on your own schedule, whatever we conclude. There's no embargo you have to sign and no veto we hold. If we decide your report isn't a break and you disagree, publish the disagreement.
-
Nothing you have to declare
We pay nothing, to anyone, for anything. That is worth saying plainly, because it is also what makes this enterable: there's no invoice, no tax form, no KYC check, and nobody at a large audit firm has to clear a payment with their conflicts desk before looking at our bundle.
"That's not a real bounty."
Correct, and we shouldn't call it one. A real bounty program pays researchers, has a triage team, and puts a public number on each severity tier. We have none of that. What we have is a specific claim we make in front of bank compliance officers, an offline checker anyone can run, and a promise that if you break it we won't quietly patch it and carry on. If money is what makes work worth your time, this isn't the right project for you, and that's a fair call to make.
Attack the mathematics, not the company.
A break has to be reproducible offline by someone else. Send the forged bundle, the steps, and anything you wrote to build it. If we can't rerun it on a laptop with no network, we can't confirm it.
In scope
- The bundle format and everything about how it is canonicalised, hashed, and sealed.
- The Merkle construction and the inclusion proofs built over it.
- The checkpoint signature and how the verifier checks it.
- The verifier's own logic, including its parsing and its failure paths.
Out of scope
- Attacks on any hosted Coriqo system. Leave our servers alone.
- Denial of service, of anything, at any scale.
- Social engineering of our team, our customers, or anyone else.
- Getting the private key by any means other than mathematics.
- Brute force described rather than performed. An estimate of how many machine-years it would take isn't a break.
Safe harbour
For work inside the scope above, we will not take legal action against you, and you may publish whatever you find, whenever you like.
That's the whole clause. It isn't conditional on us agreeing with your conclusion, on you giving us a window first, or on how the write-up makes us look.
Registration is open. Submissions aren't yet.
The bundle and verifier come first, and we'd rather hand them to a list of people who asked for them than announce an intake queue with nothing to put in it. Register below and we'll write to you on the day it opens.
We aren't accepting submissions yet
Anything sent before the window opens gets a reply asking you to hold onto it, which wastes your time and ours. This section stays on the page either way, so you can check the state here rather than wonder whether you imagined it.
Opening date: reading it from the corpus API…
Drop a bundle in and watch what happens.
The same checks verify_proof.py runs, in this page. Useful
two ways: confirm the bundle you downloaded is intact before you start, and watch your
forgery get rejected before you send it to us.
Your file is read in this tab and nowhere else. There is no upload, no request, and no copy kept — the page has the file open, our servers never see it. The code doing the checking is verify.js and verify-ui.js, both short enough to read before you trust them.
This browser doesn't implement Ed25519 in WebCrypto, so signature checks can't run here.
Everything else still will, and the result says so rather than passing it over. For the
complete check, run verify_proof.py from the bundle.
Tell us where to send it
We'll email you the download link and the SHA-256 when the bundle is published, and again on the day submissions open. Two emails, and then nothing unless you write back.
Registering doesn't commit you to anything, and it isn't a submission. It's a mailing list with one subject.
Submissions go to bounty@coriqo.io once the window above is open. We acknowledge every one within 48 hours and give a verdict within 10 business days. If we're going to miss that, we'll say so before the tenth day rather than after it.