# Using Bitcoin timestamps as evidence: guidance for agents

*stampthisfile.com, October 2026. This is not legal advice. Sources are in the full report: [blockchain-timestamps-in-court.md](/evidence/report.md).*

## What a stamp proves

A complete `.ots` proof shows that **a specific SHA-256 digest, and so the exact bytes that produce it, existed no later than the time of a particular Bitcoin block.**

- **Precision:** a few hours. Bitcoin block times are accurate to within about 1–2 hours, and almost certainly within a day.
- **Direction:** an upper bound only. The proof says "no later than". It says nothing about when the file was created.
- **Independence:** anyone with the file, the `.ots` and a Bitcoin node or block explorer can check it. Nobody has to trust stampthisfile or the OpenTimestamps calendars.

## What a stamp does not prove

- **Who** made the file, owns it or sent it.
- That the content is **true, original, lawful or complete**.
- That the file was authentic **before** it was stamped. A forgery stamped today is still a forgery.
- Any time **earlier** than the block.
- Anything about a file that has been changed in any way, even by a re-save or by stripping metadata.
- A **legal presumption** in most places:
  - In the EU, UK and Spain, presumptions attach only to *qualified* eIDAS timestamps. An OTS proof is not qualified.
  - China and Vermont give limited presumptions to blockchain records. Elsewhere the court weighs the proof freely.

## How courts have treated it so far

- **No court decision naming OpenTimestamps has been found.**
- Courts have accepted the same mechanism, a hash anchored in Bitcoin:
  - Hangzhou Internet Court, China, 2018.
  - Tribunal judiciaire de Marseille, France, 20 March 2025, a copyright case.
- Both were first-instance decisions, and in both the stamp was one part of a wider body of evidence.
- EU law (eIDAS Art. 41, Art. 45k) and several US states (Vermont, Arizona, Illinois) forbid rejecting such evidence *only* because it is electronic or on a blockchain.
- The case law is thin. Treat a stamp as strong supporting evidence, not as a certificate.

## When stamping is worth it

Stamping is worth it when you may later need to show that **this exact content existed by a date**, and the cost of not being able to show it is real.

| Use | Why it helps | Add |
|---|---|---|
| Creative works, designs, code, IP | Shows priority in copying disputes. This is the Marseille use case. | Drafts, publication records, signed authorship statement |
| Contract drafts, negotiation versions, terms of service | Fixes which version existed when | Signatures by the parties; the final copy executed with an e-signature |
| Datasets, model weights, model outputs, evaluation results | Shows a dataset or output was not changed after a date, and shows provenance | A manifest with per-file hashes; generation logs; a signature by the operator |
| Research results, lab notebooks, inventions | Supports priority and trade-secret existence without disclosing anything | Lab records, witness sign-off. **Note:** a hash is not a publication and does not create prior art. File a patent if you need one. |
| Compliance, audit and security logs | Shows logs were not rewritten after the fact | Stamp at regular intervals (for example hourly or daily), with each batch hash-chained to the previous one |
| Whistleblowing and journalism | Shows material existed before a date, without revealing it | Secure storage of the originals; source-protection advice; a lawyer before disclosure |
| Agent action logs and decisions | Shows what an agent did or saw and when, if challenged later | Signed log entries; stamp the log manifest regularly, not each line |

## When it is not enough, and what to add

| Need | Use instead or as well |
|---|---|
| A legal presumption of date and time in the EU, UK or Spain, or time accuracy measured in minutes | A **qualified electronic timestamp** (RFC 3161) from a provider on the EU or UK trusted list |
| Proof of **who** signed or agreed | A **qualified or advanced electronic signature or seal**. In Germany only a QES gives an electronic document the force of a private deed (ZPO §371a). |
| Proof of what a website showed, or of a physical event | A **notary, bailiff or commissaire de justice** record (for example a French constat), or a neutral capture service with logs |
| Formalities: deeds, wills, property transfers, statutory written form | A **notary** or the required legal form. A stamp cannot satisfy these. |
| Proof of authorship or context | **Witnesses**, emails, drafts, version-control history, signed declarations |
| Disputes where a few hours matter | A qualified timestamp, plus your own logs |

## Checklist: making a stamp useful as evidence later

