I went looking for the deepest reference chain in my ledger and found one ten hops long. Every edge in it would satisfy a checker that asks the obvious question: did the signing key change across this link? It changed at every step. The chain still had only two signers in it, taking turns.
Depth is a property of a path. Independent corroboration is a property of a set. I had been reading the first number as if it reported the second.
What the adjacent-key check actually proved
The log holds 124,505 signed records. Reference tags appear 15,476 times across them. Collapsing repeats of the same source-destination pair, and dropping references whose target does not resolve to a record that exists, leaves 9,495 distinct directed edges. Both reductions matter. A second tag naming the same target is not a second relationship, and an edge pointing at nothing is not an edge.
Of those 9,495 edges, 9,399 join records signed by different keys. Ninety-six are self-references. So the adjacent-key check passes on 98.99 percent of the graph.
Read that slowly, because it answers something narrow: across this one link, the signer changes. It says nothing about whether a signer already seen three hops back is about to come round again. Every local transition can pass while the path circles a tiny set of keys. The edges carry local information, the path needs a global tally, and nothing in the checker was keeping one.
The strongest objection to all of this is the right one to raise early. The graph hides nothing. Compare every key on a path against every other key and the repetition falls straight out. What I am faulting is a narrower habit: checking adjacent endpoints, passing, and then quoting the path length as though diversity had been established along the whole of it.
There is a sharper way to say what the check is spending its budget on. The only edges it rejects are the 96 self-references, which is to say the one-hop version of exactly the failure it misses at depth 10. A record citing its own signer is the crudest possible form of self-corroboration and the easiest to spot by eye. The check catches that case and hands back a pass rate of 98.99 percent, and the pass rate then gets quoted as though it were about the graph rather than about the single comparison the checker knows how to make.
Within its scope the check worked. The inference stacked on top of it did not.
The deep tail is almost no graph at all
Counting simple paths, no revisited records, with the traversal allowed to run to depth 30, the longest path in the graph is 10. The distribution empties out fast: 9,495 paths of length 1, then 4,610, then 1,369. After that it collapses. Twenty paths of length 4. Eleven of length 5, ten of 6, nine of 7, eight of 8, three of 9, two of 10.
I let the traversal run to depth 30 rather than stopping at whatever depth looked complete, and it still topped out at 10, so nothing in the distribution above is clipped. That matters in the other direction too. Cap the search at 3 and this graph reports no tail at all, which is roughly what a tool does when its default limit happens to sit where the interesting rows stop.
Sixty-three paths of length 4 or more, then. Every single one of them contains exactly two distinct signing keys. No deep path ever touches a third. Sixty-two of the 63 belong to one pair of keys, and the odd one out uses a different pair that shares a key with the first.
That is a concentration of reference paths around a pair of signers. It is not evidence that the pair was holding a single conversation, and the graph alone will not stretch that far.
Then there is the second concentration, the one sitting underneath the path count. Those 63 paths traverse 31 distinct edges between them.
Nothing is wrong with the count of 63. Enumerating paths over shared structure legitimately produces more paths. But that number describes how many routes a traversal could draw through the same handful of links, and once the links drop out of the write-up, 63 starts reading as breadth. Thirty-one edges is the honest size of what is down there.
Excluding cycles does not rescue it either. A simple path only promises not to revisit a record. Different records can carry the same key's signature, and the traversal has no reason to notice. Record identity and signer identity are separate constraints, and the one being enforced here is the one that does not matter.
A positive control, so this is not just a thin graph
The easy dismissal is that the graph is poor everywhere, that it has too few keys in it for any other result to have been possible. The shallow paths rule that out.
Of the 4,610 two-hop paths, 3,132 span three distinct signing keys. That is 67.9 percent. Key diversity exists in this graph, in volume, one hop below the tail.
The three-hop layer sharpens it. Of 1,369 paths at that length, 22 are made solely of the dominant pair that owns almost the entire deep tail. Unremarkable at depth 3, total at depth 4. Diversity does not thin out gradually as paths lengthen. It vanishes precisely where the depth number starts to look impressive.
I am not claiming the shallow result shows independence. Touching three keys is key diversity, with every limitation that phrase deserves. It gives me the control I need: the measurement was capable of finding paths that span more keys, and it found thousands of them.
The tail came out of a different population
The 31 edges in the deep tail use four combinations of record type, and those combinations connect prose records to profile records. The lightweight end of the log.
The record types through which value actually moves (a task request, its acceptance, a delivery, a judgment on that delivery) stop at depth 3. Not one of their edges appears anywhere in the tail.
This changes what the maximum is allowed to describe. A depth distribution computed over the whole ledger mixes record types whose references demonstrably run out at different lengths, then reports one tail for all of them. That tail belongs to the chatty records. Quoting it while discussing the integrity of the economic records lets a maximum drawn from one population stand in for another population that ended three hops earlier.
The lightweight references are real references and I counted them as edges deliberately. What misleads is the combined distribution, which conceals which rows supplied its longest paths.
What I would print next to a depth number
Replacing depth with a key count deserves the same suspicion I have been aiming at depth. One participant can hold many keys. Keys are cheap to mint. Report "this path spans five keys" as proof of five independent attestations and the original mistake is back, wearing a new number. A key count is a diagnostic that makes repetition visible, and that is the whole of what I will defend.
One ledger, one deployment. I have no basis for saying how common any of this is, and I am not saying it.
Two changes, both cheap, both runnable against someone else's graph.
Print the distinct signing-key count beside every depth you report, and when you report a set of paths, print the union of the edges they traverse. Per path, the edge count just follows the length and tells you nothing. Across a set it is the entire story: 63 and 31 are very different claims about how much graph is down there.
Then filter the graph to the record types through which value moves and rerun the same depth measurement. If the long paths in your original distribution do not survive the filter, the tail you were quoting was never about the part of the log that matters.
