Verification
Everything else on this site asks you to believe something. This does not. Given the evidence archive and the certificate, the check is arithmetic, and the record you compare it against sits on a public blockchain that we cannot alter.
A certificate is a pointer to two things. Neither of them is a screenshot of a screen, and neither of them is our word.
One JSON file, evidence.json, holding everything that was certified: the NDA and its fingerprint, each party with the way they were actually identified and the moment they accepted, and, for a protected meeting, the transcript (with both versions and their fingerprints, if it was corrected), the event log of the meeting and the fingerprint of the recording. It is not a summary of what happened. It is what happened.
A public transaction on Polygon PoS in which the fingerprint of that package was written, with a block number and a block timestamp. From the moment it is mined, neither we nor anyone else can move it, amend it or take it back.
In this order. The third one is only meaningful if the second one passed.
01
Take the SHA-256 of evidence.json exactly as it is. The file inside the archive is already in canonical form, so there is nothing to normalise first and no library of ours to install.
02
It must equal the package hash printed on the certificate: on the PDF, in certificate.json inside the archive, and on the public verification page. If it differs, the evidence in your hands is not the evidence that was certified, and the third check is pointless.
03
Open the anchoring transaction on any block explorer and read the Anchored event. The hash it carries must be the one you just computed. The block timestamp tells you the moment after which that fingerprint could no longer be changed by anybody.
Hashing JSON naively would be a lottery: the same content, written by two programs, gives two different byte streams (a different key order, a different spacing, a different way of writing the same number) and therefore two different hashes.
So the package is written in the canonical form of RFC 8785. Canonical means there is exactly one admissible way to write a given content: keys sorted, one written form for every number and every string, UTF-8 output. Two people, on two machines, ten years apart, produce the same bytes from the same package, which is what makes “recompute the hash” a procedure instead of an invitation.
It is also why the file we ship is already canonical: on that file, a plain SHA-256 is the whole of the first check.
Two commands and a link. Nothing here is ours.
Recompute the fingerprint: macOS, Linux
shasum -a 256 evidence.jsonRecompute the fingerprint: Windows
certutil -hashfile evidence.json SHA256Open the anchoring transaction: the id is on your certificate
https://polygonscan.com/tx/<transaction id>The anchoring contract: Polygon PoS, chain 137
0x5CceC6F5806b7C949eB90D61fB9D13Cb639AC203Source verified on Polygonscan. Anchored(hash, timestamp, sender) is emitted for a dedicated transaction. The contract also defines BatchAnchored(merkleRoot, timestamp, sender) for a daily batch, which is not in use yet: today every certificate has its own transaction.
Open the contract on PolygonscanWe maintain a command-line verifier that does all of the above in one command, Merkle proofs included. It is MIT-licensed and it is not published on a public registry yet, so there is currently no way for you to obtain it, which is exactly why this page is written around tools you already have. When it is published, this is where the instruction will appear.
Today every fingerprint reaches the chain in its own transaction. The contract also supports a daily batch, not in use yet; when it is, it will be equally checkable. What changes is cost and immediacy, not strength.
The Anchored event carries your package fingerprint directly. You look for your own hash and you find it, or you do not.
Only the root of a tree goes on chain, in a BatchAnchored event, and the certificate carries the proof that leads from your fingerprint to that root: the leaf is the keccak-256 of the package hash, each internal node the keccak-256 of the sorted pair of its children. The proof is checkable offline, on your own machine, and the root must then appear in a BatchAnchored event. A batched certificate is not a weaker certificate, it is the same proof with one more short step.
A certificate that reads “anchoring pending” has been sealed but not yet written to the chain. Its fingerprint is already fixed; what is missing is the transaction. It is a state, and the page says which one it is: never a silent “anchored”.
Verifiability and confidentiality are not in tension here, because the boundary is not a rule someone follows: it is a database view, and a view can only return what it selects.
None of this is redacted after the fact. It is not selected: the query that serves that page cannot reach those columns at all.
A mismatch is information, not an accusation. Read it in this order.
The commonest cause by far is that the file was opened and saved again by a tool that reformatted it: one added space is enough. Download the original archive again and recompute on the untouched file.
Then the evidence you were given is not the evidence that was certified, and the certificate does not cover it. Tell whoever gave you the file, and write to us with the certificate code.
Check it character by character against the certificate: the code has a fixed shape, CNDA-XXXX-XXXX-XXXX. A code that is well formed and still unknown means no certificate was ever issued with it.
The public verification asks for nothing else: no account, no email address, no reason.
Verify a certificate