Overview

OpenTimestamps is an open standard and set of tools for blockchain timestamping, created by Peter Todd. It defines a portable format for provable timestamps that demonstrate a piece of data existed at or before a given point in time. Users hash their data locally, submit only the digest to public “calendar” servers, and receive a proof file (extension .ots) that ultimately commits the digest to the Bitcoin blockchain. Because only the hash leaves the user’s machine, the underlying document stays private while still gaining an independently verifiable timestamp. OpenTimestamps is deliberately narrow: it is a trust-minimized proof-of-existence primitive, not a records service, and it says so plainly (“It does not establish authorship, ownership, or digitally sign documents”).

Key points

• Standard format: OpenTimestamps specifies a portable proof format (.ots files) describing the chain of cryptographic operations from a data hash up to a Bitcoin transaction, so proofs can be verified by independent implementations.
• Calendar servers: Free public calendar servers (for example Alice, Bob, Finney, Catallaxy) accept timestamp requests with no registration or API keys, batch many requests together, and pay the Bitcoin transaction fees on behalf of all users.
• Aggregation via Merkle trees: Calendar servers combine large numbers of user digests into a single Merkle tree and commit one Merkle root per Bitcoin transaction, amortizing cost across the whole batch (famously, hundreds of millions of Internet Archive files under one transaction).
• Client-side hashing for privacy: The digest is computed locally and further protected with a nonce, so the calendar sees only an opaque value and raw data is never transmitted or recorded on-chain.
• Pending then complete: a calendar returns an “incomplete” proof in about a second; the proof must later be upgraded (via a calendar) once the Bitcoin transaction confirms, after which it is fully self-contained and calendar-independent.
• Independent verification: A completed proof is checked by replaying its hash operations and confirming the committed root appears in a real Bitcoin block, read from Bitcoin block headers (a local node, or a block explorer for convenience), without trusting the calendar server.
• Open and durable: reference libraries and a CLI exist in Python, JavaScript, Java, and Rust, the project is open source, and the client commits to permanent backward compatibility so old proofs always remain verifiable.

Truestamp compared to OpenTimestamps

OpenTimestamps and Truestamp sit at two different points in the proof-of-existence design space, and each is one entry in a long line of provenance and timestamping methods. OpenTimestamps is a minimal primitive whose entire proof reduces to Bitcoin: a bare hash, one Merkle root per block, nothing else. Truestamp is a fuller records service that proves more per item and integrates deeper, at the cost of more moving parts and a hosted service, while keeping the underlying proof independently verifiable against the public chains. The table contrasts the feature sets.

Where OpenTimestamps is stronger: its radical simplicity is a feature. A completed .ots proof depends on nothing but Bitcoin, with no signature and so no signing key to reason about, and no account is needed even to create a timestamp. It is free, permissionless, maximally private (the network never sees more than an opaque digest), and a widely adopted open standard with a durability commitment. For a use case that needs only “this exact bytes existed before time T,” verified against Bitcoin alone, OpenTimestamps is hard to beat.

Where Truestamp does more: it proves a bounded interval rather than a one-sided instant, signs every artifact and ties it to a published keyring, carries a structured claims and metadata layer with reversible redaction (and can embed the provable data itself in claims-only mode, so there is no separate original file to keep alongside the proof), commits to two independent public chains, folds in external entropy with graded verification, adds team collaboration and per-item private, team, or public visibility, and ships a self-contained signed bundle that verifies fully offline without a Bitcoin node, all behind first-class developer APIs and a managed item lifecycle. Those capabilities are the point of a records product and are simply out of scope for OpenTimestamps.

On developer and user ergonomics the gap is wide, and it is not incidental. OpenTimestamps deliberately ships a protocol, not a product: its calendar server (otsd) is roughly 1,400 lines of Python exposing an unauthenticated HTTP surface with two working verbs, POST /digest and GET /timestamp, whose payloads are OpenTimestamps binary rather than JSON, so a client must link an OTS library to build a request or read a proof. There is no OpenAPI or endpoint reference, no JSON or GraphQL data API (only an operational status page), no accounts or rate limiting, and no interface beyond a basic in-browser stamp-and-verify page. Truestamp instead treats those surfaces as the product: a web app and public explorer, a CLI, an in-app AI chat, an MCP server, a documented JSON:API (OpenAPI, Swagger, ReDoc), an introspectable GraphQL with a playground, outgoing webhooks, and a console stream, all authenticated. For a developer wiring timestamping into an application, or a non-technical user who just wants to submit and check a proof, that difference in ergonomics is as consequential as any single cryptographic feature.

On trust and durability the two systems are closer than the feature gap suggests. Neither proof requires trusting its provider to verify. An OpenTimestamps .ots checks against Bitcoin alone, and a Truestamp bundle can be checked entirely with local code: recompute every hash and the signature, then match the committed epoch root against the OP_RETURN and memo you read from Bitcoin and Stellar yourself. The repository’s proof Livebook and the open-source Truestamp CLI, which verifies entirely offline with no account, do exactly this, so the verification code itself is auditable and the published keyring and hosted verification endpoints are conveniences a verifier may ignore, not a trust dependency. Durability is close for a proof you have downloaded: in both systems the proof stays verifiable against the public chains indefinitely, so keeping your own copy is the durable move. What differs is what that copy must contain. An OpenTimestamps proof commits only a digest, so you must also retain the exact original file, byte for byte, to prove anything about its contents, whereas a Truestamp claims-only submission embeds the provable data in the bundle itself, so the single downloaded proof is self-sufficient and there is no separate pristine snapshot to keep in sync (a hash-mode Truestamp proof, like an .ots, still needs the original file). The other service-side difference is re-fetching. OpenTimestamps has no account, so you always hold the file (though a pending proof depends on a calendar until it is upgraded), whereas Truestamp retains the item so you can re-download or regenerate a proof for 90 days on the Free tier and without limit on paid tiers. It is also worth noting the two projects’ development cadence. OpenTimestamps’ reference tooling is now feature-frozen and only lightly maintained: its last genuinely new capability landed years ago, recent commits are dependency, fee, and CI upkeep, and several of its language ports are dormant. Because a completed proof depends only on Bitcoin, that dormancy does not threaten proofs you already hold, but it does mean the format’s capabilities are effectively fixed, whereas Truestamp is under active development. These remain different products for different needs, which is why more than one approach to proving existence has always coexisted.

Citations

1. OpenTimestamps. Open standard for Bitcoin blockchain timestamping, originated by Peter Todd; primary source for the design, calendars, and privacy model.
2. OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin. Peter Todd, 2016. Design rationale, calendar aggregation, and the explicit scope limits (authorship and signatures are out of scope).
3. opentimestamps-client. Reference CLI: the stamp, upgrade, and verify commands, the Bitcoin-node verification requirement, and the backward-compatibility commitment.
4. opentimestamps-server. The calendar server (otsd): the unauthenticated two-verb HTTP protocol, OpenTimestamps binary payloads, and the absence of a documented API or accounts.