The protocol, in detail.

1 · Scope of attestation

An Orphograph receipt attests precisely the following: a file whose SHA-256 fingerprint matches the recorded hash_hex existed by the time of the recorded Bitcoin block. No claim is made — and the protocol is structurally incapable of supporting any claim — regarding the file's authorship, ownership, originality, identity of submitter, location of submission, or the means by which the file was created (whether by a person, a model, or any other process).

2 · Client-side hashing

The browser computes the file's fingerprints using the platform Web Cryptography API. For a file of any size the procedure is:

const buf = await file.arrayBuffer();
const [s256, s512] = await Promise.all([
  crypto.subtle.digest("SHA-256", buf),
  crypto.subtle.digest("SHA-512", buf),
]);
const sha256_hex = hex(s256);
const sha512_hex = hex(s512);
// Only the hex digests are transmitted in the subsequent POST.

For large files the protocol supports a chunked-read variant that streams the file in megabyte-sized increments, computing both digests in a single pass without loading the file into memory. The Model Context Protocol server (mcp/orphograph_mcp.py) uses this variant when operating on local filesystem paths.

At no point during the hashing operation does the protocol issue a network request. The file body is not transmitted, not copied to disk, not exposed to extensions, and not made available to any code other than the WebCrypto primitive itself. The only data that leaves the originating process is the resulting hex digest.

3 · The SHA-512 sibling — a quantum hedge

OpenTimestamps commits a SHA-256 digest to the Bitcoin chain. The Orphograph receipt records the SHA-256 alongside a sibling SHA-512 of the same file. To forge a file-to-receipt binding, an attacker must produce a second file whose SHA-256 AND SHA-512 collide with the original — a much harder problem than producing either collision alone.

The argument matters because Grover's algorithm halves the effective bits of preimage resistance under a hypothetical large-scale quantum computer. SHA-256 falls from approximately 2^256 to 2^128 effective work; SHA-512 falls from 2^512 to 2^256. The dual-hash receipt preserves attack cost in the post-quantum range for the foreseeable future. The sibling witness is the protocol's hedge against an advance that current research does not anticipate within decades, but the cost of preparing for it is zero.

4 · Calendar aggregation

The OpenTimestamps protocol aggregates many submitted digests into a Merkle tree. The Merkle root is committed in a single Bitcoin transaction; each submitted digest receives a per-digest proof path (a sequence of hash operations that, when applied to the digest, reconstructs the committed root). The proof path is what the Orphograph protocol distributes as the .ots file.

The marginal Bitcoin cost per anchor is therefore the cost of one transaction divided by the number of anchors in the batch. With aggregator batches in the thousands per hour, the per-anchor on-chain cost is fractions of a cent and falls toward zero as load grows.

5 · Multi-calendar redundancy

Each anchor is submitted to five independently operated OpenTimestamps calendars: a.pool.opentimestamps.org, b.pool.opentimestamps.org, alice.btc.calendar.opentimestamps.org, finney.calendar.eternitywall.com, and btc.calendar.catallaxy.com. Each calendar produces its own .ots proof path against the calendar's own Bitcoin commitment.

The receipt is considered valid when ANY single calendar's proof verifies. Failure of one calendar — whether through transient unreachability, deliberate refusal, or permanent operator exit — does not invalidate the receipt. This is the structural guarantee against calendar-operator hostility.

6 · The .ots proof format

An .ots file is a binary sequence of hash operations (op_sha256, op_append, op_prepend, and several others) which, when applied in order to the original digest, yields the Merkle root that the calendar published to the Bitcoin chain in its commitment transaction. A verifier executes the operations against a held copy of the file's digest, compares the resulting hash against the publicly-readable Bitcoin commitment, and accepts or rejects the receipt accordingly.

The format is independently documented at github.com/opentimestamps/python-opentimestamps; the Orphograph distribution of the receipt does not modify the OTS format in any way.

7 · Receipt envelope

The receipt JSON has the following shape (with optional fields shown):

