The core value of OpenTimestamps is simple: it proves that a certain file already existed before a certain point in time. It does not prove the content is true, does not prove who wrote the file, and does not prove the file has not been modified. It only answers one question: "What is the earliest possible time this file could have existed?"
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Once you understand this, the operations and verification logic become much clearer.
Stamping: Only the Hash Is Sent, Not the File
The OpenTimestamps protocol is designed to submit only the SHA-256 hash of your file to a calendar server. The original file never leaves your device. This makes it safer than many services that require you to upload the whole file to a website for timestamping.
To use it, the official client opentimestamps-client can do this with a single command:
ots stamp yourfile.pdf
After running this, a file named yourfile.pdf.ots is created. This .ots file is your timestamp proof. You need to keep it together with your original file, as both are required for verification.
From the output of ots stamp, you will see that it submits to multiple calendar servers (usually public ones like alice, bob, and finney). This is a redundancy design: as long as at least one calendar server eventually anchors the hash to the Bitcoin blockchain, the proof can be completed.
About "Pending": It Is Not a Failure
Immediately after running ots stamp, the .ots file only contains a pending attestation from the calendar server. It does not yet have confirmation from the Bitcoin blockchain.
Bitcoin block confirmation usually takes 10 to 60 minutes, and can extend to several hours if the network is congested. During this window, ots verify will tell you "Pending confirmation in Bitcoin blockchain". This is normal, not a failure.
If you need a complete, independently verifiable proof, you need to run:
ots upgrade yourfile.pdf.ots
upgrade queries the calendar server to see if the hash has been confirmed. If it has, the path information to the Bitcoin block is written into the .ots file itself. An upgraded proof no longer depends on the calendar server being online and can be verified offline using a local block header.
Verification: Requires a Local Blockchain Node
This is where OpenTimestamps often trips people up: the official client requires a local Bitcoin Core node for verification (a pruned node also works).
If you do not have a local node, ots verify will try to complete verification through a public block explorer. This path works, but the trust assumption changes: you are trusting the data returned by the block explorer, not the consensus of the Bitcoin network itself.
So the complete verification path is:
Upgrade as soon as possible after stamping: Do not leave your proof in a pending state forever.
Keep the
.otsfile: An upgraded.otsis self-contained and includes the complete cryptographic path from your file hash to the Bitcoin block.Verify with a local node (recommended): Run Bitcoin Core, then execute
ots verify yourfile.pdf.ots. The client will directly query your local block header and will not rely on any third party.Check the verification output: A successful output will clearly show "Bitcoin block XXXXXX attests existence as of [date]".
If the .ots is still pending, ots verify will try to upgrade it automatically; if the upgrade succeeds, it will continue to verify. If the calendar server has shut down or is no longer responding, a pending proof cannot be upgraded and verification cannot be completed. This is a real risk of relying on calendar servers.
A Privacy Detail That Is Easy to Overlook
The web-based tool on opentimestamps.org asks you to drag and drop your file into the browser. Although its JavaScript does calculate the hash locally and does not upload the file, the website itself could silently change its behavior—you cannot tell from the outside whether it is really not uploading your file.
For sensitive files, a more reliable approach is to calculate the SHA-256 hash locally and submit only the hash value to the calendar server. Some tools (like istampit-cli) support a --hash parameter that directly accepts a pre-computed SHA-256 digest, completely avoiding contact with the original file. The protocol itself never requires submitting the original file. The web version's "drag and drop" is just a convenience, not a necessary step.
Determine Which Situation You Are In
If you just need to prove the existence time of an ordinary file: Use the official CLI or a trusted local tool, upgrade the .ots file, and keep the original file and the .ots together. When verifying, use a local node if you have one; otherwise, use a public block explorer and accept the trust assumption.
If you are dealing with sensitive files: Do not use the web version to drag and drop files. Calculate the SHA-256 locally and use a tool that supports the --hash parameter to submit the hash, ensuring that not a single byte of the original file leaves your device.
If you need a long-term verifiable proof: Make sure the .ots file has been upgraded to include the Bitcoin block path. A pending .ots cannot be completed once the calendar server goes offline. An upgraded .ots can be verified independently without the calendar server.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- PyPI·istampit-cli — Blockchain Timestamp Verification (OpenTimestamps), page published or updated: 2025-08-15; checked: 2026-10-14.
- NPM·@otskit/mcp, page published or updated: 2026-09-05; checked: 2026-10-14.
- PyPI·git-ots, page published or updated: 2026-09-15; checked: 2026-10-14.
- NPM·zeitstempel, page published or updated: 2026-08-20; checked: 2026-10-14.
- GitHub·opentimestamps/opentimestamps-client, page published or updated: 2026-02-06; checked: 2026-10-14.
- Politecnico di Milano·Thesis on OpenTimestamps, page undated; checked: 2026-10-14.
- NPM·@otskit/core, page published or updated: 2026-06-09; checked: 2026-10-14.
