A reading, a bound and outside signatures
What the clock read, how wrong our own model says it could be, and signed outside evidence, each part showing one thing about the time.
Everything on this page came off one receipt that is committed in the repository. It was taken from nine public servers on an ordinary desktop, and you can run the same check on it yourself.
Version 1, 2026-09-10
The three numbers, and why the third one is somebody else's
A receipt that only said what the clock read would be worth what any other timestamp is worth, which is nothing you can check. These three go together or the receipt does not mean anything.
What the clock read
A local counter read at nanosecond resolution, taken at the moment of the event. Through the resident agent that reading has no network call in it, because the clock work happens continuously in the background. The receipt below was taken by the one-shot command instead, which asks the sources in the same few seconds as the stamp. Nanoseconds is the resolution of that read. It is not the accuracy to UTC and the two get confused constantly, which is the confusion this product exists to fix.
How wrong it could be
An interval, not a margin of error on an answer. The reading is a point inside it and the interval is the claim. This is our own number, worked out by our own model on your machine, and it is labelled inside the receipt as our claim rather than as evidence. It is the most precise number in the receipt, and it rests on trusting whoever signed it, as the reading beside it does.
Signed from outside
Signatures from parties who have never heard of this product, carried inside the receipt so a stranger can check them without asking us for anything. Each shows one thing about the time and none of them says when the reading was taken. They do not vouch for the interval above, which is ours, and a bound resting on them is what this is being built towards. Three roles, and none of them does another's job. They are set out further down this page.
Our own bound is labelled inside the receipt as our claim, never as third-party evidence. A verifier that only we could run would not be evidence either, so the verifier costs nothing, needs no account and runs with no network at all. It runs in a browser at timewitness.dev/verify with no toolchain, and as a command, built from source or, on Linux, taken from the signed binaries in the v0.8.2 release. Both are further down this page rather than glossed over here.
One real receipt
This one is committed at crates/verify/tests/data/a-real-stamp/receipt.cbor in the product repository. It was produced by `timewitness stamp` on 2026-09-09 at 18:41 UTC on an ordinary desktop on an ordinary internet connection, at the sixteen polling rounds the agent defaults to. Nine public servers disciplined the clock, three of each of the three kinds this product speaks. None of them has heard of us.
- The reading
- 1788979278918450302 ns since the Unix epoch
- 2026-09-09T18:41:18.918450302Z. Nanosecond resolution, because it is a local counter read. Through the resident agent no network call is in the read; through the one-shot command that made this receipt, the polling that produced it is part of the same few seconds. Resolution is not accuracy.
- The interval
- 153.875 ms wide
- From 1788979278845210129 ns to 1788979278999084899 ns. That width is the claim. The reading is a point inside it and is not the answer. The ceiling it was signed under was 30 s until 2026-09-15, and the verify command prints it off the receipt itself.
- The sources
- 9 answered, 9 kept, run by 6 operators
- Combined by Marzullo intersection and then inverse-square weighting, never averaged. Independent here means the party running the server rather than the address, because several addresses at one company are one chance to be wrong rather than several. This agent declines to sign on fewer than four operators rather than widening the interval.
- The evidence
- 3 entries, one in each role
- A Roughtime corridor, a drand beacon and an RFC 3161 timestamp authority. The reader checked 3 of 3 against keys chosen in advance.
This is a figure from that desktop on that connection at that moment. It is not a figure for your machine, and nothing here should be read as one. A machine that can only reach the three public Roughtime servers gets no receipt: that is three operators, under the shipped floor of four, so the stamp refuses. Before that floor went in on 2026-09-09 such a machine got seconds, 12.0 s wide at the same sixteen rounds, measured on 2026-09-08 on an ordinary desktop, because a Roughtime server states its own uncertainty as a radius in whole seconds.
Where that width comes from, part by part
The verifier prints this breakdown, in half widths, so a reader can see how our own model arrived at the total. The parts are our arithmetic and so is the total. The largest single part is our own model's residual rather than anything the network did.
- 35.081 msthe sources overlapping, halved
- 38.011 msthe model's own residual
- 3.586 msthe oscillator since the last sync
- 250.000 usa fixed safety margin
- 10.000 usthe local read
The widest source round trip, halved, is 72.433 ms. The verifier reports it and does not add it, because it is already inside the first line.
Three evidence roles, and they are not interchangeable
This is the part most people get wrong first time. Each role answers a different question and no amount of one substitutes for another.
An authenticated UTC corridor
roughtime.int08h.com
Puts a signed interval round the moment its server answered, which a stranger can check and the receipt's interval has to overlap. We generate the nonce and the server signs ours, so the response could not have been recorded earlier and replayed at us.
It does not make the bound tighter. A Roughtime radius is a whole number of seconds, and the three public servers reachable on 2026-09-07 were stating one, three and five. Anybody who expects Roughtime to be the precise part has the roles the wrong way round.
A public freshness beacon
drand quicknet, round 32058638
Proves not-earlier-than. The beacon value could not have been known before its round was published, so a receipt carrying it was made after that round.
The signature covers the round number and nothing else. The time comes from arithmetic on the chain's genesis and period rather than from anything signed, and the whole thing rests on a coalition of the chain's members not colluding.
An independent final witness
DigiCert, RFC 3161, serial e64b2c364074693e7d97a198ff858d5e
Takes the not-later-than role. DigiCert signs for the payload hash before the receipt exists, so a stranger can check that a token over that hash was made.
That token writes its time to the nearest second and states no accuracy of its own, so it puts no number on how wrong that authority's clock could be and bounds nothing in UTC, however good the signature is. A reader who has read the authority's published practice can allow for that clock in their own anchors, and the figure is then printed as theirs; nothing that ships carries one. It attests the payload rather than the receipt, and it makes no claim that its own times put its own tokens in order.
The agent's own bound goes in as well, structurally separate from all three and labelled as our claim. On this receipt the outside evidence leaves one edge and not two: the round shows the receipt was made no earlier than it, and nothing outside holds the moment from above.
NTS is in the round on this receipt and is in none of these roles. It improves the clock and can never be portable evidence: its keys are symmetric, so a machine holding one could compose a reply it can then check, and a stranger has no signature to look at. The receipt format refuses an NTS response in an evidence role outright.
The command that checks it
No account, and no network for the check itself. In a browser, the page at timewitness.dev/verify does it with no toolchain: it names the commit it was built from and reads the receipt without sending it anywhere. With nothing of ours involved at all, it is a Rust toolchain and the two commands below. On Linux the v0.8.2 release carries a signed binary that saves the build, and that binary is ours.
cargo build --release -p timewitness-cli
./target/release/timewitness verify a-receipt.cbor --subject the-thing-it-stamps`bash scripts/build-verifier-page.sh` makes the same verifier as one HTML file that runs from your own disk. The two commands above and this one all run in a clone of the public repository, and the receipt above is in it.
What it prints
It answers eight questions one at a time and says plainly where it cannot answer. Two of the eight come back as neither held nor failed on this receipt, and that is the honest result rather than a gap:
is that key one of ours
Nothing here can say without a key log. The receipt proves the agent that signed it held that key. A log of our keys is served at timewitness.dev/key-log.txt and names the keys of our two Roughtime servers and the one agent key we vouch for, which signs our own receipts from 2026-09-24, with the window it is ours in. The key that signed this receipt is not in it: it was made on 2026-09-09 and its private half cannot be accounted for, and an entry for it would vouch for anything it signs. So checked against that log this receipt is refused as not ours, and reading the log takes v0.4 or later; v0 refuses its format by name. A reader who knows the key can compare it themselves; a reader who does not learns that one key signed this and is told so.
does this receipt sit where it says in a chain
It is number 1 and names no previous receipt, so there is nothing to place it against. Every receipt carries a sequence number and the hash of the one before it, both signed, and timewitness order compares two receipts at a time from v0.2.
The same receipt with one bit changed
A copy of that file with a single bit flipped at byte 4882 of 9765, put through the same command. Run on 2026-09-10 on the same desktop.
REFUSED. was this signed by the key it names, over exactly these bytes the signature does not check out: the signature does not match the receipt, so either the receipt was altered after it was signed or it was signed by a different keyIt stops at the first thing that fails and says which one, rather than returning a single word. It then prints what it judged the receipt against and the whole list of what TimeWitness cannot prove, because a refusal is a result and a reader deserves the same detail either way.
Your own machine
The figures above are ours. Getting your own takes the same two steps as checking a receipt, and the number that comes back is about your clock and your connection rather than about this desktop.
cargo build --release -p timewitness-cli
./target/release/timewitness stamp --subject the-thing-you-are-stamping --key timewitness-agent.key --out receipt.cbor`timewitness agent` runs the same model as a foreground process and answers a reading with no network call in it, which is what a stamp costs once the agent is up. `timewitness agent install` hands it to the platform's own service manager so that it starts at boot, and a restart has been checked on Linux only.
What this page cannot prove
The full list is a section of the product rather than a note under it, and it is one click away. These four are the ones that bite hardest on the page you are reading:
A signed timestamp establishes that a record existed by a time. It does not establish that the event the record describes happened then.
Order is checked two receipts at a time, and nothing walks a chain. timewitness order says which of two came first where their intervals sit clear of each other, and which was signed first where one names the other by hash.
The operator count is an upper bound on independence rather than a measurement of it. A shared upstream, a shared network path, a shared satellite constellation or a shared server program is one fault however many companies it is, and no field in NTP, NTS or Roughtime states any of the four. Three programs stand behind those nine names.
It cannot prove exact UTC over the public internet. The claim is bounded time and unbroken order. It is not accurate time.