Break the seal.
An examiner, an auditor or a board shouldn't have to take our word that a record hasn't been changed. So we invite anyone to try to break it, in public, and we publish any break they find.
Coriqo seals AI evidence 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 is no prize money, not even a token payment. We are a small company, and we would rather say so 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.
Before you start: we already found and published three defects ourselves. That tells you which corners we have already checked.
One zip: a sealed record, its checkpoint, and the verifier.
An examiner can check a sealed record without our help, and so can you. 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 next to the code. You can read what each field is meant to say before you try to make it say something else.
Nothing in the archive calls home. It has 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 is 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.
Everyone who relies on a sealed record is relying on one claim. The claim 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 dents that claim 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 sit in the archive, or on a text-formatting rule 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 case matters as much as the first. Nobody will trust a checker that fails honest records when it counts.
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 makes it easy to enter: there is no invoice, no tax form and no identity check. 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 publishes a number for each severity level. 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: 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.
Someone else has to be able to reproduce a break offline, because the people who rely on the record need to be able to rerun it themselves. 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. We would rather hand them to people who asked for them than announce an intake queue with nothing 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 opens the file and 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 checksum when the bundle is published, and again on the day submissions open. That is two emails, and then nothing unless you write back.
Registering doesn't commit you to anything, and it isn't a submission. It is 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 are going to miss that, we'll tell you before the tenth day, not after.