How the blockchain seal works — and how to check it yourself

What happens when a delivery is sealed

1. 1

   Each file is fingerprinted before it leaves the sender

   As a file uploads, the sender's own browser computes its SHA-256 fingerprint — a 64-character value that changes completely if a single byte of the file changes. It is calculated on the sender's device, before the file crosses any network.

2. 2

   The fingerprints are written into one manifest

   Sealing lists every file in the delivery — its name, exact size, type and fingerprint — in a fixed, documented format. The SHA-256 of that list is the manifest digest: one value that covers every file at once.

3. 3

   The manifest digest is timestamped into Bitcoin

   The digest is submitted to the public OpenTimestamps calendar servers, which commit it into a Bitcoin transaction. No file, filename or content is sent — only a fingerprint of the fingerprint list. Confirmation typically takes one to three hours, after which the proof no longer depends on the calendar servers or on us.

4. 4

   The delivery is frozen

   While a delivery is sealed, no file can be added, removed or replaced — not by upload, deletion, or moving files between cases. Changing it means unsealing, which is recorded; sealing again produces a new manifest, a new digest and a new timestamp. Every seal and unseal is written to an append-only, hash-chained log, so the history cannot be quietly rewritten either. The one thing that still removes files is the delivery's own retention schedule, and the receipt marks each file it has removed.

The chain you are checking

Each link can be recomputed by anyone. If every link holds, the file in front of you is byte-for-byte the file that was sealed, and the seal existed no later than the Bitcoin block named.

1. Your file

   exactly as you received it

2. Its SHA-256 fingerprint

   listed in the manifest

3. The manifest's SHA-256

   printed on the receipt

4. A Bitcoin block

   which nobody can rewrite

What you need

The recipient of a sealed delivery sees a Seal Receipt link at the top of the case. The receipt offers two downloads. Save them into the same folder, together with the receipt itself (printing it to PDF is fine):

seal-XXXXXXXX.json

The sealed manifest — the exact list of files and fingerprints that was timestamped.

seal-XXXXXXXX.json.ots

The timestamp proof — the path from that manifest into a Bitcoin block. Offered once Bitcoin has confirmed it, usually within one to three hours of sealing.

How to check a seal, step by step

Four checks. Each is independent of the others, and none of them needs anything from us.

1. 1

   Check a file against its fingerprint

   Compute the file's SHA-256 with the tool your system already has:

   Windows

   certutil -hashfile "surveillance-01.mp4" SHA256

   macOS

   shasum -a 256 "surveillance-01.mp4"

   Linux

   sha256sum "surveillance-01.mp4"

   Compare the result to that file's fingerprint on the receipt or in the manifest, ignoring letter case and any spaces. A match means this is byte-for-byte the file that was sealed. Any difference at all means it is not.

2. 2

   Check the manifest is the one that was sealed

   Run the same command on the manifest file — for example, on Linux:

   sha256sum seal-XXXXXXXX.json

   The result must equal the manifest digest printed on the receipt. This is what ties the per-file fingerprints to the value that was timestamped.

3. 3

   Check the manifest lists your files

   Open seal-XXXXXXXX.jsonin any text editor. It is a single line of JSON with one entry per file, and each entry's sha256 field is the fingerprint you checked in step 1.

4. 4

   Check when it was sealed, against Bitcoin

   Install the OpenTimestamps reference client, an open-source tool we did not write and cannot influence:

   pip install opentimestamps-client

   Then, in the folder holding both downloads:

   ots verify seal-XXXXXXXX.json.ots

   The client finds seal-XXXXXXXX.json beside the proof on its own, checks that it is the file the proof was made for, and checks the proof against Bitcoin. A valid seal reports:

   Success! Bitcoin block 965977 attests existence as of …

   with the real block number and date. If the manifest has been altered in any way it reports File does not match original! instead.

   The client checks the block against a Bitcoin node you run, and trusts nobody when you do; without one it relies on a public block explorer. That is a trust assumption, and it is yours to make or refuse — not ours.

   Prefer not to install anything? The same check runs at opentimestamps.org. That sends the proof file to a third party; it contains only hashes and reveals nothing about the case, the files or the people involved, but if that matters, use the command-line client.

For technical reviewers: the manifest format

The manifest is a JSON array with one object per file, sorted by fileId, keys always in the order fileId, filename, sizeBytes, mimeType, sha256, strings escaped as standard JSON, UTF-8, with no whitespace and no trailing newline. sizeBytes is the exact byte count and sha256is lowercase hex. The manifest digest is the SHA-256 of those bytes. The proof's header records SHA-256 with that digest as its message, which is why ots verify accepts the manifest file directly.

[{"fileId":"…","filename":"surveillance-01.mp4","sizeBytes":1900000000,"mimeType":"video/mp4","sha256":"…"}]