You received a Bitcoin-anchored receipt. Here is what that means.

Three things this receipt does prove

The file existed before the recorded date. The 64-character fingerprint shown on the receipt page is a SHA-256 hash, a value that can only be produced from the exact bytes of a specific file. That hash was submitted to a public, distributed timestamping network and committed to a Bitcoin block whose date is fixed by the chain. The file therefore existed, in its present form, by the time that block was mined.

The exact bytes have not changed since. Changing even a single byte of the file changes the SHA-256 hash entirely. If the file you receive today matches the hash on the receipt, it is bit-for-bit identical to the file that was anchored on the recorded date.

The Bitcoin chain confirms it independently. The date is not asserted by the office or by any private database. It is asserted by the Bitcoin block header, which thousands of independent operators worldwide preserve. The office could not have forged or backdated the receipt; the chain would refuse to confirm any such attempt.

Three things this receipt does NOT prove

It does not prove who created the file. A fingerprint binds a file to a date; it does not bind the file to an author. Authorship is established by other means — affidavits, custody records, identifying metadata, witnesses — that lie outside the receipt itself.

It does not prove the file is true. The file may be a photograph, a contract, a report, a transcript, or a spreadsheet; the receipt attests only that the bytes existed on the recorded date. The accuracy of what the file says is a separate question, decided by whoever evaluates the file's contents.

It does not prove the file was lawfully obtained. A receipt records the existence of bytes at a moment; it does not record the chain of custody that produced those bytes, nor the legal authority under which they were collected. Lawfulness of acquisition is a separate question for the relevant forum and counsel.

How to verify it yourself

Step 1 — Look at the receipt page. Click the URL you were given. The page displays the date the fingerprint was anchored, the 64-character SHA-256 fingerprint, and links to public block explorers. Compare the date to your records; compare the fingerprint, if you have the original file, by computing its SHA-256 with any standard tool.

Step 2 — For independent verification. Download the MIT-licensed verifier at /dist/orphograph-verify.zip and follow the README inside. The verifier is a small, self-contained program that recomputes the proof against the Bitcoin chain on your machine. It does not call back to the office.

Step 3 — For a deeper check. The protocol underneath is OpenTimestamps, a public, open standard. The standard OpenTimestamps client can be run against the .ots file linked from the receipt page; instructions are at opentimestamps.org. This step requires a Bitcoin node or a third-party block explorer; the verifier in step 2 is sufficient for most purposes.

Who runs Orphograph

The office is independent. It operates the protocol — the submission interface, the calendar coordination, the receipt-page hosting — but it cannot alter, revoke, or backdate any receipt that has already been issued. The proof lives on the Bitcoin chain, which the office does not control. If the office were to disappear tomorrow, your receipt would still verify against the chain using the MIT-licensed tool described above. The protocol is the instrument; the chain is the trust anchor; the office is the typist.

For lawyers and adjusters

A separate page describes the doctrinal grounding — the rules of evidence governing electronic records, the state and federal electronic-records statutes, and the small but growing body of state-level blockchain-evidence laws that already address cryptographic timestamping by name. See /method/evidence-law.html. The office does not give legal advice; whether the receipt is admissible in any particular proceeding is a question for that proceeding's rules and the parties' counsel.

Questions

Correspondence: [email protected]. Security reports and coordinated disclosure: see /security.html. Current service state and any ongoing incidents: see /status.html.