Why Timestamp Drafts Not Final Versions
By BlockchainSignPublished
Most people timestamp the finished thing. It is the natural instinct — the final version is the one that matters, so that is the one to protect.
It is the wrong way round, and the reason is worth ten minutes.
A timestamp is an upper bound
A blockchain record establishes that a file existed no later than a particular block. It says nothing about how much earlier it existed.
So the value of any timestamp is set by how early it is. A record from the day you finished proves you had it that day. A record from the first rough draft, six months earlier, proves you had something six months earlier — which is a much more useful claim when the question is who was first.
Timestamping only the final version throws away every month of priority you actually earned.
The sequence argument
The second reason is more interesting than the first.
A single dated file shows possession. Anyone who obtained a copy could produce the same thing.
A sequence of dated files, showing a work changing over months, shows development. Rough to refined, wrong turns and corrections, structure emerging. That is very difficult to fabricate after the fact and essentially impossible for a copyist to produce, because they have the output and nothing behind it.
This is the strongest form of evidence available to an individual creator, and it costs a few dollars per entry.
| One final timestamp | A sequence of drafts | |
|---|---|---|
| Establishes possession | Yes | Yes |
| Establishes how early | Only at the end | From the beginning |
| Shows a process | No | Yes |
| Reproducible by a copyist | Yes | No |
| Survives "you could have copied it" | Weakly | Strongly |
What this looks like in practice
Writing. The first complete draft, each version sent to a reader, the version before a major restructure. Keep the certificates for superseded drafts — the superseded ones are the valuable ones.
Design. Initial concepts, each client presentation, and specifically the routes that were rejected. Rejected work is the most likely to reappear elsewhere and the least likely to exist anywhere else.
Engineering. Concept sketches and early CAD, each significant revision, the state before any external disclosure.
Photography. The RAW, before delivery and before publication. Not the exported JPEG.
Software. Each release, plus the state before code goes to a client or an auditor.
The recurring instruction: timestamp before the moment the work leaves your control, not after.
The cost objection
Timestamping every draft sounds expensive if each certificate is a few dollars and you produce a lot of drafts. Two responses.
You do not need every draft — you need the earliest, and the ones at meaningful transitions. Five or six records over a project's life captures the sequence.
And where volume genuinely is high, batch: put a set of working files into one archive and timestamp the archive. One certificate covers the exact package. The trade-off is that producing one file later means revealing that the others exist, which matters in some contexts and not in most.
The one thing to get right
Keep the exact files, byte for byte.
A hash covers exact bytes. Re-saving a document, re-exporting an image, or rebuilding an archive produces a different file that will not match. Archive each certified version separately and keep working on a copy.
Losing the file is by far the most common way people find their certificate is worth nothing. See how long does a blockchain record last.
What it still will not do
Prove you wrote it. A sequence of drafts is strong circumstantial evidence of authorship and it is not proof of it — see proof of existence vs proof of authorship. What it does is make the alternative explanation considerably harder to advance.