{
  "receipt_id":      "<16-char url-safe>",
  "created_at":      "<UTC ISO-8601>",
  "hash_hex":        "<64-char SHA-256 hex>",
  "sha512_hex":      "<128-char SHA-512 hex>",
  "client_label":    "<optional human-readable string, ≤200 chars>",
  "source":          "free | pack:<prefix> | sub:<hmac-id> | api:<prefix>",
  "calendars_ok":    N,
  "calendars_total": M,
  "successes":       [ { "calendar": URL, "ots_path": "...", "ots_bytes": N }, ... ],
  "failures":        [ ... ],
  "c2pa_manifest_hash": "<optional 64-char SHA-256 hex>",
  "private":         true | false,
  "owner_id":        "<HMAC-keyed identifier, 16 hex chars, or null>",
  "btc_pinned_at":   "<UTC ISO-8601 once committed, else null>",
  "pinned_count":    N,
  "pinned_total":    M
}

8 · HMAC-keyed identifiers for private receipts

Subscribers who mark a receipt private have their email address transformed at receipt time using a HMAC function with a per-installation secret known only to the office. The output is recorded as owner_id; the plaintext email is never written to disk in association with the receipt.

Access to a private receipt requires presentation of a valid session cookie whose underlying email, when transformed by the same HMAC, matches the stored owner_id. An attacker who obtained the receipt vault by other means cannot dictionary-attack the receipt-to-email mapping without also obtaining the per-installation HMAC secret.

9 · Verification independence

Verification of an Orphograph receipt requires:

• a copy of the original file (held by the customer),
• the receipt JSON and the .ots proof files (held by the customer, or available at orphograph.com/r/<id>),
• any OpenTimestamps client OR the 100-line MIT-licensed verifier at github.com/Orphograph/Orphograph OR the single-file browser verifier at /verify-js.html.

Notably absent from this list is any call to Orphograph's servers. The office issues the instrument; the chain is the trust anchor. The continuity statement at /continuity.html expands on the operational implications.

10 · C2PA coexistence mode

When a customer holds a Coalition for Content Provenance and Authenticity (C2PA) manifest for the same file, the SHA-256 of that manifest may be recorded on the Orphograph receipt as c2pa_manifest_hash. The receipt then references both attestations without disclosing the content of either. The two systems are complementary: C2PA documents how an asset was captured and edited; Orphograph attests when its fingerprint existed. A reader presented with both has the complete provenance picture; a reader presented with only Orphograph has the date-of-existence; a reader presented with only C2PA has the chain of capture.

11 · Failure modes and operational continuity

The protocol's robustness is enumerated against the following failure scenarios:

• Calendar unavailability. Five-calendar redundancy ensures any single failure is invisible to the customer.
• This office becoming unreachable. Every receipt verifies against the Bitcoin chain independently. See /continuity.html.
• Bitcoin fee-market degradation. Aggregation amortises per-block transaction fees across all customers anchored in that block, keeping per-anchor cost negligible even under sustained fee pressure.
• Receipt vault data loss. The vault is convenience storage; the customer-held original file plus the .ots proof are sufficient to reconstruct the verification path.

12 · What is stored, what is not

The office persists, per anchor: the receipt JSON, the per-calendar .ots proof files, the HMAC-keyed owner_id when the receipt is private, the source attribution. The office persists, per account-holder: the email used at sign-in, the HMAC-keyed identifier derived from it, the Stripe customer identifier for billing.

The office does NOT persist: file contents, file paths, file names, plaintext owner email tied to a private receipt, full network addresses (only truncated /24 prefixes, briefly, for rate-limiting), browser or device fingerprints, behavioural profiles, page-level analytics tied to individual visitors.

13 · Publication date and prior-art status

This document was first published on 2026-05-18. It is anchored to the Bitcoin chain on publication using the protocol it describes; the receipt identifier for this revision is recorded in the footer below. Subsequent revisions are anchored separately; their receipts are appended to the same footer record.

The combination of detailed disclosure, MIT licensing of the verifier and protocol code, and a Bitcoin-anchored publication date establishes this page as prior art for the methods described. Any later filing — by any party — that claims novelty on these methods is rebuttable by reference to this publication.

Citations and verification

• Standalone independent verifier (single HTML file)
• Comparison with C2PA
• Frequently asked
• Continuity statement
• Model Context Protocol server
• Webhook integration
• github.com/Orphograph/Orphograph
• opentimestamps.org