Transparency log witnesses: how cosigned checkpoints make a log tamper-evident

On 17 August 2026, at 14:17:40 UTC, an independent witness operated by Markovian Protocol cosigned the checkpoint of our public transparency log. Nothing about the log changed that afternoon. What changed is what we can prove about it: from that moment, if we ever rewrote the log's history, a third party outside our infrastructure would be holding cryptographic evidence of the version we abandoned.

This post explains what a transparency log witness is, what a cosigned checkpoint actually proves, and the obligations you take on when one starts watching your log. Most of it we learned by going through the process rather than by reading about it.

The gap witnesses close: a log can lie to you specifically

An append-only log is the standard answer to "how do I show my records existed before the dispute did". You publish entries into a Merkle tree, the tree has a root hash, and anyone can check that a given entry is included. Certificate Transparency (RFC 6962) runs the web's certificate issuance through this structure; the Go checksum database does it for module hashes; Sigstore's Rekor does it for software signatures.

But a Merkle tree on its own has a hole, and RFC 6962 was upfront about it: detecting a misbehaving log requires people to compare notes on what the log showed them. A log operator who controls the serving infrastructure can present one version of the tree to the auditor and a different version to everyone else. Each view is internally consistent, each proof checks out, and the two views never meet. This is the split-view attack, and no amount of hashing inside the log prevents it, because the operator is the one doing the hashing.

For our purposes the operator's honesty is exactly what is in question. Traceseal exists because logs written by the party under scrutiny are not evidence. Our transparency log anchors signed agent receipts, and until last week it had the same weakness as every self-hosted log: you had to trust us not to serve you a private version of history.

What a checkpoint is

A checkpoint is a small signed statement of the log's current state, in the format specified by c2sp.org/tlog-checkpoint: the log's name (its origin), the number of entries, and the root hash of the tree at that size, wrapped in a signed note. Ours currently reads:

log.traceseal.io
19
OhQzzSdQHnpofrO/F2reZkiIDDPjUEM+wuGNc4mlD84=

— log.traceseal.io vLzsyMryP2doyfOtISb5...

Nineteen entries. Certificate Transparency logs hold billions, and the format is the same, which is rather the point: the protocol does not care whether it is guarding the web PKI or a small receipts log. A checkpoint commits the operator to one specific history up to one specific size. What it cannot do alone is stop the operator issuing two different commitments to two different audiences.

What a witness actually does

A witness is a service, run by someone other than the log operator, that keeps the latest checkpoint it has seen for each log it follows. The protocol, c2sp.org/tlog-witness (v1.0.0, March 2026), is short enough to read over coffee. The core of it:

Witnesses verify that the checkpoint is consistent with their previously recorded state of the log (if any), and return a timestamped cosignature.

"Consistent" carries the whole load. When our log grows and asks the witness to cosign the new checkpoint, it must supply a consistency proof: a Merkle proof that the tree at the new size contains the tree the witness already recorded as a prefix. If the proof fails — if any old entry was altered or removed — the witness refuses. The cosignature it returns on success embeds its own timestamp, so the statement a verifier ends up with is precise: at this time, this witness saw this exact view of the log, and that view extended every view the witness had seen before.

A split view now requires deceiving the witness as well, and the witness's records are not ours to edit. That is the entire trick. No new cryptography, just a signature from someone whose incentives are not our incentives.

One implementation detail that cost us an afternoon: the log's own /checkpoint endpoint serves only the log's signature. The cosignature lives on the witness's copy, at /<sha256(origin)>/checkpoint on the witness's host. If you fetch your own checkpoint and wonder where the witness signature went, it was never going to be there.

What a cosignature does not prove

Witnessing is content-blind, and it is worth being blunt about the edges:

• It says nothing about what the entries mean. A witness checks append-only consistency, not truth. A log of fabricated receipts, faithfully appended and never rewritten, will be cosigned without complaint. Content verification is a separate job — ours is done by signature checks on each receipt, and the honest-limits caveats in that post still apply.
• One witness is one extra party to corrupt. If the log operator and the witness collude, the split view returns. The mitigation is a quorum of independent witnesses, which is why a shared witness network is being built around the C2SP protocols rather than each log recruiting its own friendly observer.
• A cosigned checkpoint covers the log up to that size. Entries appended since the last cosignature are committed by the log's own signature only, until the next witnessing round picks them up.

The part nobody advertises: witnessing binds you

Before the pin, our append-only claim was policy. We could have quietly regenerated the log, re-signed it, and nobody outside would have been the wiser. After the pin it is a commitment with teeth, and the teeth point at us.

The log must now stay strictly append-only forever, because the witness's copy of every cosigned checkpoint is permanent evidence against any rewrite. And the log's signing key can no longer rotate casually: the witness pins the key it verified, and a checkpoint signed by an unknown key gets refused. We put both obligations in writing to the witness's operator — no history rewrites, and no key rotation without coordinating first — and they were confirmed back to us as the terms of witnessing.

Check our log yourself

None of this asks for trust in the telling. Both views are public:

$ curl https://log.traceseal.io/checkpoint
$ curl https://witness.markovianprotocol.com/$(printf 'log.traceseal.io' | sha256sum | cut -d' ' -f1)/checkpoint

The bodies should match byte for byte, with the witness's cosignature as an extra line on the second. We have published the verifier we run daily — it checks the log's Ed25519 signature, the witness cosignature against the witness's public key, and that live and pinned bodies agree — as lib/tlog_witness.py in the Alibi repository.

Where this fits in an agent accountability stack

A signed receipt proves an execution record has not changed since it was sealed. An audit trail tells you what to put in that record. The transparency log proves the receipt existed before anyone had a reason to dispute it. The witness closes the last gap in that chain: it stops the log itself being quietly replaced. Each layer covers a failure the previous one cannot.

One witness is not the end state; a quorum of independent witnesses is. What ours bought is the step from "trust us" to "trust us, or catch us out through a party we do not control". How many witnesses a receipts log needs before a court or an auditor treats its timestamps as settled is a question nobody has an answer to yet. We would rather be early to finding out.