RFC 3161 vs Blockchain Timestamping
By BlockchainSignPublished

There are two credible ways to prove a file existed at a moment in time, and they rest on completely different foundations. One trusts an organisation. The other trusts a ledger.
Neither is simply better, and anyone telling you otherwise is selling something.
What RFC 3161 does
RFC 3161 is the internet standard for trusted timestamping, published in 2001 and in continuous use since. The flow is simple:
- You hash your file locally.
- You send the hash to a Timestamping Authority as a timestamp request.
- The TSA signs a token containing your hash and its own clock reading.
- You keep the token alongside the file.
The file never travels — only the hash — which is the same privacy property a good blockchain service has. Verification is done with openssl and the TSA's certificate chain.
The token is valid because a trusted third party signed it. That is the whole model, and it is a sound one: it is standardised, widely understood, recognised by technical experts and courts, and often free.
What blockchain timestamping does
The first two steps are identical. Then it diverges:
- The hash is written into a transaction on a public blockchain.
- The transaction is confirmed and becomes part of an append-only ledger.
The record is valid because it is in a chain that no single party controls and anyone can read. There is no signature to trust and no authority in the loop.
Where each one breaks
This is the useful comparison, because both work fine when nothing goes wrong.
RFC 3161 fails at the authority. The token depends on the TSA's certificate chain remaining available and trusted. Certificates expire. Authorities shut down — WIPO closed its own timestamping service in 2022. Long-term validity requires either archival timestamping (re-timestamping before algorithms and certificates age out) or an authority that outlives your need. That is a maintenance obligation, and most people never perform it.
Blockchain fails at the chain. The record depends on the ledger continuing to exist and remain readable. For Bitcoin and Ethereum that is a good bet on any horizon you can plan for, but it is a bet on infrastructure rather than an institution. Aggregated designs add a second failure point: if the proof lives in a separate file you must keep, losing the file loses the timestamp.
| RFC 3161 | Blockchain | |
|---|---|---|
| Trust rests on | A signing authority | A public ledger |
| Standardised | Yes, since 2001 | No |
| File uploaded | No | No |
| Verification tool | openssl and a cert chain | A block explorer |
| Long-term maintenance | Re-timestamping before certs age | None |
| Fails when | The TSA or its chain goes away | The chain stops being readable |
| Cost | Often free | Gas, or a service fee |
| Readable by a non-expert | No | Yes, if written directly |
The eIDAS wrinkle
In the EU there is a third category worth knowing about. A qualified electronic timestamp comes from an audited qualified trust service provider and carries a legal presumption under Article 41(2) of eIDAS as to the accuracy of its date and the integrity of the data.
A qualified timestamp is an RFC 3161 timestamp from a specific kind of provider. An ordinary free TSA is not qualified, and neither is a blockchain record. Article 41(1) says an electronic timestamp cannot be denied legal effect or admissibility merely for being unqualified — so both are admissible, and neither gets the presumption.
If someone has specifically asked you for a qualified timestamp, only a qualified TSA will do. See is a blockchain timestamp valid in court for the wider legal picture.
Which to use
Use RFC 3161 if you want the older, more standardised route, if free matters, if you are automating timestamps into a build or an archive, or if someone has asked for a token in that format.
Use a blockchain record if you would rather not maintain a chain of trust, if a non-technical person will eventually have to verify it, or if you want a record that survives any single organisation disappearing.
Use both if it genuinely matters. They are independent records under different trust models, they cost very little together, and a bad decade for one leaves the other untouched. For anything you would regret losing, that is the honest recommendation.
Whichever you pick, the thing being proven is the same and equally narrow: that a specific file existed by a specific time and has not changed since. Neither proves who made it — see proof of existence vs proof of authorship.