How to prove a piece of code existed before a competitor's commit.

Why the commit date is not enough

A commit's author date is a field in the commit object. The field is editable. A repository's history can be rewritten, force-pushed, rebased onto an earlier base, or constructed from scratch with arbitrary dates. A hosting provider's "pushed at" timestamp is more credible because the provider records it, but it depends on the provider being trusted by the disputing party — and the provider's records being available, intact, and admissible when the dispute arises, sometimes years later.

A defensible date of record needs three things the commit date does not provide on its own: cryptographic binding to the byte-exact state of the tree, anchoring outside any party's control, and verifiability that does not depend on a hosting provider remaining cooperative. The architectural treatment of those properties is at /blog/what-makes-a-digital-timestamp-legally-defensible.html.

What you do

• Produce a single file from the tree. The simplest form is a reproducible archive — for example, git archive --format=tar.gz HEAD > snapshot.tar.gz, or a tarball of the working tree with deterministic ordering. Any byte-stable single-file representation works. A commit hash itself is also a valid input: the SHA-1 or SHA-256 of a commit binds to the entire reachable history.
• Drop the file at orphograph.com. The browser computes the SHA-256 fingerprint locally. The archive's contents never leave the device. Only the sixty-four-character fingerprint is submitted.
• Save the receipt. The receipt is a sixteen-character ID, a public URL of the form orphograph.com/r/<id>, and five small .ots proof files from five independent calendars. Commit the receipt into the repository, or keep it in the engineering matter folder alongside the archive.

Within about an hour the fingerprint is committed to a Bitcoin block. From that block forward, the receipt is evidence that a tree with this exact fingerprint existed by no later than the block's mined timestamp.

Three useful cadences

Per-milestone

Anchor the tree at each tagged release, internal milestone, or major feature branch merge. This is the lightest discipline and the most common configuration. It establishes the byte-exact state of the codebase at a small set of high-signal moments. For most priority disputes that touches the dispute window, a milestone anchor is enough.

Per-day

Anchor the head of the default branch once per day, via a CI job that produces the archive, computes the fingerprint, and submits it. The result is a chain of daily artifacts that traces the actual development inside the dispute window. A counterparty who later argues a feature was added after their commit must reconcile the daily anchors that show it present before.

Per-commit, for the disputed area

In active dispute or where IP priority is core to the product, anchor on every commit that touches the relevant subtree. The resulting density of evidence makes any "this code did not exist until later" argument expensive to mount and easy to disprove.

What the receipt actually establishes

The receipt proves one specific, narrow fact: a file with this exact SHA-256 fingerprint existed on or before Bitcoin block N.

For a source tree, that fact converts the priority question into mechanical verification. Either the archive in the engineer's possession hashes to the recorded fingerprint or it does not. Either the block was mined before the competitor's commit or it was not. Both questions are answered against the public chain without trusting either party.

The verification path

• Produce the archive the same way it was produced at anchoring time. Reproducibility matters here — sort file entries, fix the modification times, and pin the compression level so the byte sequence is stable.
• Hash the archive with any SHA-256 tool. The fingerprint must match the receipt.
• Check the .ots proof files against any copy of the Bitcoin chain. The proof reveals a specific block height and its mined timestamp.
• Confirm the block was mined before the competitor's commit date.

A reference verifier under MIT is at /method/the-mit-verifier-annotated.html. It runs offline once the chain is local. The office is not in the verification loop.

Practical notes

Anchor the archive, not the working directory

A working directory has unstable byte order, untracked files, swap files, and editor temp files. Anchor the output of a deterministic archive command instead. The fingerprint must be reproducible by a verifier given the same source state.

Keep the archive, not just the receipt

The receipt fixes the date for whatever file was anchored. If the archive is lost, the receipt is unverifiable — there is no file left to hash. Treat the archive as evidence and back it up alongside the receipt.

Anchor the dependency snapshot too

A priority dispute often hinges on which version of a third-party library was in use. Lockfiles record those versions; anchoring the lockfile alongside the source tree pins that fact at the same moment.

Folder-mode for engineering organisations

Standing Order accounts can anchor a folder of receipts continuously, producing a daily merkle root that fixes the state of every tracked archive in a single chain entry. The mechanism is described at /method/folder-merkle.html.

What it cannot do

• It cannot prove the engineer wrote the code rather than copying it. The receipt fixes the bytes at a date; provenance of those bytes is a separate evidentiary question.
• It cannot prove the code is original work. A receipt anchored on a fork of someone else's project still records a real fingerprint at a real time — it just records prior art, not creation.
• It cannot reach back. A receipt anchored today fixes today, not the date the code was first typed. Anchor early and on a cadence; the office cannot supply a date that pre-dates the receipt.

Try it

Open orphograph.com. Drop a tarball of the current tree. Save the receipt into the repository. The codebase now has a defensible date of record, and any later argument about when a feature came into being can be answered with a fingerprint and a block height rather than a chain-of-trust dispute over a hosting provider's logs.