Verity

Announcement · 2 November 2026

Time, countersigned.

The signature proves who sealed it. The anchor proves when — by a clock Verity doesn’t control.

Tonight the proof stack went to production. The chain head is now anchored on a schedule to an RFC 3161 timestamp authority — DigiCert’s public endpoint, timestamp.digicert.com: no account, no credentials, no private arrangement, the same public endpoint anyone can call. The token that comes back is stored in full and served openly, so the proof can be checked by people who do not trust the gate. And the first signature issuance is on the chain — the gate witnessing a record hash it never saw, sealed at seq 17.

Anchor 1 · head seq 13 DigiCert (public) · 2026-11-03T04:00:10Z OpenSSL · Verification: OK Issuance · seq 17 Chain at ship time · 17 records · 17 signatures

Run it yourself

Don’t take this page’s word for it

This terminal runs in your browser, against the public API only. It recomputes every hash from its preimage, reads the timestamp out of DigiCert’s token itself, and checks the chain’s Ed25519 signatures against the public key the API publishes. Nothing is taken on faith — not even the lines it prints, which are built from material your browser fetched and verified itself. Start with verify.

One check is deliberately not in the browser: the signature DigiCert itself placed inside the token. That one is verified offline, with OpenSSL, against DigiCert’s published CA chain — the openssl command prints the exact commands, and the filed receipt for anchor 1 reads Verification: OK. The boundary is the point: each proof is checked with the tool that actually proves it.

In the record

What shipped, and where it sits in the chain

Every line below is a public record. The links are the records themselves — not screenshots of them.

External timestamps

RFC 3161 anchoring of the chain head on a schedule, so the clock belongs to a third party. Production anchors run on DigiCert’s public timestamp endpoint — http://timestamp.digicert.com — no account, no credentials, no private arrangement. The full token is stored and served openly on the anchor’s public row.

Live
Anchor 1

The first production anchor. Head at seq 13, countersigned by DigiCert’s public TSA under policy 2.16.840.1.114412.7.1, at 2026-11-03T04:00:10Z. Read the anchor row — token included.

Seq 13
The offline receipt

Anchor 1’s token was also verified by hand, offline: OpenSSL against DigiCert’s published CA chain returned Verification: OK, and the receipt is filed with the proof-stack records. The terminal’s openssl command prints the exact commands so anyone can repeat it.

Filed
Anchor 2

A second anchor confirmed the same night: head at seq 15, DigiCert (public endpoint), 2026-11-03T04:05:47Z. Run anchors in the terminal for the live list — it reads the API, not this page.

Seq 15
First issuance — seq 17

Signature issuance opened with the system witnessing itself: the first issuance seals the SHA-256 of the proof-stack’s own specification, bdd5eccc…c408e994 — class spec-document, operator verity-self, under the agreement self-issuance-canary. The bundle carries its label verbatim: “Verity witnessed the presentation of this record hash and sealed it in its chain. Verity did not see the record, and this issuance is not an endorsement of the record’s contents, accuracy, or legality.” Read the bundle.

Seq 17
Claim-checking

Verdicts against retrieved sources still run by hand, as a by-request service, while the automated module is built. How to ask is on the architecture page.

By request
See the architecture Read the API

Why public

Anchored · Public DigiCert

The endpoint being public is not an implementation detail. It is the feature.

A private timestamping account would prove the time to anyone willing to trust our arrangement with a vendor. A public endpoint proves it to anyone, full stop. There is no account to revoke, no contract to audit, no relationship to take on faith — the clock is a public utility, and DigiCert’s public TSA answers our requests exactly as it answers anyone’s.

That is why the card for this announcement is stamped the way it is: ANCHORED · PUBLIC DIGICERT. The proof does not depend on who we are to DigiCert. It depends on mathematics anyone can re-run — in the terminal above, or with OpenSSL on their own machine.

A signature proves who sealed it. The anchor proves when. Two different proofs, from two different parties — the gate’s key for the first, a public clock for the second. Neither one is asked to vouch for the other’s part.

The honest boundary

What each check does — and does not — prove

  • The browser proves the bindingThe digest inside DigiCert’s token is the SHA-256 of the chain head’s hash bytes — recomputed in your browser, compared three ways: served imprint, recomputed imprint, and the imprint parsed out of the token itself. The time it shows is read from the token, not from our row.
  • The browser proves the sealsFor any issuance bundle, the proposal hash, the chain hash, and the Ed25519 signature are recomputed and verified in your browser against the public key. With a caller key, verify replays the whole chain the same way, record by record.
  • The browser does not verify DigiCert’s own signatureThat check belongs to OpenSSL and the published CA chain — run once by hand for anchor 1, receipt filed, commands printed by the terminal’s openssl command for anyone to repeat. A browser pretending to do this check would be theater; this page doesn’t do theater.
  • Coverage is stated, not impliedAn anchor countersigns the head at its seq — nothing after it. The issuance at seq 17 stands on its signature today and is covered when a later anchor’s head passes it; the terminal’s issuance 17 output says exactly that, because the bundle itself says it (anchor: null until covered).