How to prove a contract existed before a date.
Contract disputes frequently turn on a single question of time. Did the master service agreement exist before the work was performed. Did the side letter exist before the closing. Did the indemnity clause exist before the loss. The office's method does not adjudicate any of those questions, but it does fix the one fact a disputing party most often cannot establish on its own: the document in its present byte-exact form existed on or before a specific Bitcoin block.
The problem
Filenames lie. Document metadata can be edited. The "last modified" field on a file system reflects the file system, not the contract. A printout's date is whatever the person at the printer types. Email headers can be reconstructed. None of those signals survive a serious challenge from a counterparty who has a financial reason to argue the contract was drafted after the dispute arose.
The conventional fix is to send the document to a third party — a lawyer, an escrow agent, a recording office — and let the third party's records do the work. That is useful and remains useful. It also creates a single point of failure: if the third party loses its records, closes its business, or is itself a party to the dispute, the date of record evaporates.
What the method establishes
The office issues a receipt that proves one specific, narrow fact: a file with this exact SHA-256 fingerprint existed on or before Bitcoin block N. The fingerprint is sixty-four characters; the block has a published timestamp; the chain has a sixteen-year track record without a reorganization past about six blocks.
For a contract, that fact is usually enough to convert a date dispute into a math dispute, and the math is settled. Either the counterparty's copy of the contract hashes to the recorded fingerprint or it does not. Either the block was mined before the date in question or it was not. There is no room for argument about either of those two facts.
The receipt does not prove the contract was signed, that the parties had capacity, that consideration was exchanged, or that the document is enforceable. Those questions are litigated on their own evidence. The receipt only proves the contract existed in its present byte-exact form by a specific date.
What you do
- Save the final contract as a single file — typically the executed PDF, but the method does not care about format. Word, plain text, scanned image, even a zip of the contract and its exhibits — anything that reduces to a stable byte sequence works.
- Drop the file at orphograph.com. The browser computes the SHA-256 fingerprint locally; the contract's contents never leave the device. Only the sixty-four-character fingerprint is submitted to the calendars.
- Save the receipt. The receipt consists of a sixteen-character ID, a public URL of the form
orphograph.com/r/<id>, and five small.otsproof files from five independent calendars. Keep them in the matter file alongside the executed contract.
The fingerprint is committed to a Bitcoin block within about an hour. From that block forward, the receipt is evidence that the contract existed by no later than that block's mined timestamp.
Where this matters most
The "did this clause exist before the event" dispute
A counterparty asserts a clause was added after a triggering event — a default, a sale, a regulatory inquiry. The receipt fixes the contract's byte-exact form on a date before the event. The clause either appears in that version or it does not, and the question is settled without a hearing on credibility.
The "the contract was never finalized" dispute
A counterparty argues that the version produced in litigation is not the version the parties agreed to. The contemporaneously anchored version — its fingerprint recorded at finalization — fixes a specific byte sequence as the operative one. Any later substitution will hash to a different fingerprint, and the substitution will be visible.
The "we signed an earlier version" dispute
Multiple drafts are common; arguments about which draft was the final one are also common. A receipt anchored at signing fixes the version. Anchoring earlier drafts as they are exchanged produces a chain of dated artifacts that traces the actual negotiation from the inside.
The verification path
A counterparty, court, arbitrator, or auditor needs no account, no API key, and no trust in the office to verify the receipt. The verification path is:
- Hash the contract again with any SHA-256 tool. The fingerprint must match the one recorded on the receipt.
- Check the
.otsproof files against any copy of the Bitcoin chain. The proof reveals a specific block height and timestamp. - Confirm that block height was mined on or before the date being claimed.
A reference verifier is published under MIT at /method/the-mit-verifier-annotated.html. Any party in any jurisdiction can run it. The office is not required to be present, reachable, or in business for verification to succeed.
What it cannot do
- It cannot prove who drafted, signed, or delivered the contract. Those questions are answered by the document itself, by witnesses, and by surrounding correspondence.
- It cannot make an unenforceable contract enforceable. Statute of frauds, capacity, formality, choice-of-law, and the rest are unaffected.
- It cannot detect that a counterparty has anchored a fabricated document. Anyone can anchor any file. Authorship is separate from existence. The receipt establishes that a file existed by a date — not that the file is genuine, accurate, or yours.
What survives the office
Receipts are verifiable through OpenTimestamps, the open public standard the office uses underneath, against any copy of the Bitcoin chain. The receipt is the artifact. The office is the convenience. The artifact outlives the office by design.
Try it
Open orphograph.com. Drop the executed contract. Save the receipt to the matter file. The date of record is now fixed, and a counterparty's later claim about when the document came into being can be answered with a fingerprint and a block height rather than a credibility argument.
Disclaimer. Proof of existence is not a legal opinion. A receipt establishes that a specific byte sequence existed by a specific Bitcoin block — it is one piece of evidence in a contract dispute, not a determination of enforceability, validity, or breach. Consult counsel for legal advice specific to a matter.
Posted 2026-05-21 · More from the blog
Start here: What this office actually does.