This is a polar (radial) Merkle tree: the 16 certificate leaves sit on the outer ring, one per 22.5° slice, and every level of hashing steps one ring further inward until a single root sits at the centre. Unlike a spatial 3D scene, the ring layout is drawn straight down in 2D and every node carries a real computed hash (a 32-bit FNV-1a chain over the leaf's own id, shown as hex), not just a coloured box:
root = H(H(H(L0,L1), H(L2,L3)), …)
proof length = log2(16) = 4 sibling hashes
recompute root from leaf + 4 siblings → must equal the published root
When an epoch seals, the panel on the left picks one leaf and prints its real inclusion proof: the 4 sibling hex values needed to walk back up to the root, plus a live check that recomputing the root from just the leaf and those siblings reproduces the actual root exactly.
- Forged / mis-issued rate — the chance a newly logged certificate was never requested by the domain owner. Note the proof math above is completely blind to this: a forged cert gets an equally valid inclusion proof, because a Merkle tree only proves presence in the log, never legitimacy.
- CT Monitoring — legitimacy is caught separately, by monitors diffing the public log against an inventory of certs the domain owner actually requested. A scan (the expanding radar sweep) catches every still-undetected forged leaf and flips it gold.
- Mean time-to-detect — the average gap between a forged certificate being logged and a monitor catching it; it stays "—" forever with monitoring off, since an unmonitored log gives an attacker unlimited exposure time even though every one of its certs still has a perfectly valid Merkle proof.
Real deployments: Google's Certificate Transparency, RFC 6962; Chrome and Safari refuse to trust a publicly-issued certificate that isn't logged this way. (This demo's hash is a simplified 32-bit FNV-1a chain, not SHA-256 — the tree math it demonstrates is identical.)