◆ The Proof Factory
You are holding something.
Check it right here.
Most people know one model of verification: you upload a file to a site and get an answer. That model verifies an object — it has a fixed hash, you run it again, you compare.
A disclosure is not an object but an event: who opened it, when, and that we did not see it. An event cannot be uploaded again — it happened once. So you do not verify the file but the receipt, and you do it in four legs that do not depend on one another.
Check a proof number
Got a number on a document transfer, a file, or a decision? Paste it here.
Your number appears on the transfer page after every transfer, and on every receipt in the system.
What gets checked, in order
that the file is the same file
For every transfer we keep a sha256 hash of the original content, computed in the sender’s browser before encryption. You run sha256 on the file in your hands and compare. We never saw the content, so we could not have invented that number — and that is exactly what makes the comparison worth something.
does not depend on us
that we issued the receipt, and that it was not altered
Receipts are signed with Ed25519, and some also with ML-DSA-65. The public key travels inside the receipt and is also published separately. A valid signature closes off after-the-fact editing — it does not make us a neutral witness, and that is a difference worth saying out loud.
depends on the published key
that the time was not set by us
The receipts are grouped into an epoch stamp, and its Merkle root is anchored in the Bitcoin chain via OpenTimestamps. Once a block is closed, no one — us included — can move the time backward.
does not depend on us
that no event was removed from the middle
Every receipt points at the one before it. In a single transfer’s pack the numbering runs from 0 in sequence, so a hole in the chain shows immediately. That is different from a broad export, where a hole only means the window was narrow.
checked inside the pack
What this proof does not say
If we wrote only what it does say, someone would read it in good faith and conclude too much. So, explicitly:
- That the file is the one we meant to send. A hash binds bytes to a receipt. It does not know whether the right file was chosen.
- That the recipient did not copy the file after opening it. Once bytes are on their device, they are theirs. The record logs the release, not what happened after.
- That we are a neutral witness to our own log. The signature proves a receipt was not altered after it was issued. It does not prove we issued a receipt for every event. The two legs that do not depend on us are the content hash (we could not compute it) and the Bitcoin anchor (the clock is not ours).
- That the code was kept secret. A link and a six-digit code are the whole authorization. Whoever holds both looks, in this record, exactly like the intended party.
◆ For readers on the security side
Why this counts as proof, and how to read it in three minutes
The structure here is not new and is not meant to be. It is an append-only linked hash chain with Ed25519 signatures, grouped into epoch stamps whose root is anchored in OpenTimestamps. The same model behind Certificate Transparency — there, so that no certificate authority can quietly issue a certificate; here, so that no file release can quietly disappear. If you have ever inspected a CT log, you know how to read this.
The question worth asking about any such system is not «is there a signature» but what happens if the vendor lies. A signature on our own log does not answer that — it prevents after-the-fact editing, and no more. The two legs that do answer are: a hash computed on the other side before the content was encrypted (we could not produce it), and an anchor in a chain we do not operate. Those two legs work without us. The convenient path — pasting a serial into the box above and getting a verdict — plainly asks us, and we say so.
The practical check: ask the party holding the transfer for the evidence pack (JSON). The math is written inside the pack itself, under verification_recipe: recompute every event_hash, check every Ed25519 signature against the key that travels in the file, and walk the chain by index. It runs in WebCrypto in a browser with the network disconnected, and the same recipe runs as a Node or bash script — no page of ours in the loop.
What signals honesty: a pack can come back with empty fields. A receipt created before its signing mechanism went live returns signature_hex: null, and transfers made before 2026-08-19 carry no content hash at all. Our tools mark these cases as «cannot be checked», not «failed», and do not backfill them retroactively — bytes were signed then or they were not. If you see a system that fills such holes after the fact, that is the sign worth asking about.
The numbers on this page were measured 2026-08-19 and are correct as of that date. If something here does not line up with what you saw in the system — that is a good question, and we would rather receive it than have it linger.