Reading settings
How does an EU qualified electronic timestamp differ from a blockchain timestamp?
Published 5 November 2026
A qualified electronic timestamp is issued through a qualified trust service under the EU’s eIDAS rules, using an accurate time source linked to Coordinated Universal Time (UTC). It benefits from a legal presumption of accurate date and time and integrity of the linked data. A blockchain timestamp connects a file’s fingerprint to a blockchain record, with verification based on the anchoring protocol and the blockchain’s rules. Depending on its design, the anchoring protocol can also link that record to a user-controlled cryptographic key. The two approaches can complement each other.
What does “qualified” mean?
This answer focuses on the EU’s eIDAS framework. Other jurisdictions have their own rules for timestamping services and evidence, with different requirements and legal effects; the EU’s qualified status should not be assumed to apply elsewhere.
“Qualified” is a defined status under EU law, not a general description of technical quality. A qualified electronic timestamp must meet the eIDAS requirements, including binding the data to an accurate UTC-linked time and being signed or sealed by a qualified trust service provider, or protected by an equivalent method.
The provider and the particular timestamping service must be listed as qualified in an EU national trusted list. A provider offering one qualified service does not automatically make all its products qualified. The European Commission’s trusted-list guidance explains how to check this status.
Similarly, using the standard RFC 3161 timestamp format does not by itself make a timestamp qualified. The format describes how the cryptographic evidence is structured; qualification also depends on the service’s regulatory status and operation.
Where does the time come from?
With a qualified timestamp, the authority binds the file’s fingerprint to a time from an accurate source linked to UTC. The authority signs the resulting evidence, so a reviewer can check who issued it and whether the signed information has been altered.
With a blockchain timestamp, the fingerprint is connected to a transaction or other record according to an anchoring protocol. The meaning and precision of its time depend on the blockchain used. In Bitcoin, blocks arrive about ten minutes apart on average, and their times are supplied by miners subject to protocol limits. This is different from an authority’s UTC-linked clock; it should not be presented as equivalent precision.
For the mechanics of connecting files to that public record, see Bitcoin anchoring.
What difference does qualification make legally?
Under Article 41 of eIDAS, a qualified timestamp benefits from a presumption that its date and time are accurate and that the linked data has integrity. A qualified timestamp issued in one EU Member State is recognised as qualified throughout the EU.
A non-qualified electronic timestamp cannot be denied legal effect or admissibility solely because it is electronic or lacks qualified status. Blockchain anchoring alone does not confer the qualified timestamp’s specific presumptions. Its evidential weight still needs to be assessed in context.
A growing body of case law and legislation supports the use of blockchain records as evidence across different jurisdictions. The working paper Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight, by Bernstein’s co-founders Marco Barulli and Paul Reboh, surveys developments in more than thirty jurisdictions. It distinguishes acceptance of a record as evidence from the weight a court gives it: the applicable rules, the reliability of the proof and the surrounding evidence still matter.
Neither approach automatically establishes authorship, ownership or an IP right. Those are separate questions from whether particular data existed at a given time.
Can the record also link the files to a particular person?
Yes, if the protocol includes that link. An anchoring protocol can bind the file’s fingerprint to a user’s public key. A signature made with the corresponding private key demonstrates control of that key. If the user signs the anchoring record before it is timestamped, the dated evidence also covers that signature.
This adds a connection between the work and the key holder to the evidence of existence. When the key is reliably linked to a person or organisation, that connection can support an authorship or ownership claim alongside development records, agreements and other evidence. It is a feature of the particular protocol, rather than something every blockchain timestamp provides.
For example, OpenTimestamps provides proof that data existed before a certain time, but its timestamp proof does not itself identify the requester or bind the record to an owner’s public key. That attribution must be supplied separately, for example by timestamping a digitally signed document. OpenTimestamps alone therefore does not provide the user-key link described above.
The distinction is between control of the key and possession of the file: signing a fingerprint alone does not prove that the signer had the underlying file at that time, or has retained it continuously since. Nor does it establish that the signer created the work or owns its rights.
A qualified timestamp on a file’s fingerprint alone does not identify the person presenting the file either. It can, however, cover a document already signed by that person. Linking the work to a user and establishing its date are complementary functions that can be combined with either timestamping approach.
Can both be verified independently?
Yes, provided the necessary evidence is available. Independence means being able to check the proof outside the platform that supplied it; it does not mean that both methods rely on the same sources of trust.
For an authority-issued timestamp, the reviewer checks the file’s fingerprint against the timestamp token, verifies the authority’s digital signature and certificate chain, and examines the relevant certificate-status information. Where qualified status matters, the reviewer also checks the service’s status at issuance using trusted-list information. The check relies on the authority’s certified identity and its timekeeping obligations, but need not rely on a “Valid” badge on its website.
For a blockchain timestamp, the reviewer reproduces the connection from the file’s fingerprint to the blockchain record and verifies that record against the chain. This relies on the anchoring protocol, the blockchain’s consensus rules and the blockchain data used for verification.
In either case, keep the complete evidence needed for independent verification, rather than only a screenshot or a link to an online certificate.
Why use both for the same files?
The two records address different needs. A qualified timestamp supplies an authority-attested time with a defined EU legal status. A public-blockchain anchor supplies a separately verifiable record secured by the blockchain’s network.
Their relative evidential weight can also change across jurisdictions. Outside the EU, a qualified timestamp does not automatically carry the presumptions it enjoys under eIDAS. Depending on local rules and the evidence presented, a court could give a well-supported, independently verified Bitcoin anchor greater weight than an EU qualified timestamp. Neither method is universally stronger in court; retaining both provides different grounds on which to establish the dated record.
Sources
- 1.European Parliament and Council. Regulation (EU) No 910/2014 — eIDAS . Articles 41 and 42: legal effects and requirements for electronic timestamps. 23 July 2014. Accessed 5 November 2026
- 2.European Commission. Questions & Answers on Trust Services under the European Digital Identity Regulation . Electronic timestamps: the 2024 revision leaves the existing timestamp provisions unchanged. Accessed 5 November 2026
- 3.European Commission. List of qualified trust service providers in the EU . Qualification of providers and individual services through national trusted lists. Accessed 5 November 2026
- 4.C. Adams, P. Cain, D. Pinkas and R. Zuccherato. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol . Timestamp tokens, message imprints, authority signatures and verification; updated by RFC 5816. August 2001. Accessed 5 November 2026
- 5.Bitcoin Developer Documentation. Block Chain — Reference . Block headers, transaction commitments and miner-supplied time. Accessed 5 November 2026
- 6.Marco Barulli and Paul Reboh. Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight . Working paper, version 3; comparative survey of more than thirty jurisdictions; authors are Bernstein’s co-founders. 1 October 2026. Accessed 5 November 2026
- 7.OpenTimestamps. OpenTimestamps — How it Works . Proof of prior existence and public calendar services that require no registration. Accessed 5 November 2026
