The 100-line verifier, annotated.

1 · The role of the verifier in the trust architecture

An attestation that requires the issuer to be present in order to be checked is an attestation whose evidentiary weight is bounded by the issuer's continued availability. Such an attestation collapses to nothing the moment the issuer becomes unreachable, unwilling, or insolvent. The protocol is designed to refuse this dependency. The receipt the office issues is checkable against the Bitcoin chain by any party holding the file, the receipt, and a program that executes the OpenTimestamps format — the reference client being the obvious one.

The office's verifier is the artifact that closes the remaining gap, which is a different gap: it establishes that a given proof and a given receipt are about a given file. The chain provides the ordering oracle; the OpenTimestamps protocol provides the aggregation and, through its client, the chain check; the receipt records the per-anchor proof path; the office's verifier binds the customer's bytes to that record. Together they compose a path from the bytes to a chain-attested time of existence, and the path traverses no party whose continued cooperation is required — least of all the office, which authored only the binding step.

2 · Why MIT

The verifier is published under the MIT licence. The choice is not incidental. A verifier that the office held proprietary would be a verifier whose continued availability depended on the office's continued willingness to publish and operate it. A verifier that any party may run, fork, audit, redistribute, embed, or rewrite is a verifier that has been promoted from an artifact of the office into a public good. The licence is upstream of the trust: the verifier is the trustworthy object because the licence permits any party to make it so.

The practical consequences of the licence are several. Any party may inspect the source to confirm that the verifier does what it claims. Any party may compile and run the verifier on their own hardware, with no network call to the office, in airgapped environments, against archived copies of the receipt. Any party may package the verifier into a different system, into a court-evidence workflow, into a backup procedure, or into a wholly different brand of notary that nevertheless can check the office's receipts. The MIT licence makes each of these uses unambiguous and uncontested.

The licence applies to the code, not to the brand. The verifier may be copied, modified, and redistributed; the office's name, marks, and rendered material remain reserved. The intent is that the trust mechanism is a public good and the brand around the mechanism is the office's own.

3 · The Python verifier, in walk-through

The Python verifier is published at github.com/Orphograph/Orphograph. It is intended to be short enough to be read in a single sitting, audited by a competent reader without specialised tooling, and operated with no dependencies beyond the standard library. The line count is small because the work it performs is small; the OpenTimestamps proof format is compact, and verifying a proof reduces to executing a short sequence of byte-level operations and comparing the result to a known commitment.

What the verifier reads:

• The original file whose existence is being established. The verifier opens the file, streams its bytes through a SHA-256 computation, and derives the file's fingerprint.
• The corresponding .ots proof file. The proof is a binary record of a sequence of hash operations — append a known suffix, prepend a known prefix, apply a SHA-256, apply a RIPEMD-160, and so on — together with a reference to the Bitcoin block whose Merkle root the proof terminates against.

What the verifier executes:

• It re-derives the file's SHA-256 from the bytes on disk, when the file is supplied.
• It confirms that each .ots file carries a well-formed OpenTimestamps header.
• It confirms that the digest embedded in each .ots is the digest the receipt claims was anchored — binding proof to receipt.
• For a folder anchor, it walks the local directory through the same RFC 6962 construction the office used and compares the recomputed Merkle root against the root the manifest records.

What the verifier concludes:

• On a match, the bundle is internally consistent: this proof is about this file, and the recorded root is the root these bytes produce. The verifier reports OK.
• On a mismatch, the bundle is unsound — the file was altered, the proof was altered, or the wrong file has been paired with the proof — and the verifier reports which comparison diverged.

4 · Relation to upstream OpenTimestamps clients

The verifier is functionally equivalent to any conforming OpenTimestamps client. A receipt issued by the office is checkable by the office's verifier, by the reference Python OpenTimestamps client, by any third-party implementation that adheres to the format, or by a fresh implementation written from the published specification. The office does not control the verification path; the office contributes one implementation among many, and adheres in that implementation to the public specification.

The line count of the office's verifier is small because it omits, on purpose, the part someone else already does better. Interpreting the proof's operation sequence and testing the result against the chain is the reference client's function; it is maintained by the OpenTimestamps project, audited far more widely than anything this office publishes, and a reader who is checking whether they must trust the office should prefer it precisely because the office did not write it. Re-implementing it here would add a second thing to trust and subtract nothing from the first. The office's verifier covers the layer the reference client does not: that this proof and this receipt are about this file.

