Proof Anchored on chain
Includes the bundle, a printable PDF proof, and a verify guide. Keep alongside the original file.
Include the original file in this package (optional)
Pick the file you anchored. Your browser will re-hash it locally and compare against the anchored fingerprint; the file’s bytes never leave this page. If it matches, it will be bundled into original/ inside the ZIP so recipients have everything in one place.
Keep these two together
Verifying later needs both: your original file and the bundle. The proof commits to the file’s fingerprint, not its bytes — we never had them.
In plain terms. This is tamper-evident proof that whoever anchored it held this file’s fingerprint (its SHA-256) by 2026-05-02T02:04:16Z UTC, recorded on the public BSV chain. Anyone can re-check it without trusting Satsignal — it does not establish authorship, or that the event the file describes actually happened. The full breakdown is below.
Standard proof — file never left your device. Your file was NOT uploaded. Only its SHA-256 hash, file size, and any label you typed were transmitted.
A valid proof establishes the file existed in this exact form at the time of the on-chain transaction. It does not prove:
- that the underlying event the file describes actually happened;
- who produced the file, who saw it, or who signed it;
- what the file means or whether its claims are true.
Technical proof detail — hashes, on-chain commitment, size
- File SHA-256 file fingerprint
139eb4599dace99757b1d7a441abc4981d629951aaa91f23089a38f8240ae17d- File size
- 1,920bytes
- Filename label
- sample.png
- Anchored at (UTC)
- 2026-05-02T02:04:16ZUTC
- Transaction on-chain record
-
031e6b1e44a0edab62d1ea75f9a898a994e86f11c87be0779fa12cbec7bd4538 - On-chain commitment cryptographic anchor
6e9091e901a76d463e7282383d91bb5ecbec447a
Proofs anchored
Three orthogonal proofs about your file are committed in a single on-chain anchor. Use whichever the situation calls for.
- Byte-exact
139eb4599dace99757b1d7a441abc4981d629951aaa91f23089a38f8240ae17d- Content-canonical
2a61b3da3e704fd82f73248130c69068f3ec78a8dd31912a29923f24f08eaba9- Per-section commitment
779e410d002ab5a5bf8870a8558fd8ae51c58333efd51c6de2f4dfab8a71445e
Other download options
How to verify this proof yourself (manual recipe)
For an audit trail or scripting, here are
the manual steps anyone can run with sha256sum:
- Re-fetch the on-chain transaction:
https://whatsonchain.com/tx/031e6b1e44a0edab62d1ea75f9a898a994e86f11c87be0779fa12cbec7bd4538— confirm anOP_RETURNoutput starting with the bytesMBNT. - Decode the OP_RETURN payload: bytes 8–27 are the
doc_hash(sha256 of the canonical proof doc, truncated to 20 bytes; bytes 0–3 areMBNT, 4 the version, 5 the subtype, 6–7 the TLV length). It must match6e9091e901a76d463e7282383d91bb5ecbec447a. - Hash the included
canonical.jsonfrom the.mbntbundle directly — the bundle stores the exact bytes that were hashed on-chain, so do not re-canonicalize:sha256sum canonical.json | cut -c1-40. The first 40 hex chars must equal6e9091e901a76d463e7282383d91bb5ecbec447a. (If you instead re-canonicalize to defend against a tampered stored copy, you MUST use SCJ-v1 — code-point key sort, NFC, floats forbidden — not RFC 8785 / a generic JCS library: the product uses three non-interchangeable JSON canonicalizers. See the MBNT spec §5.) - Sha256 the original file — must equal the File SHA-256 above. The bundle does not contain the bytes; you kept them.