Consensus Rules

Tidecoin is a Bitcoin Core-derived UTXO chain with post-quantum consensus extensions. The base validation model remains Bitcoin-like: blocks contain transactions, transactions spend UTXOs, scripts authorize spends, proof-of-work orders the chain, and contextual flags decide which rules apply at a given height.

This page ties the consensus surface together. It is not a mining setup guide; mining workflows belong under Mining. It is not the RPC reference; API behavior belongs under Reference.

Fixed block limits

Rule	Value
Maximum serialized block size	6,000,000 bytes
Maximum block weight	6,000,000
Maximum block sigops cost	80,000
Coinbase maturity	100 blocks
Witness scale factor	4

These values are consensus-level constants.

Network activation parameters

Network	AuxPoW start height	AuxPoW chain ID	Strict chain ID	Target spacing	Retarget timespan
Mainnet	Disabled	8	Yes	60 seconds	5 days
Testnet	1,000	8	Yes	60 seconds	5 days
Regtest	0	8	Yes	60 seconds	4 hours

AuxPoW activation is the major consensus boundary. On mainnet the parameter is currently disabled. Testnet and regtest exercise the post-AuxPoW rules.

Pre-AuxPoW ruleset

Before AuxPoW activation, Tidecoin validates blocks under the launch ruleset:

Area	Rule
Proof-of-work	YespowerTIDE block hash must satisfy the target.
Signature schemes	Falcon-512 is the only consensus-allowed PQ signature scheme.
Falcon verification	Legacy-compatible Falcon-512 verification is allowed.
Witness v1 P2WSH-512	Not active as the enforced witness-v1 script-hash path.
`OP_SHA512`	Not enabled as the SHA-512 opcode.
AuxPoW data	Not allowed before activation.

Blocks with AuxPoW data or the AuxPoW flag before activation are invalid.

Post-AuxPoW ruleset

At and after nAuxpowStartHeight, Tidecoin enables the post-AuxPoW ruleset:

Area	Rule
Proof-of-work	Scrypt parent proof is validated through AuxPoW.
AuxPoW	Header/block AuxPoW data, chain ID, merkle branches, and parent PoW are checked.
Signature schemes	Falcon-512, Falcon-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87 are allowed.
PQ verification	`SCRIPT_VERIFY_PQ_STRICT` is active.
Witness v1 P2WSH-512	`SCRIPT_VERIFY_WITNESS_V1_512` is active.
`OP_SHA512`	`SCRIPT_VERIFY_SHA512` is active.
Difficulty	Post-AuxPoW retarget rules are used.

The activation is contextual by block height. Historical pre-activation blocks keep their pre-activation script flags.

Script flags

The post-AuxPoW script flag bundle is:

Flag	Bit	Consensus effect
`SCRIPT_VERIFY_PQ_STRICT`	13	Reject legacy-only Falcon signatures under strict verification.
`SCRIPT_VERIFY_WITNESS_V1_512`	14	Enforce 64-byte witness v1 P2WSH-512 validation.
`SCRIPT_VERIFY_SHA512`	15	Enable `OP_SHA512`.

Validation applies these flags for mempool acceptance against the next block height and for block validation against the block’s actual height.

Scheme gate

Signature scheme availability is height-gated:

Height context	Allowed schemes
Before AuxPoW activation	Falcon-512 only
At and after AuxPoW activation	Falcon-512, Falcon-1024, ML-DSA-44, ML-DSA-65, ML-DSA-87

The serialized public key carries the scheme prefix. The signature verifier selects the scheme from that prefixed public key.

AuxPoW validation

When a block uses AuxPoW, consensus checks:

AuxPoW flag and AuxPoW data are consistent.
AuxPoW is not used before activation.
Chain ID bits match Tidecoin chain ID 8 when strict chain ID is enforced.
The AuxPoW commitment and merkle branches are valid.
The parent block hash satisfies the target.

Common rejection reasons include auxpow-missing, auxpow-unexpected, auxpow-pre-activation, auxpow-chainid, auxpow-invalid, and auxpow-parent-pow.

Proof-of-work and difficulty

Before AuxPoW, Tidecoin validates YespowerTIDE work. After AuxPoW, Tidecoin validates the scrypt proof carried by the parent block through the AuxPoW structure.

Rule	Pre-AuxPoW	Post-AuxPoW
Work source	Tidecoin block hash	Parent block scrypt hash through AuxPoW
Mainnet target spacing	60 seconds	60 seconds
Retarget	5-day interval	Per-block post-AuxPoW retarget path
Mainnet min difficulty	Disabled	Disabled

See Proof-of-Work for the full difficulty description.

Monetary policy

Block subsidy starts at 40 TDC. The subsidy is reduced by a factor of four at each subsidy step, and each step’s interval doubles from the initial interval.

Network	Initial subsidy interval
Mainnet	262,800 blocks
Testnet	262,800 blocks
Regtest	20 blocks

The subsidy calculation uses cumulative doubling intervals and returns zero once the shift would exceed the valid range.

Consensus versus policy

Consensus rules decide whether a block or transaction can be valid on chain. Policy rules decide whether a node will relay or mine a transaction from its mempool. For example, standard transaction weight, standard scriptSig size, P2WSH stack limits, and pre-activation wallet output gating are policy surfaces layered on top of consensus.

Integration code should distinguish:

Question	Use
Can this transaction appear in a valid block?	Consensus rules
Will my node relay or mine this transaction now?	Policy rules
Which flags apply to the next block?	Active chain height plus consensus parameters
Which flags applied to an old block?	That block’s contextual height

Source of truth

Topic	Source
Consensus constants	`../tidecoin/src/consensus/consensus.h`
Chain activation parameters	`../tidecoin/src/kernel/chainparams.cpp`
Script flag application	`../tidecoin/src/validation.cpp`
AuxPoW context checks	`../tidecoin/src/validation.cpp`, `../tidecoin/src/auxpow.cpp`
PoW switch and retarget rules	`../tidecoin/src/pow.cpp`
Scheme activation gate	`../tidecoin/src/pq/pq_scheme.h`
Subsidy calculation	`../tidecoin/src/validation.cpp`