Difficulty Specification

cASERT — Contextual Adaptive Stability & Emission Rate Targeting
Difficulty Adjustment

Unified consensus-rate control combining bitsQ primary controller, equalizer profiles, and anti-stall for ConvergenceX Proof-of-Work.

CONSENSUS | Integer-only arithmetic · Q16.16 fixed-point · Per-block retargeting

bitsQ Primary Controller

Exponential Foundation
INSPIRED BY BCH ASERT (2020)

cASERT's bitsQ primary controller uses an exponential moving average inspired by BCH's ASERT algorithm (designed by Mark Lundeberg and Jonathan Toomim, November 2020 hard fork). cASERT was designed by NeoB for SOST Protocol (2026), unifying the exponential controller with equalizer profiles and anti-stall decay into a single consensus-rate control system for ConvergenceX.

PropertyDetail
Core formulanext_bitsq = anchor_bitsq * 2^(-td / halflife)
Time delta (td)actual_time - expected_time (deviation from ideal schedule)
Exponential responseDifficulty doubles/halves every halflife period
SOST implementationInteger-only cubic polynomial approximation of 2^x
EncodingQ16.16 fixed-point arithmetic, no floating point in consensus
BITSQ_HALF_LIFE43,200s (12 hours)
Per-block delta cap6.25%
TARGET_SPACING600s (10 minutes)
Key principle: The bitsQ controller is anchor-based. The difficulty for any block can be computed directly from the anchor block and the elapsed time, without iterating through intermediate blocks. This makes it stateless and resistant to manipulation of intermediate timestamps.

cASERT Architecture

cASERT is a unified three-layer consensus-rate control system: (1) the bitsQ primary controller provides exponential difficulty adjustment, (2) equalizer profiles introduce discrete hardening levels when the chain runs ahead of schedule, and (3) anti-stall decay ensures liveness under sudden hashrate loss. ConvergenceX PoW has a stability_metric (gradient descent convergence) that can be tightened. cASERT monitors how far ahead of schedule the chain is and introduces discrete hardening levels to prevent fast-block attacks.

Level Thresholds
BLOCKS AHEAD OF SCHEDULE
LevelBlocks AheadThresholdBehavior
L10 – 4NORMALStandard operation, baseline stability requirements
L25 – 25CASERT_L2_BLOCKS = 5First hardening stage, scale = 2
L326 – 50CASERT_L3_BLOCKS = 26Increased stability requirements, scale = 3
L451 – 75CASERT_L4_BLOCKS = 51Aggressive hardening, scale = 4
L576 – 100CASERT_L5_BLOCKS = 76Near-maximum fixed hardening, scale = 5
L6+101+level = 6 + floor((ahead-101)/50)Unbounded hardening, scale grows with distance
UNIDIRECTIONAL

Hardens Only

cASERT only HARDENS difficulty, never relaxes it. When the chain is behind schedule, cASERT bitsQ handles the adjustment. This prevents attackers from exploiting difficulty drops.

SCALE = LEVEL

Proportional Response

The hardening scale equals the level number. Higher levels impose stricter stability_metric thresholds on ConvergenceX, making it progressively harder to produce fast blocks.

ANTI-STALL

Decay Anti-Stall

If no block is found for an extended period, the cASERT level decays gradually. Activation: dynamic — max(ahead × 600s, 2h). No ceiling. This prevents mining deadlock when hashrate drops suddenly.

WORKED EXAMPLE — L10 (450 blocks ahead)

Activation: max(450 × 600, 7200) = 270,000s (75 hours)

After activation, decay uses current level tier (not original):
L10→L9→L8: FAST (10min/level) — 30 min
L7→L6→L5→L4: MEDIUM (20min/level) — 80 min
L3→L2→L1: SLOW (30min/level) — 60 min

Total decay L10→L1: 170 min (2h 50m)
Total from mining start: 75h + 2h 50m = ~78 hours

BCH ASERT Heritage

