Transparency logs · monitor, not witness · expectations first
Re-deriving what 23 public logs say they did
A witness holds a key, stays online, and cosigns a checkpoint to attest it saw that tree head
and no other. A monitor holds no key, runs in batches, and re-derives: read a checkpoint,
check the signature against a key the log did not hand you, read it again later, ask for a
consistency proof between the two sizes, and recompute the second root from the first. This
node does the second thing and claims nothing about the first.
No key, no cosignature, on no witness list · a batch monitor cannot see a split view between
batches · the verifiers are hand rolled and self-tested, and a failure here is charged to
this monitor first
Population 23 logs, 21 Certificate Transparency plus
the Go checksum database and Sigstore Rekor
Two reads per log, 45 seconds apart · engine commit 72e9477c3f02
Expectations digest 78cb2f5444df2da26462e17070ab9e421ae85b30a8ec1ed672ea21cddeb34290 published 2026-08-02 05:32 UTC
Batch digest 1e9ae859e742abe6cfb6dabb7e5d337cba88d3f3cc0715ceb8a5a9bdc3821603 run 2026-08-02 05:43 UTC · probe v1.0.0
11
of 11 proofs
recomputed to the root the log published
The whole job of a monitor. Two reads 45 seconds apart, one proof between them, arithmetic done here.
22
of 23 checkpoints
verified against an independently held key
Verified with a pure Python ECDSA and Ed25519 implementation that is self-tested before it is allowed to charge anyone.
0
this batch
disagreements recorded
No tree shrank and no log served two roots at one size. 51,218 entries were added across 11 logs while this monitor watched.
0
of 23 checkpoints
carried a witness cosignature
Including this node, which cosigns nothing. A signed tree head has nowhere to put one, and the notes here carried only the log.
What a batch monitor cannot do
Stating this first, because the value of the numbers above depends entirely on the reader
knowing what they are not.
- Catch a split view that is served to one reader and withdrawn before the next batch. A monitor sees the log at the instants it reads it and says nothing about the gaps.
- Give anyone else an attestation. A monitor's output is a claim about what one reader saw. A witness cosignature is a claim other parties can rely on, and this node produces none.
- Detect anything at all about a log it does not read. The population is frozen and small, and the ledger reports it as a population rather than as coverage.
Cold start, stated plainly
This monitor holds a prior batch for 23 of 23 logs,
because this is the first batch. Everything on this page is a within-batch result: two reads 45 seconds apart and the proof between them. Cross-run comparison starts from the next batch,
and this run appended 46 checkpoints to the append only record
it will compare against. There is no way to make a first batch look like a long running monitor
and no attempt was made to.
The arithmetic is hand rolled, and it is self-tested first
This engine carries no cryptography library, so ECDSA over P-256, Ed25519 and the RFC 6962 consistency recomputation are implemented in pure Python in engine/bridge/tlog_monitor_probe.py.
Each verifier is self-tested with a positive and a negative case before the run is allowed to charge anybody, and the self-test result is published in the ledger. The Merkle self-test builds consistency proofs from the recursive definition in RFC 6962 section 2.1.2 and verifies them with the separate iterative algorithm, for every pair of sizes in an eight leaf tree, and also checks that a tampered proof is rejected.
A signature this monitor fails to verify is recorded as this monitor failing to verify it. It is not published as a claim that the log is wrong.
| Verifier | Self-test | Passed |
|---|
| merkle | pairs_checked=36 · positive_cases_passed=36 · tampered_cases_rejected=28 · root_at_size_8=5dc9da79a70659a9ad559cb701ded9a2ab9d823aad2f4960cfe370eff4604328 | yes |
| ed25519 | vector=RFC 8032 section 7.1 test 1 · positive_case_passed=true · tampered_case_rejected=true | yes |
| ecdsa_p256 | tested_against=ct.cloudflare.com/logs/nimbus2026 · positive_case_passed=true · tampered_case_rejected=true | yes |
What this batch read
| Checkpoint format | Logs |
|---|
| ct_v1_sth | 21 |
| c2sp_signed_note | 1 |
| rekor_json_wrapping_a_signed_note | 1 |
| Operator | Logs |
|---|
| DigiCert | 6 |
| Sectigo | 6 |
| Google | 4 |
| TrustAsia | 3 |
| Cloudflare | 2 |
| Google, for the Go project | 1 |
| Sigstore | 1 |
11 of 23 trees advanced during the window, adding 51,218 entries between the two reads. Where a tree did not advance there is nothing to prove, and the
receipt records that rather than charging the log for a quiet minute.
Where they refuse, and who the refusal belongs to
| Strongest failing limb | Logs |
|---|
| public_key_obtained_independently_of_the_log | 1 |
| Attribution | Logs |
|---|
| ecosystem | 1 |
The one MUST refusal in this batch is Sigstore Rekor, and it is attributed to the ecosystem
rather than to the log. The only key source this monitor reads for it is the log's own
endpoint, and a log that is the only source of its own key cannot be checked by a reader who
did not already trust it. Sigstore does distribute that key through a separate TUF root, which
is the independent path, and this monitor has not implemented TUF. Rekor's checkpoint also
uses a note signature scheme this monitor cannot read, and that refusal is charged to this
monitor.
Limbs
Chains are evaluated independently. A failure inside one chain stops that chain and does not touch the others, so a log whose signature scheme this monitor cannot read is still read, still compared across the two reads, and still counted.
| Limb | Chain | Level | ok | fail | n/a | not reached |
| log_listed_in_a_public_list | read | MUST | 23 | 0 | 0 | 0 |
| public_key_obtained_independently_of_the_log | read | MUST | 22 | 1 | 0 | 0 |
| checkpoint_endpoint_answers_without_credentials | read | MUST | 23 | 0 | 0 | 0 |
| checkpoint_parses_in_its_declared_format | read | MUST | 23 | 0 | 0 | 0 |
| checkpoint_carries_tree_size_and_root_hash | read | MUST | 23 | 0 | 0 | 0 |
| checkpoint_carries_a_signature | read | MUST | 23 | 0 | 0 | 0 |
| signature_scheme_supported_by_this_monitor | verify | SHOULD | 22 | 1 | 0 | 0 |
| signature_verifies_against_the_published_key | verify | MUST | 22 | 1 | 0 | 0 |
| second_read_answered | rederive | MUST | 23 | 0 | 0 | 0 |
| tree_did_not_shrink_between_reads | rederive | MUST | 23 | 0 | 0 | 0 |
| consistency_proof_served | rederive | MUST | 11 | 0 | 12 | 0 |
| consistency_proof_recomputes_to_the_second_root | rederive | MUST | 11 | 0 | 12 | 0 |
| checkpoint_carries_witness_cosignatures | observe | OBSERVED | 0 | 23 | 0 | 0 |
| prior_batch_checkpoint_on_record | observe | OBSERVED | 23 | 0 | 0 | 0 |
Predictions, scored, including the one that missed
Seven predictions were written into the expectations file and published before the batch, at
digest 78cb2f5444df2da2. 2 missed. The scorer was not
changed afterwards and the window was not widened, because rewriting either until a prediction
passes is the failure this whole pattern exists to prevent.
| Prediction | Observed | Result | Blind |
|---|
| Every log in the population serves a checkpoint over plain HTTPS with no credentials of any kind. | 23 of 23 logs served a checkpoint with no credentials | met | yes |
| Every Certificate Transparency checkpoint signature verifies against the key published in the log list, using the verifier implemented in this repository. | 21 of 21 Certificate Transparency signatures verified | met | yes |
| No tree in the population shrinks between the two reads in this batch. | 0 of 23 trees shrank or served two roots at one size | met | yes |
| Every consistency proof this monitor requests recomputes to the second root the log published. | 11 of 11 served proofs recomputed to the second root | met | yes |
| Fewer than half the checkpoints in the population carry a witness cosignature beyond the log's own signature. | 0 of 23 checkpoints carried a witness cosignature | met | yes |
| This monitor holds no prior batch for any log, because this is the first batch, so the cross run comparison refuses for every log in the population. | 23 of 23 logs had a prior batch on record | missed | no |
| At least one log in the population refuses a re-derivation limb for a reason that belongs to this monitor rather than to the log. | 0 of 23 logs refused for a reason attributed to this monitor | missed | no |
Missed: This monitor holds no prior batch for any log, because this is the first batch, so the cross run comparison refuses for every log in the population. Observed: 23 of 23 logs had a prior batch on record.
Written after the batch of 2026-08-02 05:43 UTC,
which observed 23 of 23 logs had a prior batch on record: This prediction was written for the first batch and it was right for the first batch. On every batch after that it is wrong by construction, because the cold start it described is over: this monitor now holds a prior checkpoint for all 23 logs and the cross run comparison no longer refuses for a lack of history. The line is left in the frozen prediction set and left scored as missed rather than retired, because retiring a prediction the moment it stops flattering the run is the habit this ledger exists to avoid. Read it as a dated statement that has since been overtaken.
Missed: At least one log in the population refuses a re-derivation limb for a reason that belongs to this monitor rather than to the log. Observed: 0 of 23 logs refused for a reason attributed to this monitor.
Written after the batch of 2026-08-02 05:34 UTC,
which observed 0 of 23 logs refused for a reason attributed to this monitor: This missed, and it missed for two separate reasons that are worth keeping apart. The prediction was operationalised as the headline refusal attribution, which is the single strongest failing limb, rather than as any limb on any log. A probe attributed refusal does exist in this batch: Rekor's checkpoint uses a note signature scheme this monitor has not implemented, and that limb refuses with the refusal charged to this monitor. It is not the headline for Rekor because a MUST limb fails first, and it is not a re-derivation limb, which is what the prediction named. The second reason is the one the prediction was really about: the Go checksum database was expected to refuse a re-derivation limb because this monitor cannot reconstruct tile based proofs, and its tree did not advance during the forty five second window, so that limb was never reached. A quiet log did not exercise the gap the prediction pointed at. Neither the scorer nor the window was changed after seeing this.
Written after the batch of 2026-08-02 05:43 UTC,
which observed 0 of 23 logs refused for a reason attributed to this monitor: Missed again on the second batch, for the same structural reason and with one new fact worth recording against this monitor. The Go checksum database did move between the two batches, from tree size 58590582 to 58590854, so the advance the first note said never happened has now happened. This monitor still did not ask for a proof of it, because the consistency limbs are scoped to the two reads inside a single batch and the cross batch pair is only recorded, never proven. That is a real gap in the monitor and not a property of the log: the strongest check a batch monitor can run is exactly the one across batches, and this version does not run it. It is named here rather than added quietly, because the limb order is frozen in the expectations file and widening it belongs to a new probe version with its own expectations committed first.
Per log
| Log | First size | Added | Proof nodes | Verdict | Receipt |
| ct.cloudflare.com/logs/nimbus2026 | 5,737,504,186 | 0 | none | admit |
json
|
| ct.cloudflare.com/logs/nimbus2027 | 186,722,674 | 0 | none | admit |
json
|
| sphinx.ct.digicert.com/2026h2 | 1,468,299,031 | 5587 | 24 | admit |
json
|
| sphinx.ct.digicert.com/2027h1 | 38,181,371 | 22 | 18 | admit |
json
|
| sphinx.ct.digicert.com/2027h2 | 24,787 | 0 | none | admit |
json
|
| wyvern.ct.digicert.com/2026h2 | 1,515,546,766 | 5544 | 23 | admit |
json
|
| wyvern.ct.digicert.com/2027h1 | 48,180,696 | 156 | 19 | admit |
json
|
| wyvern.ct.digicert.com/2027h2 | 24,791 | 0 | none | admit |
json
|
| ct.googleapis.com/logs/eu1/xenon2026h2 | 1,922,271,995 | 7020 | 24 | admit |
json
|
| ct.googleapis.com/logs/eu1/xenon2027h1 | 97,749,657 | 938 | 21 | admit |
json
|
| ct.googleapis.com/logs/us1/argon2026h2 | 2,281,773,943 | 8838 | 18 | admit |
json
|
| ct.googleapis.com/logs/us1/argon2027h1 | 164,761,368 | 1942 | 17 | admit |
json
|
| sum.golang.org | 58,590,854 | 0 | none | admit |
json
|
| elephant2026h2.ct.sectigo.com | 1,483,103,970 | 0 | none | admit |
json
|
| elephant2027h1.ct.sectigo.com | 117,560,696 | 0 | none | admit |
json
|
| elephant2027h2.ct.sectigo.com | 27,129 | 0 | none | admit |
json
|
| tiger2026h2.ct.sectigo.com | 1,793,127,438 | 0 | none | admit |
json
|
| tiger2027h1.ct.sectigo.com | 129,512,654 | 0 | none | admit |
json
|
| tiger2027h2.ct.sectigo.com | 26,531 | 0 | none | admit |
json
|
| rekor.sigstore.dev | 2,197,425,668 | 10701 | 21 | refuse |
json
|
| ct2026-a.trustasia.com/log2026a | 2,359,466,486 | 0 | none | admit |
json
|
| ct2026-b.trustasia.com/log2026b | 2,380,761,114 | 10373 | 25 | admit |
json
|
| hetu2027.trustasia.com/hetu2027 | 46,928,816 | 97 | 14 | admit |
json
|
Prior art
None of the constructions here are this node's work. The monitor implements what these
specifications already define, and the ledger exists to record what one reader saw when it
did.
- RFC 6962, Certificate Transparency
: Defines the signed tree head, the get-sth and get-sth-consistency endpoints this monitor calls, the TreeHeadSignature input it reconstructs, and the consistency proof verification algorithm it implements.
- RFC 9162, Certificate Transparency version 2.0
: Restates the same Merkle constructions and is explicit about the separation between logs, monitors and auditors that this ledger relies on.
- C2SP signed note and tlog checkpoint
: The text checkpoint format the Go checksum database and Sigstore serve, which this monitor parses: origin line, tree size, base64 root hash, blank line, signature lines.
- C2SP tlog-witness
: The witness protocol this node deliberately does not implement. A witness cosigns with a key and this node holds none.
- transparency.dev
: The ecosystem this work sits inside, and the source of the witness and monitor distinction the ledger is built around.
- Sigsum
: A log design where witness cosigning is mandatory rather than optional, which is the contrast that makes counting cosignatures on other logs worth doing.
- Go checksum database design
: The tile based transparent log this monitor reads a checkpoint from and cannot yet prove consistency over.
Read it yourself
One log at a time: https://geniusflow-federation.vercel.app/tlog/receipts/<LOG_KEY>.json, with
slashes in the log key written as underscores. The index carries both forms so nobody has to
guess.
Re-run it
PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py selftest
PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py expect
PYTHONPATH=engine python3 engine/tools/tlog_monitor_run.py run
PYTHONPATH=engine python3 engine/tools/tlog_monitor_export.py
selftest runs the verifier checks on their own and needs no network.
run aborts if the expectations digest stops matching its contents.
What this is not
- This node is a monitor, not a witness. It holds no key, cosigns nothing, and appears on no witness list. Nothing in this ledger is an attestation anybody else can rely on.
- A batch monitor cannot see a split view that is served to one reader and withdrawn before the next batch. It sees the log at the instants it reads it and says nothing about the gaps between them.
- A signature this monitor fails to verify is recorded as this monitor failing to verify it. The verifiers here are hand rolled in pure Python because this engine carries no cryptography library, and a hand rolled verifier that disagrees with a log operated by Google is overwhelmingly more likely to be the broken party.
- This is not coverage of the transparency log ecosystem. The population is a frozen list drawn from public log lists, and no rate here should be read as a rate over all logs.
- No log was contacted beyond plain GETs of endpoints that are already public, with an identifying user agent.
Added after the expectations were frozen, and kept separate rather than folded into
the list above, because editing a frozen list after the fact would defeat the reason
for freezing it.
Added 2026-08-02, raised while researching this ecosystem's terms of art, after the expectations for this ledger were already committed: Two components this node publishes elsewhere carry names that are terms of art here, and neither is what the name suggests to a reader arriving from this community. `witnessfield` is not an implementation of the C2SP tlog-witness protocol and issues no cosignature. `helixhash` is a hash chain, which is tamper evident only to a verifier willing to replay the whole chain, and it is not an RFC 6962 Merkle tree: it offers no inclusion proof, no consistency proof and no efficient evidence against equivocation. Both names predate this ledger. They are disambiguated here rather than defended, because a page that spends its length separating a monitor from a witness should not leave its own naming to be guessed.