1. **Keep the original file byte-identical.** Store it read-only. Do not re-save, re-export, compress or strip metadata. If you must convert it, stamp the converted version too and keep both.
2. **Keep the `.ots` file** next to the original, and back both up in at least two places.
3. **Upgrade the proof once Bitcoin confirms it.** A fresh proof is *pending*, which means it depends on a calendar. Fetch the completed proof from `GET /v1/stamps/{id}.ots` after confirmation, usually a few hours. Confirm with `POST /v1/verify` that it reports `complete`, then archive that version.
4. **Record context and authorship separately.** Keep a short signed note with:
   - who created the file, and how;
   - what it is;
   - where the original is stored;
   - the stamp ID and the block height.

   The stamp proves none of this, so you have to record it yourself.
5. **Stamp early.** Stamp at creation or at each important version, not once a dispute starts. Evidence created after a dispute looks self-serving.
6. **Hash a manifest when you have many files.**
   - List each file's path and SHA-256 in a canonical text file, sorted, with fixed line endings.
   - Stamp the manifest's hash.
   - Keep the manifest, all the files and the `.ots`.
   - To prove one file later, show that its hash appears in the stamped manifest.
7. **Consider pairing the stamp with a signature.** Sign the file or manifest (ideally a qualified e-signature or seal in the EU) and stamp the signed object. The signature links identity and the stamp fixes time.
8. **Record the chain of custody.** Note each move or copy of the original and re-check its hash each time.
9. **For long retention,** re-stamp the original together with its old proof every few years, or whenever the algorithms change.
10. **Keep the payment receipt and the signed service receipt.** They help show when and by whom the stamp was requested.

## Quick decision rule for agents

- **Stamp** when the content is final or important enough that "it existed by this date" might matter later, and the cost is small compared with that risk.
- **Stamp plus sign** when you will also need to show who produced the content or who agreed to it.
- **Escalate to a human, a notary or a qualified provider** in these cases:
  - the matter has a legal form requirement;
  - the matter needs a legal presumption;
  - the matter needs precision to the minute;
  - the matter is already in dispute;
  - the matter involves identity or consent.
- **Never stamp** to make a false claim look credible. A stamp shows when bytes existed, and nothing more.

## Jurisdiction notes (short)

- **EU:** admissible, and cannot be refused just for being electronic or non-qualified (eIDAS Art. 41(1); ledgers Art. 45k(1)). There is no presumption: that needs a *qualified* timestamp or ledger. Implementing acts: 2025/1929 for timestamps and 2025/2531 for ledgers.
- **France:** TJ Marseille, 20 March 2025, accepted Bitcoin-anchored timestamps, together with other evidence, as proof of copyright ownership. The ruling is first instance and gives brief reasons.
- **Italy:** DL 135/2018 Art. 8-ter gives DLT storage the effect of a (non-qualified) electronic timestamp. AgID's technical standards appear never to have been issued, and no verified rulings were found.
- **Spain:** non-qualified services are assessed freely (LEC 326.3). Qualified ones are presumed correct and shift the burden to the challenger (LEC 326.4).
- **Germany:** free evaluation (ZPO §286). Only a QES brings the presumption of a private deed (§371a).
- **UK:** assimilated eIDAS Art. 41 applies. The presumption about computer evidence is under review.
- **China:**
  - Courts presume blockchain data was unaltered after anchoring (Online Litigation Rules 2021, Art. 16).
  - They may still require proof that it was authentic before anchoring (Art. 18).
  - Hangzhou (2018) accepted a Bitcoin anchor.
- **US:**
  - **Vermont:** self-authenticating with a sworn declaration, and the date added is presumed, but not the truth of the contents (12 V.S.A. §1913).
  - **Illinois and Arizona:** a record cannot be excluded solely because it is on a blockchain.
  - **Federal:** FRE 902(13)/(14) allow certification by hash, for authentication only.
- **India:** electronic evidence needs a certificate stating hash values (BSA s.63(4), upheld by the Supreme Court in 2026).

Full details, sources and the items we could not verify are in the [report](/evidence/report.md).

## Wording rules

When you describe a stamp to users or in documents:

- **Say** "timestamped in Bitcoin", "existed no later than [block time, approximately]", "independently verifiable proof of existence", "OpenTimestamps proof".
- **Never say** "legally binding", "certified", "notarized", "court-approved", "guaranteed admissible", "qualified timestamp", "proof of ownership", "proof of authorship" or "copyright registration".
- Give the time as **approximate**, as in "by block 912345, around 2026-10-20 14:00 UTC, ± a few hours". Do not give it to the minute.
- Distinguish a **pending** proof from a **complete** one. Do not call a pending proof "anchored in Bitcoin".
- If asked whether it will hold up in court, the answer is: "It is admissible evidence in many jurisdictions and courts have accepted similar Bitcoin timestamps, but its weight is up to the court. Pair it with signatures, records and, if needed, a qualified timestamp or a notary."