New · transparency log
Time evidence
Our server clock is on the record every minute: time source, GPS lock, error bound, fallback to backup sources and offset against independent laboratories. Every entry is signed, added to a Merkle tree and, every 10 minutes, timestamped by Roughtime servers independent of us; it cannot be changed afterwards. Query any past moment below, verify it and download the evidence bundle.
Query a moment
verification runs in your browserPick a date and time (UTC). Your browser finds that minute’s entry, verifies the Ed25519 signature of the first external anchor checkpoint covering it, builds the Merkle inclusion proof itself from the published tiles and shows the result. You do not have to trust us: the computation happens on your device.
The downloaded evidence bundle has the same format as the command-line verify.py and verifies without an internet connection. The Roughtime proof itself is verified with verify.py, not in the browser.
How it works
certificate transparency, applied to timeRoughtime tells you the time, signed, but not what our clock was fed by at that moment. This log closes that gap: the health of the clock is recorded every minute. If the source changes, the satellite signal is lost or we fall back, an extra event entry is written.
Security rests on construction, not on trusting us: entries can only be appended, every append changes the tree root, and the root is timestamped by independent servers outside. Changing even one entry afterwards contradicts proofs signed by others.
- 01Record
One state entry every minute; an extra event entry when the state changes.
ETSI EN 319 421 - 02Merkle tree
Each entry carries the hash of the previous one and is a leaf of an RFC 6962 tree.
RFC 6962 - 03Signature
The tree root is published every minute as a checkpoint signed with Ed25519.
C2SP checkpoint - 04Tiles
The tree is published as static 256-hash tiles; anyone can build an inclusion proof.
C2SP tlog-tiles - 05External anchor
Every 10 minutes the checkpoint is timestamped, in two passes, by three independent Roughtime operators.
Roughtime
Standards and how they map
what regulators ask for, and the cryptographic constructionNo single standard defines this. We combined the relevant parts of the following.
| Standard | What it asks for | In this log |
|---|---|---|
| ETSI EN 319 421 | Time-stamping authorities: UTC synchronisation and loss-of-synchronisation events must be logged | A state entry every minute + separate event entries |
| MiFID II RTS 25, (EU) 2025/1155 | Documented traceability to UTC, continuous record of divergence, annual review | Error bound, source and offsets to independent sources; kept indefinitely |
| RFC 6962 / RFC 9162 | Certificate Transparency: append-only, verifiable Merkle log | The same tree and inclusion proofs |
| C2SP tlog-checkpoint, tlog-tiles | Signed checkpoint and static tile format | Exactly; tested against Go sumdb/tlog |
| Roughtime | Signed, chainable time; proof that a server lied | Independent external witnesses |
Entry fields
in English for international useEvery entry is canonical JSON (sorted keys, no whitespace). Examples in latest.json and /timelog/records/DAY.jsonl.
| Field | Meaning | Values |
|---|---|---|
clock_state | State of the clock | gnss_locked · holdover · network_backup · unsynchronised |
holdover | Free-running without satellites | start, duration and estimated error from the measured 3 µs/hour drift |
tracking.error_bound_s | Maximum clock error | |system_time_offset| + root_dispersion + root_delay / 2 |
tracking.* | chrony tracking values | reference, stratum, offsets, frequency, leap status |
pps | Pulse per second | selected, reach, last reception, offset |
gnss | Satellite receiver | fix, satellite counts, HDOP, constellations; osnma: not supported by the receiver |
backup_active | Fallen back to network sources | true / false |
cross_check | Offsets to independent stratum-1 sources | UME, PTB, Netnod, INRIM, CZ.NIC, RIPE NCC, Time.nl |
events[].kind | Event type | log_started, outage, state_repaired, clock_state_changed, reference_changed… |
seq, prev | Sequence number, SHA-256 of the previous entry | gapless chain |
Verifying from the command line
the whole log or a single momentverify.py is an independent tool: it downloads the log and checks signatures, the chain, the Merkle root, external anchors and Roughtime proofs on your machine. Roughtime proofs need roughtime-stamp (installation).
Verify the whole log
curl -sO https://ntp.alastyr.com/timelog/verify.py
pip install cryptography
python3 verify.pyThe entry at a given moment
python3 verify.py --at 2026-09-24T16:30:00ZCreate an evidence bundle
python3 verify.py --bundle 2026-09-24T16:30:00Z \
-o evidence.jsonVerify the bundle offline
python3 verify.py --verify-bundle evidence.jsonConfirm the verifier key from this page and other channels, not from the server: ntp.alastyr.com/timelog+cb0bb9d1+AVE7wZiELg0QMVE6AplpKfH8Jl/UAftuIIq9ch2dnyYA
| Index | index.json | start, list of days, format definition, latest anchor |
| Checkpoint | checkpoint | signed root, every minute |
| Records | records/DAY.jsonl | older days .jsonl.gz; kept indefinitely |
| Tiles | tile/<L>/<N>, tile/entries/<N> | C2SP tlog-tiles |
| External anchors | anchors/DAY/ | checkpoint + Roughtime proof · witness list |
| Tool | verify.py | Python 3 + cryptography |
Limits
to be honestIt is self-reported
An entry carries our clock’s state as we measure it. Independent support comes from offsets to independent laboratories.
Anchors prove time
An external anchor proves when an entry was written and that it has not changed, not that its content is true.
The signing key is online
It signs every minute. If stolen, only later entries could be forged; the anchored past cannot change.
No OSNMA
Our GNSS receiver does not support Galileo signal authentication yet; entries state this explicitly.
Not a calibration certificate
Not an ISO 17025 calibration or UTC(k) traceability certificate; traceability is via GNSS.
Single antenna
It relies on one GNSS receiver; on loss it falls back to stratum-1 network sources and records that.
Frequently asked questions
6 questionsWhat is this log for?
When you later have to defend the timestamp of an event, it shows whether the time source you relied on was itself trustworthy at that moment. If your systems take their time from ntp.alastyr.com or compare against it, the answers to "was Alastyr's clock locked to GPS at that second, what was its error bound, had it fallen back to network sources?" are here, signed and impossible to change afterwards.
What is an evidence bundle and where is it used?
A single JSON file for a given moment: that minute's entry, a Merkle inclusion proof showing the entry is part
of a signed checkpoint, the checkpoint itself, and the timestamp independent Roughtime servers gave that
checkpoint. You can embed it as-is in your own event record, audit file or evidence object; years later it
verifies offline with verify.py --verify-bundle.
Does it prove your clock was right?
An entry carries our clock's state as we measure it; the external anchor proves when the entry was written and that it has not changed since. Independent support for the content comes from the offsets, recorded in every entry, against eleven independent stratum-1 servers (TÜBİTAK UME, PTB, Netnod and others).
Does it also prove the time I received over NTS?
Not directly. NTS uses symmetric session keys; it proves the reply came from us only to the client that made the measurement. To make your own measurement provable, timestamp a hash of your measurement record with at least three independent operators using Roughtime, and take our clock's state for that minute from this log.
What if the log is ever interrupted?
Gaps are not hidden: if the server or the logging service stops, the first entry after the restart is an
outage event stating how long there were no records. If the satellite signal is lost, entries move to
holdover, then after 10 minutes to network_backup, and each transition is recorded as its own event.
Why these standards instead of your own format?
Certificate Transparency, Sigstore and the Go module database use the same construction: an RFC 6962 Merkle tree,
a C2SP signed checkpoint and tlog-tiles. So our log can be read and verified with that ecosystem's existing tools;
we tested our tiles against Go's official sumdb/tlog library.