Blockchain timestamping for software teams
By BlockchainSignLast updated
Version control gives you a detailed history and a weak date. Commit timestamps are written by your machine and a rebase will produce any history you like. For anything that might be evidence, that is a problem worth ten dollars.
The gap in your existing history
Git records a great deal, accurately, for engineering purposes. As evidence it has one specific weakness: the dates are yours to write.
git commit --date, an interactive rebase, a clock change — any of these produce a history that looks entirely ordinary and says whatever you want. That is fine internally. Against a motivated opponent it is not much of a claim, and the same weakness cuts against you when you are the one defending.
A hosted repository's own timestamps are better, but they belong to a platform, they can be lost with an account, and they are not independently verifiable by someone outside it.
What to anchor
Releases. The hash of a release archive or a repository bundle, timestamped at each release. That gives a dated, tamper-evident record of exactly what shipped, which is useful in an infringement claim and equally useful in defending one — proving your version predates the code you are accused of copying is the same operation in reverse.
Pre-disclosure states. Before code goes to a client, an auditor, an acquirer or an escrow agent. The hash is computed in your browser and only the hash is transmitted, which matters when the code is the trade secret — see trademark vs copyright for source code for why secrecy is often the protection actually doing the work.
Design and architecture documents. Frequently the most valuable and least protected artefacts a team holds.
Data snapshots. Where you need to show a dataset was in a particular state at a particular time.
How to do it in practice
Hash the artefact, not the working tree. The reliable pattern is a deterministic archive:
git archiveorgit bundlefor a repository state- A build artefact for a release
- A tarball for a directory, with reproducible ordering if you want the hash repeatable
Then timestamp that file. Store the certificate with the release, and note the tag it corresponds to. Anyone can later re-create the archive, hash it, and compare against the ledger.
Why nothing is uploaded
For proprietary code the confidentiality requirement is absolute, and a timestamping service that wants the file is a service you cannot use.
Here the file is hashed in your browser with the Web Crypto API and only the 64-character SHA-256 hash is transmitted. There is no endpoint that accepts the artefact. If you would rather generate the hash yourself, the free hash tool does it locally, and it produces byte-identical output to shasum -a 256.
What it proves
That the artefact existed by that time and has not changed. It does not prove who wrote it, it is not a patent, and it does not register copyright — see proof of existence vs proof of authorship.
Copyright in your code arises automatically. What you usually lack is an unimpeachable date, and that is the specific gap this fills.