Content hash anchoring: prove it existed, then

1. The problem: existence claims without evidence

A contract counterparty claims a clause was agreed in March; you believe it was April. A regulator asks when a policy version took effect. An investigator needs to show a seized file is byte-identical to the one logged at collection. A journalist asks whether a published document predates a leak. In every case someone asserts “this content existed in this state at this time” — and assertions are cheap.

The usual substitutes fail under pressure:

• File timestamps. Trivially forged, reset by copies, and meaningless across systems. No auditor accepts mtime as proof.
• Emailing it to yourself. Proves an email provider saw bytes at some point — not what those bytes were, and dependent on a third party's records and cooperation years later.
• Notarization or trusted third parties. Works but scales poorly: per-document fees, business-hours latency, and content disclosure to an outside party for every item worth protecting.
• Public blockchains. Immutable, but every anchor is a public disclosure of interest, with unpredictable fees, ungovernable retention, and content-metadata leakage into a ledger you do not control.

What teams actually need is a private, scalable way to commit to content-plus-time — provable later by anyone holding the file, disclosing nothing to anyone holding only the receipt.

2. What good looks like on your infrastructure

1. Hash-only anchoring. The registry stores digests, never content. Anchoring a thousand documents discloses zero bytes to the log itself.
2. Append-only, hash-chained log. Each entry commits to its predecessor with a signed root. History cannot be rewritten without detection.
3. Independent timestamps. The receipt binds content to a moment recorded separately from the system holding the file — so file-store tampering does not move the timestamp.
4. Open verification. Re-hash locally, walk the chain, compare. No proprietary tool, vendor account, or network access required.

The registry runs on your infrastructure under your retention policy. Verification is a local computation anyone can repeat.

3. How anchoring works — hash, append, receipt

Hash

Take the SHA-256 digest of the exact bytes you want to commit to — a contract PDF, a dataset snapshot, a manifest of manifests. Hash on your own host; the content never leaves. Attach minimal metadata: a label, the hash algorithm identifier, and whatever context your retention policy requires.

Append

Hash Anchor appends the digest to its log, chaining it to the previous entry and signing the new root. The append is the timestamp: the entry's position in an append-only sequence, not a wall-clock assertion anyone can edit. Batch nightly sweeps or per-release sets the same way — one receipt per entry, one chain for all of them.

Receipt

You receive a compact receipt: entry identifier, digest, algorithm, timestamp, and chain position. Disclose it freely — in filings, in evidence bundles, alongside published media. A verifier with the file re-hashes, finds the entry, checks the chain, and confirms both state and moment. A verifier with only the receipt learns nothing about the content.

4. The components

One registry, two natural companions for the things worth anchoring.

Start with Hash Anchor alone for document time-proofs. Pair with Evidence Locker when custody and proof must live apart.

5. How to verify it — re-hash, check chain, compare time

• Re-hash the file. SHA-256 over the exact bytes, locally. Any tool computes it; agreement with the receipt digest proves state.
• Walk the chain. Confirm the entry's position links unbroken to the signed root. A gap or mismatch means the log was altered after the fact.
• Compare the timestamp. The entry time must precede the disputed moment and follow the claimed creation — the receipt bounds the claim on both sides.
• Check the algorithm field. Receipts name their digest algorithm explicitly so verifiers never assume it. Migrating algorithms? Anchor under both during transition.
• Separate-system test. Verify from a host with access to neither the registry operator's credentials nor the file store — independence is the property being proven.

6. Buying checklist

• ☐ Registry stores digests only — anchoring discloses zero content bytes
• ☐ Log is append-only and hash-chained with a signed root
• ☐ Receipts carry entry id, digest, algorithm, timestamp, and chain position
• ☐ Batch anchoring supported with per-entry receipts
• ☐ Verification is open recomputation — no vendor tool or account needed
• ☐ Registry runs on your infrastructure under your retention policy
• ☐ Exportable log for auditors (JSON/CSV) with no proprietary viewer
• ☐ Studio experiment available without signup — isolated demo host, try before installing
• ☐ No timestamp-authority or blockchain claims — the chain is the proof

7. Common anti-patterns to avoid

• Hashing the copy, not the original. Anchor before distribution, migration, or conversion. A digest of a transcoded file proves nothing about the source.
• Proof and file in one system. If the same admin can rewrite both the store and the log, the anchor adds nothing. Separate them.
• Algorithm silence. “Hash” without a named algorithm is unverifiable. Every receipt must state its digest function.
• Public ledger by default. Anchoring everything to a chain you do not govern trades verifiability for permanent metadata exposure. Keep the log yours.
• Timestamp as wall clock. A signed assertion of “now” from the same box holding the file is self-attestation. Position in an append-only sequence is the timestamp that matters.

Frequently asked questions