Properties Inherited from BCH ASERT
SHARED LINEAGE
PropertyDetail
Exponential moving average formula2^(-td / halflife) — same mathematical approach
Anchor-based calculationUses first block of epoch as anchor reference
Q16.16 fixed-point encodingSame integer representation, no floating point
Global difficulty clampsMIN_BITSQ / MAX_BITSQ bounds enforced
Per-block retargetingEvery block, not every N blocks
Epoch structureBLOCKS_PER_EPOCH = 131,553 blocks (~2.5 years)
Heritage note: cASERT's bitsQ controller is inspired by BCH ASERT's exponential approach but uses a 12h half-life (vs BCH's 24h) and a 6.25% per-block relative delta cap. These changes, combined with the equalizer and anti-stall layers, make cASERT a unified system purpose-built for ConvergenceX.

What is New in cASERT

Novel Components
SOST-SPECIFIC
FeatureDescription
Anti-stall decayDecay activates after max(ahead 00D7 600s, 7200s) without a block 2014 proportional, no ceiling
Level systemDiscrete levels (not continuous) for deterministic consensus — any two nodes compute the same level
Floor at L1Chain always gets at least L1 stability requirements, even when behind schedule
Stateless recalculationAny node can compute the cASERT level from the chain alone, no extra state needed
ConvergenceX integrationcASERT adjusts the stability_metric threshold, not the PoW target directly
Contraction coefficientc = 7/10, ensuring d_final <= 0.7 * d_initial + margin
Anti-Stall Mechanism
DECAY PROTOCOL

The anti-stall decay ensures liveness under sudden hashrate loss. If no valid block arrives for DECAY_START seconds, the cASERT hardening is gradually reduced. This decay is deterministic and computed from the timestamp of the previous block, making it fully verifiable by all nodes.

ConditionResponse
Stall < activation thresholdNo decay — cASERT level applies at full scale
Stall >= activation thresholddecay_factor reduces cASERT scale progressively
ResultMining continues even if hashrate drops dramatically
Design rationale: Discrete levels (rather than a continuous function) eliminate consensus ambiguity from rounding differences between implementations. Every conforming node will compute exactly the same level for the same chain state.

Consensus Parameters

Parameter Table
IMMUTABLE CONSTANTS
ParameterValueDescription
BITSQ_HALF_LIFE43,200s12-hour half-life for bitsQ exponential adjustment
BITSQ_DELTA_CAP6.25%Per-block relative delta cap for bitsQ adjustment
TARGET_SPACING600s10-minute target between blocks
BLOCKS_PER_EPOCH131,553Blocks per difficulty epoch (~2.5 years)
GENESIS_BITSQ765,730Initial difficulty in Q16.16 (11.6841, calibrated)
MIN_BITSQ65,536Minimum difficulty (1.0 in Q16.16)
MAX_BITSQ16,711,680Maximum difficulty (255.0 in Q16.16)
CASERT_L2_BLOCKS5Blocks ahead to enter L2
CASERT_L3_BLOCKS26Blocks ahead to enter L3
CASERT_L4_BLOCKS51Blocks ahead to enter L4
CASERT_L5_BLOCKS76Blocks ahead to enter L5
CASERT_L6_BLOCKS101L6+ unbounded starts here
CASERT_DECAY_ACTIVATIONmax(ahead00D7600, 7200)Dynamic: proportional to blocks ahead, floor 2h, no ceiling
CASERT_DECAY_FAST_SECS600sL8+: 10 min/level (fast recovery)
CASERT_DECAY_MEDIUM_SECS1,200sL4–L7: 20 min/level (medium)
CASERT_DECAY_SLOW_SECS1,800sL2–L3: 30 min/level (cautious)
Activationheight ≥ 2Requires at least 2 blocks in chain
CX_C_NUM / CX_C_DEN7/10Convergence ratio for stability test
Source reference: All parameters are defined in include/sost/params.h and include/sost/pow/casert.h. These values are consensus-critical and immutable.
Implementation: cASERT is validated as part of the L2 block validation layer (header context checks). See include/sost/block_validation.h for the full consensus pipeline.