Accurate Time. Provable Timestamps.

What is NTP?

The Network Time Protocol is the internet standard for synchronizing computer clocks. Our Stratum-1 servers are traceable to UTC(NRC) through the National Research Council of Canada’s TimeLink service, giving you time accurate to within a few milliseconds over the public internet.

Why use timestamps.org NTP?

• Traceable to UTC(NRC) via NRC TimeLink — no upstream pool dependency.
• Geographically distributed for low latency.
• Free for everyone: personal devices, servers, IoT fleets.
• Fully compatible with ntpd, chrony, systemd-timesyncd, and Windows Time Service.

Quick Start

# chrony.conf
server pool.timestamps.org iburst

# or with ntpd
server pool.timestamps.org iburst prefer

What is NTS?

Network Time Security (RFC 8915) adds cryptographic authentication and encryption to NTP. An initial TLS 1.3 handshake negotiates keys, and subsequent NTP packets are authenticated with AEAD ciphers. This prevents spoofing, tampering, and replay attacks on your clock.

Why does secure time matter?

• TLS certificate validation depends on accurate clocks.
• DNSSEC signature windows rely on correct time.
• Log correlation and forensics break when clocks are wrong.
• Kerberos and TOTP authentication are time-sensitive.

Quick Start

# chrony.conf (chrony >= 4.0)
server nts.timestamps.org iburst nts

# Verify NTS is working
chronyc -N authdata

NTS is supported by chrony (>= 4.0) and ntpd-rs. No account or API key is required.

What is OpenTimestamps?

OpenTimestamps (OTS) lets you create a compact cryptographic proof that a piece of data — a document, a commit hash, a snapshot — existed at or before a certain time. Proofs are anchored into the Bitcoin blockchain via Merkle tree aggregation, so verification is trustless and permanent.

How it works

• Submit — Send a SHA-256 hash to our calendar server. Your data never leaves your machine.
• Aggregate — The server collects hashes into a Merkle tree and commits the root to a Bitcoin transaction.
• Verify — Anyone can independently verify your proof against the Bitcoin blockchain, without trusting us.

Quick Start

# Install the client
pip install opentimestamps-client

# Stamp a file
ots stamp document.pdf

# Upgrade a pending stamp (after Bitcoin confirmation)
ots upgrade document.pdf.ots

# Verify a stamp
ots verify document.pdf.ots

Calendar Server

Point your OTS client at our public calendar endpoint:

ots stamp -c https://ots.timestamps.org document.pdf

What are Stamp/Beacon Trees?

Standard Merkle tree timestamping has a fundamental precision problem: only the tip of the tree is timestamped, so every leaf shares the same coarse-grained timestamp regardless of when it was actually received. Stamp/beacon trees solve this by embedding per-leaf timing data directly into the tree structure, achieving precision limited only by network latency.

The protocol was designed by Peter Todd. Unlike trustless schemes such as OpenTimestamps, stamp/beacon trees rely on a trusted notary, but in return they provide per-leaf precision and built-in random beacons.

How it works

Each leaf in a stamp/beacon tree contains four values:

• d_i — The client-submitted digest (your data hash).
• n_i — A nonce chosen by the notary, kept secret until publication.
• s_i — The time delta between a reference time T and when the digest was received.
• p_i — The time delta between T and when the nonce was published to the client.

The notary signs a commitment over the Merkle root, the absolute reference time T, and an uncertainty radius ε. This attests that each digest was received at time T − s_i ± ε and each nonce was published at time T + p_i ± ε.

Two protocols in one

• Stamping — The receipt-time delta s_i proves your data existed at a precise moment, not just "sometime before the tree was built."
• Beacon — The notary attests that each nonce n_i was secret until T + p_i − ε, making it a verifiable random beacon. Clients can use it as a source of randomness that provably did not exist before a known time.

Scalable aggregation

Untrusted aggregation servers can sit between clients and the notary. An aggregation server collects digests from many clients, builds an intermediate Merkle tree, and submits only the tip to the trusted notary. This adds one aggregation interval of latency but allows massive horizontal scaling without requiring trust at every layer. The OpenTimestamps proof format already supports these aggregation layers natively.

Verification

A client receives a Merkle path from their leaf to the tree root, combined with the notary’s signature. This is sufficient to independently verify both the timestamp and the beacon nonce for that leaf, without downloading the full tree.