Are blockchain timestamps qualified under eIDAS?
Short answer: no. A timestamp anchored in Bitcoin, Ethereum or any other public blockchain is not a qualified electronic time-stamp under the EU’s eIDAS Regulation, and it cannot become one. It is still valid electronic evidence — a court may not reject it just for being electronic — but it does not get the legal presumption that a qualified time-stamp gets. The rest of this post explains why, what eIDAS 2 changed (less than the headlines suggest), and when each option makes sense.
What eIDAS actually requires
eIDAS defines an electronic time-stamp broadly: data that binds other data to a particular time, establishing evidence that the data existed at that time (Article 3(33)). A blockchain anchor fits that definition. A qualified electronic time-stamp is one that meets Article 42, which requires that it:
- binds the date and time to the data so that undetected changes are reasonably precluded;
- is based on an accurate time source linked to Coordinated Universal Time (UTC);
- is signed with an advanced electronic signature or sealed with an advanced electronic seal of the qualified trust service provider, or an equivalent method.
The first requirement a blockchain arguably meets. The second it does not: a block’s time is whatever the miner wrote into it, within loose consensus rules, not a reading from a UTC-linked clock. The third it cannot meet at all, because there is no qualified trust service provider — no supervised, audited organisation listed on the EU Trusted List — that issues and answers for the stamp. Qualified status belongs to a provider and a service, not to a technology.
What the legal difference is worth
Article 41 sets out the two tiers:
- Any electronic time-stamp “shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp” (41(1)). A blockchain anchor is in this tier.
- A qualified electronic time-stamp “shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and the time are bound” (41(2)), and is recognised as such in every member state (41(3)).
In practice the difference is the burden of proof. With a qualified time-stamp, the date and integrity are presumed; whoever disputes them has to show otherwise. With a blockchain anchor, you have to persuade the court yourself: explain hashing, Merkle proofs and block times, perhaps with an expert, and hope the judge finds it convincing. Often it works. It is never automatic.
Didn’t eIDAS 2 make blockchains official?
eIDAS 2 (Regulation 2024/1183) added a new trust service: electronic ledgers (Articles 45k and 45l). It mirrors the time-stamp rules closely:
- Any electronic ledger may not be denied legal effect or admissibility as evidence solely because it is electronic or not qualified (45k(1)).
- Records in a qualified electronic ledger enjoy a presumption of their unique and accurate sequential chronological ordering and of their integrity (45k(2)).
- And a qualified electronic ledger must be “created and managed by one or more qualified trust service providers” (45l(1)(a)).
So eIDAS 2 opens a qualified route for ledger services run by supervised providers — not for anchoring a hash in a public, permissionless chain that nobody operates. It also creates a separate presumption about ordering and integrity of ledger records; it does not turn ledger entries into qualified electronic time-stamps, which are still defined by Article 42.
Side by side
| Public blockchain anchor | Qualified electronic time-stamp | |
|---|---|---|
| Who issues it | Nobody in particular — miners order transactions into blocks | A qualified trust service provider, supervised by a national body |
| Legal status in the EU | Electronic evidence (Art. 41(1), 45k(1)): admissible, weighed freely by the court | Qualified electronic time-stamp: presumption of accurate time and data integrity in every member state (Art. 41(2)) |
| Time accuracy | Block time is set by the miner; Bitcoin accepts up to about two hours of drift | Linked to UTC, typically to within one second, stated in the token |
| Who has to prove it in court | You: how the anchor works, that the chain is sound, what the block time means | The other side, if they dispute it |
| Lifetime | No certificate to expire — a genuine strength | TSA certificates expire; evidence must be renewed (RFC 4998) to stay verifiable |
| Verification | Any full node or block explorer, plus the proof file | Standard tools (openssl, EU DSS) against the EU Trusted List |
| Cost per stamp | A transaction fee, shared when hashes are batched | Per stamp from the provider, shared when hashes are batched |
When each one makes sense
A blockchain anchor is fine when you mainly need technical tamper-evidence, the audience is technical, and nobody will rely on the date in a dispute — public commitments, open-source release hashes, research data. Its independence from any single company and the absence of certificate expiry are real advantages.
A qualified time-stamp is the right tool when the evidence may end up in front of an auditor, a regulator or a court in the EU: contracts, invoices, records under NIS2, DORA or the AI Act, intellectual-property priority, anything where “prove when this existed” is a legal question rather than a technical one.
Batching without a blockchain
The idea that makes blockchain anchoring cheap — combine many hashes into a Merkle tree and anchor only the root — does not need a blockchain. That is how TrustBeat Document Anchoring works: every ten minutes, all submitted SHA-256 hashes go into one Merkle tree, and its root gets a qualified RFC 3161 time-stamp from an EU qualified trust service provider (SK ID Solutions, with EuroCert as fallback). Each customer receives the token plus the short Merkle path from their hash to the root.
You get the cost profile of batching and the legal status of a qualified time-stamp; your files never leave your systems, and the proof verifies with standard tools — see RFC 3161 timestamps explained and manual verification. The weak spot of qualified time-stamps, certificate expiry, is handled by renewing each proof’s RFC 4998 evidence record before the certificates behind it expire — described in our ETSI TS 119 511 explainer.
The short version
- Blockchain timestamps are electronic time-stamps in the broad sense, and admissible as evidence.
- They are not qualified: no qualified provider signs them, and block time is not UTC-linked.
- Only qualified time-stamps get the EU-wide presumption of accurate time and integrity.
- eIDAS 2 qualified electronic ledgers need a qualified provider to run them — a public chain does not qualify.
- Merkle batching works just as well with qualified time-stamps.
This post explains the regulation; it is not legal advice for your case. If you want a qualified timestamp behind every hash, start free — 100 anchors a month, no card.