Verification Modes

Tidecoin has two post-quantum verification regimes: the legacy regime used by Falcon-512 since genesis, and the strict regime enabled at AuxPoW activation. The strict regime does more than change proof of work. It also enables post-AuxPoW script and signature rules.

This page explains the verification boundary. It is not the scheme registry; for prefixes and sizes, see Scheme Registry. It is not the wire encoding page; for byte layout, see Signature Encoding.

Mode summary

Mode	Where it applies	Falcon behavior	Other PQ schemes
Legacy	Pre-AuxPoW consensus context	Falcon-512 legacy signatures accepted	Not consensus-allowed before AuxPoW
Strict	At and after AuxPoW activation	Legacy-only Falcon signatures rejected; standard PQClean verification used	Falcon-1024 and ML-DSA schemes may be allowed by the scheme gate

Historical blocks are still validated under the flags that applied to their height. A transaction that was valid in a pre-AuxPoW block remains valid in that historical context. New spends created under strict post-AuxPoW rules must satisfy strict verification.

Consensus flags

AuxPoW activation enables a cluster of post-AuxPoW validation rules:

Flag	Bit	Meaning
`SCRIPT_VERIFY_PQ_STRICT`	13	Reject legacy Falcon-512 signatures and use strict PQ verification rules.
`SCRIPT_VERIFY_WITNESS_V1_512`	14	Enable witness v1 64-byte scripthash validation.
`SCRIPT_VERIFY_SHA512`	15	Enable `OP_SHA512`.

These flags are applied by validation once the block height is at or after nAuxpowStartHeight.

Network activation

Network	AuxPoW start height	Verification implication
Mainnet	Disabled	Legacy Falcon-512 remains the only active mainnet scheme until a future activation changes the parameter.
Testnet	1,000	Strict PQ verification and post-AuxPoW rules apply from height 1,000.
Regtest	0	Strict PQ verification and post-AuxPoW rules are active immediately.

Always verify the current activation parameter from chain parameters before publishing operational instructions. This page describes the rule; Activation Status records the current network values.

Falcon legacy mode

Falcon-512 legacy mode exists for backward compatibility with the genesis-era mainnet rules. It preserves the historical Falcon acceptance behavior, including the legacy Falcon-512 signature header byte 0x39 and the relaxed norm-bound behavior documented in the whitepaper.

Legacy mode is not a separate key type. A Falcon-512 private key and public key are the same key material across legacy and strict contexts. The difference is which signature format and verification bound are accepted for a spend at a given height.

Strict mode

Strict mode uses the standard PQClean verification path for the selected scheme. Under SCRIPT_VERIFY_PQ_STRICT, legacy-only Falcon signatures are rejected for new spends. This is the mode that accompanies AuxPoW, witness v1 64-byte scripthashes, OP_SHA512, Falcon-1024, and ML-DSA scheme availability.

For wallets, the practical rule is:

Before AuxPoW activation, create Falcon-512 spends that are valid under the legacy mainnet rules.
At and after AuxPoW activation, create spends that pass strict verification and only use schemes allowed at that height.
Do not treat old signatures as reusable templates for new post-activation transactions.

Why historical compatibility still works

Consensus validation is contextual. Old blocks are not reinterpreted as if they were mined after the activation height. Pre-AuxPoW blocks keep their pre-AuxPoW script flags, so the chain does not require a key migration or a mass re-signing event.

New blocks after the activation height use the stricter flags. That is where the behavior changes.

Source of truth

Topic	Source
Script flag definitions	`../tidecoin/src/script/interpreter.h`
Height-based flag activation	`../tidecoin/src/validation.cpp`
Scheme activation gate	`../tidecoin/src/pq/pq_scheme.h`
Wallet and transaction signing flag behavior	`../tidecoin/src/wallet/`, `../tidecoin/src/script/sign.cpp`
Cryptographic rationale	`../tidecoin/doc/whitepaper.md`