OpenTimestamps — Trusted Timestamping Anchored to Bitcoin
OpenTimestamps is an open standard that anchors arbitrary data to a Bitcoin block via free calendar servers, producing independently re-verifiable proofs.
- OpenTimestamps (OTS) is an open protocol for proving a piece of data existed at a specific point in time.
- Calendar servers aggregate user submissions, commit them to a Bitcoin transaction, and return the proof path.
- Proofs transition from PENDING to UPGRADED once the Bitcoin block headers needed to complete the path are confirmed.
Definition
OpenTimestamps is an open-source protocol and reference implementation for trusted timestamping. A user submits the SHA-256 digest of any data to a public calendar server. The calendar batches many submissions, commits the batch to a Bitcoin transaction, and returns a proof file (.ots) that contains the operations needed to walk from the original digest to a Bitcoin block header. Once the Bitcoin block is confirmed and its header is known, anyone can re-execute the proof and independently confirm the timestamp without trusting the calendar.
Calendar server model
OpenTimestamps separates two roles. Calendar servers (run by independent operators such as alice.btc.calendar.opentimestamps.org and finney.calendar.eternitywall.com) accept digests and commit them to Bitcoin in regular cycles. They are convenience providers, not trust anchors. The actual trust anchor is the Bitcoin block timestamp itself. A submitter typically posts to two or three calendars in parallel so that no single calendar outage can prevent a proof from being upgraded.
PENDING and UPGRADED states
When a digest is first submitted, the returned .ots file is incomplete: it knows how to walk from the digest to a calendar's commitment, but the Bitcoin transaction containing that commitment has not yet been confirmed. NakedPnL stores this proof in PENDING state. Once the Bitcoin transaction is mined and has accumulated confirmations, the proof can be upgraded by querying the calendar for the missing block-header path. NakedPnL stamps this with btcBlockHeight and moves the proof to UPGRADED. If a proof has not been upgraded after roughly 7 days, NakedPnL marks it FAILED so an operator can investigate.
How NakedPnL uses it
Every day at 00:05 UTC, NakedPnL builds a Merkle tree from all trader chain heads (`lib/ots/merkle.ts`) and submits the root to OpenTimestamps calendars (`lib/ots/anchor.ts`). At 00:30 UTC, a second cron job attempts to upgrade any proofs whose Bitcoin transactions have confirmed. The public endpoint `GET /api/verify/[date]` returns the daily root, the calendar proof, and the Bitcoin block height once available. Anyone can re-execute the proof using a standard `ots verify` client without any NakedPnL credentials.
Worked example
# Install the OpenTimestamps client
pip install opentimestamps-client
# Download NakedPnL's daily root and proof for 2026-05-06
curl https://nakedpnl.com/api/verify/2026-05-06 -o root.txt
curl https://nakedpnl.com/api/verify/2026-05-06.ots -o root.ots
# Re-verify against Bitcoin (requires either a Bitcoin node or a public block explorer)
ots verify root.ots
# Output: Success! Bitcoin block 829,431 attests existence as of 2026-05-06 00:08:14 UTCRelated terms
- Bitcoin timestamp — the trusted clock that OpenTimestamps proofs ultimately resolve to.
- Merkle tree — what NakedPnL submits to OTS once per day.
- Hash chain — per-trader history whose head feeds into the daily Merkle leaf set.
- SHA-256 — the digest function used for both OTS submissions and the Merkle tree.