The consequence is that full verification composes two independent programs from two independent authors, and the office controls neither the harder one nor the path a reader takes through it.

5 · What the verifier does not do

The verifier is honest about its scope, and the office is willing to enumerate the bounds.

The verifier never calls a Bitcoin node, in any configuration, and reads no block header. It makes no network call at all. It cannot tell you that your file's fingerprint reached the chain, and it does not claim to: a proof that no calendar ever attested satisfies every comparison it performs.

The chain step belongs to the OpenTimestamps reference client, and that client requires a Bitcoin node it can reach — it does not fall back to a block explorer. Running ots verify without a node produces a connection error, not a verdict. The office's downloadable bundle will invoke the client for you when passed --ots, and reports the client's own answer: confirmed, pending, rejected, or — when no node was reachable — that the check did not run. That last outcome is reported as its own state and never as a failure of your receipt, because it says nothing about your receipt.

The practical reading: a reader who wants the strongest available assurance runs the reference client against a node they operate, so the Merkle root compared against comes from a chain they have themselves validated end to end. A reader who runs neither still has the binding check, which is a real and useful thing, and is not the same thing.

The verifier does not, in any configuration, undertake to opine on the file's authorship, ownership, originality, or means of creation. The bounds of the underlying attestation are the bounds of the verifier's output; the verifier reports what is true and declines to extrapolate.

6 · The browser verifier, complementary

The office publishes a second verifier intended for the browser environment, at /verify-js.html. It is an HTML document and its verifier script, with no third-party code and no build step; the pair may be saved to disk with the browser's complete-page option, run offline, opened in any modern browser, and used to check the file-to-receipt binding without an installed Python interpreter and without a network connection.

The browser verifier covers the file-to-receipt binding: given the file and the receipt, it derives the file's SHA-256, compares it against the hash_hex the receipt records, and confirms the receipt is in fact about this file. The Python verifier covers proof-to-receipt binding and folder-root re-derivation. Neither consults Bitcoin.

Full verification is therefore three parts, not two, and only the third touches the chain:

• File → receipt. Browser verifier, or the Python verifier given the file.
• Receipt → proof. Python verifier: the .ots files are well-formed and embed this receipt's digest.
• Proof → Bitcoin. The OpenTimestamps reference client, against a node. Not the office's software.

A reader holding all three establishes — without consulting the office and without trusting the office — that these bytes were attested by the chain at the moment the proof records. A reader holding fewer establishes correspondingly less, and the honest description of the first two steps alone is that the bundle is internally consistent. The architecture is decomposable, each component is independently inspectable, and the office authored only the two weakest links on purpose.

7 · The verifier as durable artifact

It is appropriate, in closing, to state the office's own ordering of priorities. The office regards the verifier as the most important durable artifact it produces; the receipts as the second; the operational website as a courtesy that may someday be withdrawn without diminishing the standing of what came before. The receipts are the things the customer holds; the verifier is the thing that ensures the receipts remain checkable when the office is no longer present to check them.

A receipt that is checkable only by the issuer is, in the long view, no more than the issuer's promise to remember. A receipt that is checkable by any competent party in possession of the published verifier, the file, and the proof, is something else: it is an instrument whose evidentiary weight is independent of the institution that issued it. The verifier is the line between these two possibilities, and the office regards the maintenance of that line — including its MIT licensing, its minimal dependency profile, its archival publication — as the central operational commitment of the protocol.

8 · Publication date and prior-art status

The page is first published on 2026-05-19. The disclosure itself, and its publication date, are what establish prior art here. No public per-page receipt is published for this document — a receipt embedded in the page it attests would change that page and invalidate the attestation, so the office does not claim one it cannot honour. The combination of detailed walk-through, MIT licensing of the verifier itself, and a chain-anchored publication date establishes this page as prior art for the decomposed-verifier architecture described.

Citations and verification

• Architecture of the protocol
• Frequently asked
• github.com/Orphograph/Orphograph
• opentimestamps.org