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 and, when the client supplies one, a sibling SHA-512 of the same file. Where the sibling is present, forging a file-to-receipt binding requires 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. Where the sibling is recorded, 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 public OpenTimestamps calendar servers: a.pool.opentimestamps.org, b.pool.opentimestamps.org, alice.btc.calendar.opentimestamps.org, finney.calendar.eternitywall.com, and btc.calendar.catallaxy.com. Each submission returns its own .ots proof path. Two of the five, a.pool and b.pool, are aggregators that feed the alice and bob calendars, so the five submissions reach four distinct calendars (alice, bob, finney, catallaxy) under three separately run domains. The a.pool proof and the alice proof therefore both go through the alice calendar and normally end in the same commitment; the other three end in their own.

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":        [ ... ],
  "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. Ownership is never decided from a plaintext address on the receipt. The one address the office itself writes to a receipt is the confirmation-notice address described in §12.

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 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.

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, and, for a paid anchor, the address its receipt email and Bitcoin confirmation notice go to (notify_email: the address sent with the anchor, or a subscriber's sign-in address). That address is kept with the receipt until the receipt first reaches Bitcoin and the confirmation notice is sent; it is then removed from public receipts. A private receipt keeps it, for its owner. It is never part of what a receipt's public routes and exports serve; the owner's own account export is the one place it appears. 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, for any anchor: file contents, full network addresses (only truncated /24 prefixes, briefly, for rate-limiting), browser or device fingerprints, behavioural profiles, page-level analytics tied to individual visitors.

File paths and file names divide by anchor kind. Single-file anchoring transmits and persists neither: the fingerprint is the only trace of the file the office ever holds. Folder anchoring persists the manifest, which records each leaf's relative path and byte size — the trade-off stated in §7 of the folder-anchoring paper. The office serves those paths only to the receipt's owner; every other requester receives the manifest with paths redacted, leaf hashes and file digests intact, unless the owner elected at anchor time to make the paths public.

13 · Publication date and prior-art status

This document was first published on 2026-05-18 and anchored to the Bitcoin chain on that date using the protocol it describes; that receipt is recorded in the footer below and covers the text as it then stood. Later revisions are not separately anchored with public per-page receipts today — the repository is anchored daily as a whole, but a per-page receipt would have to be embedded in the page it attests, which changes the page and invalidates the attestation. The honest statement is therefore the narrow one: the receipt establishes the publication date of the original disclosure, not the wording of the current revision.

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 (in the browser)
• Frequently asked
• Continuity statement
• Model Context Protocol server
• Webhook integration
• github.com/Orphograph/Orphograph
• opentimestamps.org