Skip to content
BlockchainSign
en

RFC 3161 vs Blockchain Timestamping

By Published

RFC 3161 vs Blockchain Timestamping
Photo: Tima Miroshnichenko

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:

  1. You hash your file locally.
  2. You send the hash to a Timestamping Authority as a timestamp request.
  3. The TSA signs a token containing your hash and its own clock reading.
  4. 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:

  1. The hash is written into a transaction on a public blockchain.
  2. 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.

Frequently asked questions

Is RFC 3161 better than blockchain timestamping?
Neither is strictly better; they fail differently. RFC 3161 is older, standardised and widely recognised, but its validity depends on a timestamping authority's certificate chain staying available and trusted, which requires maintenance. A blockchain record depends on no institution but is less formally standardised. For something important, holding both costs very little.
Does an RFC 3161 timestamp expire?
The token does not expire by itself, but the cryptography and certificates behind it age. Long-term validity is normally maintained by archival timestamping — re-timestamping the token before its algorithms or certificate chain become untrustworthy. In practice most people never do this, which is the quiet weakness of the model.
Is a blockchain timestamp eIDAS qualified?
No. A qualified electronic timestamp must come from an audited qualified trust service provider, and a blockchain record does not qualify. Article 41(1) of eIDAS still makes it admissible — an electronic timestamp cannot be denied legal effect merely for being unqualified — but it carries no presumption of accuracy.

Prove your work existed today

Timestamp any file on the Ethereum blockchain and get a tamper-proof, lifetime certificate. Your file never leaves your browser.