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 in possession of the file, the receipt, and a program capable of executing the OpenTimestamps format. The verifier is that program in its minimal form.

The verifier is therefore the artifact that closes the trust architecture. The chain provides the ordering oracle; the OpenTimestamps protocol provides the aggregation; the receipt records the per-anchor proof path; the verifier executes the proof path and reports the result. The four together compose a path from the customer's bytes to a chain-attested time of existence, and the path traverses no party whose continued cooperation is required.

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 parses the binary proof into the sequence of operations it encodes.
• It initialises a working value to the file's fingerprint.
• It applies each operation in order, updating the working value. Each operation is one of the small, well-defined transformations the OpenTimestamps specification enumerates; the verifier implements each operation explicitly in standard-library code.
• It terminates with a final hash value and a Bitcoin block height. The final value is the Merkle root the proof claims is committed in that block.

What the verifier concludes:

• If the final hash value matches the Merkle root the indicated Bitcoin block carries, the proof is sound: the file's fingerprint was incorporated into the aggregated tree, and the chain has committed the root. The verifier reports success and the block height.
• If the final hash value does not match, the proof is unsound: either the file has been altered, the proof has been altered, or the wrong file has been paired with the proof. The verifier reports failure and reports which step diverged.

The verifier is, in operational terms, an interpreter for the OpenTimestamps proof format augmented with a comparison step against a known chain commitment. No other behaviour is undertaken; no telemetry is collected; no network call is issued during the local verification stage beyond what is required, optionally, to fetch the Bitcoin block header against which the final comparison is made.

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 not because it omits anything, but because the format it interprets is small. The Bitcoin commitment mechanism is the heaviest cryptographic primitive in the chain; once one is willing to take that commitment as an input, the remaining work is a few-dozen-step interpreter for a deterministic sequence of standard-library hash calls. The economy of the verifier is the economy of the format the OpenTimestamps specification provides; the office did not invent it and does not claim credit for 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 does not, in its default configuration, call a Bitcoin full node. It accepts the proof's terminal reference to a block and compares the proof-derived Merkle root against a Merkle root the verifier is told corresponds to that block. The correctness of that final comparison depends on the correctness of the block-header value the verifier obtains. A reader who treats that obtained value as authoritative is implicitly trusting whatever source the verifier consulted — typically a public block explorer or a published header — to have reported the chain's actual contents.

For readers requiring stricter assurance, the verifier may be operated against a locally run Bitcoin full node. In that configuration, the verifier obtains the block header directly from a node the reader controls, validated by the reader's node against the proof-of-work chain end to end. The Merkle root the verifier compares against is then derived from a chain the reader has independently audited, and the trust assumption reduces to the reader's confidence in their own node's correctness — the strongest assurance available short of operating the network oneself.

The verifier does not, in either configuration, undertake to opine on the file's authorship, ownership, originality, or means of creation. It opines only on whether the chain attests the file's fingerprint as of the indicated block. 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 a single HTML document with embedded JavaScript and no external dependencies; it may be saved to disk, 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 portion of the trust chain: given the file and the receipt, it derives the file's SHA-256, compares against the hash_hex recorded in the receipt, and confirms that the receipt is in fact about this file. The Python verifier covers the chain-attestation portion: given the receipt and the .ots proof, it executes the proof against a Bitcoin commitment and confirms that the chain attests the fingerprint.

The two together cover the complete trust chain. A reader in possession of both verifiers, the file, and the receipt may establish — without consulting the office and without trusting the office — that the bytes the file contains were attested by the chain at the moment the proof records. A reader in possession of only one of the two verifiers may still establish either the file-to-receipt binding or the chain attestation in isolation; the architecture is decomposable and each component is independently inspectable.

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. 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. 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
• Comparison with C2PA
• github.com/Orphograph/Orphograph
• opentimestamps.org