Transparency
An RFC 6962 append-only log, independent witnesses that remember what they endorsed, and split-view detection.
Every decision is committed to an append-only, tamper-evident log before anything is released. The log is the reason an outcome is evidence rather than an assertion: it lets a third party establish not only that a decision was signed, but that it was published, and that the publisher has not since told anyone else a different story.
RFC 6962, exactly
The log is a Certificate-Transparency-style Merkle tree over SHA-256:
- A leaf is
SHA-256(0x00 ‖ data). - An internal node is
SHA-256(0x01 ‖ left ‖ right). - A tree of
nleaves splits at the largest power of two strictly less thann— not in half.
That last rule is not a detail. The obvious alternative — duplicating the last node on odd levels — produces two distinct leaf sequences with the same root (CVE-2012-2459), which means an inclusion proof no longer pins a unique history. The RFC 6962 split has no such collision.
An inclusion proof therefore has a path length that depends on the leaf's index as well as the tree size, not on the size alone.
Two proofs, two questions
| Proof | Question it answers |
|---|---|
| Inclusion | Is this decision in the log at this size? |
| Consistency | Is the log at size m a prefix of the log at size n? Has anything been rewritten or removed? |
A verifier that checks only inclusion learns nothing about whether earlier entries
survived. Both refusal codes exist for a reason: INCLUSION_UNPROVEN (700) and
LOG_INCONSISTENT (701).
Witnesses, and why a signature is not enough
A log operator who is willing to misbehave can sign two different trees and show each to a different audience. Every proof each audience checks passes. This is a split view, and no amount of signing by the log alone detects it.
The defence is a set of independent witnesses that co-sign checkpoints — and crucially, remember what they endorsed. A witness that merely re-signs whatever it is shown is a rubber stamp; it adds a signature and no information.
A witness in this system:
- Refuses to endorse a checkpoint that is not consistent with the last one it endorsed at that size or smaller.
- Retains its endorsement, so a later conflicting checkpoint is detectable against it.
- Signs the tree size and root together, so a root cannot be re-presented at a different size.
WITNESS_QUORUM_MISSING (702) is the refusal when too few independent witnesses
co-signed. Independence is a policy input, not a count — the DIVERSITY_FLOOR (204) rule exists because five witnesses run by one party are one witness.
A witness signature is an evidence anchor, never an execution share. Counting witnesses toward an authority threshold would overstate the threshold, and the quorum rule keeps the two apart by construction.
What this does and does not give you
It does give you: detection. If the operator ever showed two histories, and the two views are ever compared, the inconsistency is provable, attributable to the signed checkpoints, and permanent.
It does not give you: prevention. Transparency is not an access control. A log tells you what happened; it does not stop it. The prevention is the quorum rule and the constitution — transparency is what makes their behaviour auditable afterwards.
It does not give you: liveness. If nobody ever compares views, a split view goes unnoticed. The value comes from independent parties actually pulling checkpoints — which is why the witness set being genuinely independent matters more than its size.
Decisions and refusals
Every outcome is a signed envelope with a stable code — and "we could not tell" is a third state that must never be reported as a denial.
Offline verification
A verifier that holds no socket, no path and no clock — it checks only what you hand it, and it never answers with a boolean.