SOST Technology — ConvergenceX PoW, cASERT Difficulty, Constitutional Gold

OVERVIEW

Architecture Pipeline

Layer 01

ConvergenceX PoW

Gradient-descent work
+ stability basin proof

Layer 02

cASERT bitsQ

Per-block difficulty
Q16.16 adjustment

Layer 03

cASERT Equalizer

Structural correction
Adaptive mode control

Layer 04

SOSTCompact

Q16.16 difficulty
encoding (nBits)

Layer 05

MTP Validation

Median Time Past
timestamp discipline

The consensus stack is vertically integrated: ConvergenceX produces the proof-of-work, cASERT controls difficulty via three layers — bitsQ primary controller adjusts every block in continuous Q16.16 log-space, the equalizer applies structural correction via ConvergenceX stability profiles, and anti-stall ensures liveness — while MTP anchors all timing decisions to validated chain history. Every layer is integer-only and bit-for-bit reproducible across all implementations.

PROOF OF WORK

ConvergenceX PoW

convergencex_attempt()

CONSENSUS-CRITICAL

Instead of brute-force hash collision, ConvergenceX requires miners to produce verifiable convergence certificates using Transcript V2. Each attempt solves a tip-bound linear system via deterministic gradient descent, mixed with memory-hard scratchpad reads, and proves the solution lies in a stable convergence basin. Transcript V2 adds segment commitments and sampled round witnesses, enabling 11-phase verification at ~0.2ms (vs ~1ms in V1). Dataset v2 (SplitMix64) and Scratchpad v2 (SHA256-indexed) are independently indexable at O(1).

// 1. Derive challenge from chain tip (anti-grinding)
block_key  = SHA256( prev_hash || "BLOCK_KEY" )
seed       = SHA256( MAGIC || "SEED" || header_core || block_key || nonce || extra_nonce )

// 2. Derive linear system M, b from block_key (deterministic per tip)
(M, b, λ)  = derive_M_and_b( block_key, N=32, λ=100 )

// 3. Gradient descent with scratchpad mixing (memory-hard)
for r in 1..100,000:
    x[i] -= ( A(x)[i] - b[i] ) >> lr_shift          // gradient step
    x[j] ^= mix_from_scratch( scratchpad, idx )   // ASIC resistance
    state  = SHA256( state || mix_data || round )   // state chain

// 4. Verify stability basin (k perturbation probes)
(is_stable, metric) = verify_convergence_stability_basin( x_final, M, b, ... )

// 5. Compute commitment
commit = SHA256( MAGIC || "COMMIT" || header_core || seed || state || x || segments_root || cp_root || metric )
require  commit <= target   AND   is_stable == true
        

CX_SCRATCH_MB	`4096` // 4 GB memory-hard scratchpad (+ 4 GB dataset = 8 GB total mining memory)
CX_N	`32` // linear system dimension
CX_ROUNDS	`100,000` // sequential gradient iterations
CX_LR_SHIFT	`18` // learning rate = 1/(2^18)
CX_LAM	`100` // regularization parameter (λ)
CX_CHECKPOINT_INTERVAL	`6,250` // rounds/16, Merkle-committed
CX_STABILITY_K	`4` // perturbation probes per attempt
CX_STABILITY_GRADIENT_STEPS	`3` // refinement steps per probe
Scratchpad derivation	Sequential SHA-256 chain // epoch-keyed, mmap-friendly
Verification	Two-stage pipeline // cheap header check → full recompute

Stability Basin Verification

CONSENSUS-CRITICAL

A valid ConvergenceX proof must demonstrate that the solution x_final resides in a stable attractor basin. The verifier applies k deterministic perturbation probes and checks two acceptance rules per probe:

Local non-explosion	`d(t+1) <= d(t) + margin_eff` // per gradient step
Global contraction	`d_final * c_den <= d0 * c_num + margin_eff` // for large perturbations
Contraction ratio	`7/10` // epoch-invariant V1
Perturbation scale	`3` // uniform in [-scale, +scale]
Stability LR shift	`20` // lr_shift + 2 (more conservative)

DIFFICULTY ADJUSTMENT

cASERT bitsQ Retargeting

casert_next_difficulty()

CONSENSUS-CRITICAL

SOST implements cASERT bitsQ as the primary hardness regulator within the unified cASERT consensus-rate control system. Inspired by BCH's ASERT, the bitsQ controller performs per-block exponential difficulty adjustment in continuous Q16.16 log-space. Unlike legacy epoch-based retarget systems that wait for large windows, bitsQ corrects difficulty every single block with a 48-hour half-life and a per-block relative delta cap of 6.25% (1/16), producing smooth transitions and faster convergence to the target interval.

// Compute expected parent time from epoch anchor
expected_pt = anchor_time + (parent_idx - anchor_idx) * 600
td          = prev_time - expected_pt

// Exponential cASERT bitsQ: next_bitsq = anchor_bitsq * 2^(-td / halflife)
exponent = (-td * Q16_ONE) / CASERT_HALF_LIFE
shifts   = exponent >> 16        // integer part
frac     = exponent & 0xFFFF     // fractional part

// 2^frac via cubic polynomial (Horner's form, Q0.16)
factor   = Q16_ONE + polynomial_approx(frac)
result   = (anchor_bitsq * factor) >> 16
result   = result << shifts       // apply integer power-of-two

// Per-block relative delta cap: 6.25% (1/16)
new_powDiffQ = clamp( result, MIN_BITSQ, MAX_BITSQ )
        

TARGET_SPACING	`600` seconds // 10-minute target block time
bitsQ Half-Life	`43,200` seconds // 48 hours
MIN_BITSQ	`65,536` // Q16_ONE — minimum difficulty
MAX_BITSQ	`16,711,680` // 255 × Q16_ONE — maximum difficulty
Anchor rotation	Per-epoch // resets at epoch boundary blocks
Encoding	SOSTCompact Q16.16 // finer granularity than Bitcoin nBits
Arithmetic	Integer-only // no floating point, no consensus drift

EQUALIZER

cASERT Controller

casert_mode_from_chain()

EQUALIZER LAYER

cASERT (Contextual Adaptive Stability & Emission Rate Targeting) is the unified consensus-rate control system. It integrates three components: (1) bitsQ Q16.16 primary hardness regulator, (2) equalizer profiles E4–H9 that adjust ConvergenceX stability parameters, and (3) anti-stall recovery. The equalizer uses 5 EWMA signals to compute a weighted control signal U, which selects a profile from deep easing (E4) through baseline (B0) to maximum hardening (H9). H10–H12 are defined in code but capped at H9.

// Signals (all Q16.16 fixed-point)
r   = log2(TARGET_SPACING / dt)      // instantaneous log-ratio
L   = height - floor((time - GENESIS_TIME) / 600)  // schedule lag
S   = EWMA(r, alpha=32/256)          // 8-block short window
M   = EWMA(r, alpha=3/256)           // 96-block long window
V   = EWMA(|r - S|, alpha=16/256)    // 16-block volatility
I   = leaky integrator(L, rho=253/256) // ±100 cap

// Control signal (lag-dominant, prevents oscillation)
U = 0.05·r + 0.40·L + 0.15·I + 0.05·(S-M) + 0.02·V

H = clamp(U >> 16, E4=-4, H9=9)   // max hardening (H10-H12 defined but capped)

// Safety rules
if lag <= 0 (behind schedule): H = min(H, B0)  // never harden when behind
if chain.size() < 10:        H = min(H, B0)  // require 10 blocks

// Slew rate: ±1 profile level per block (prevents oscillation)
H = clamp(H, prev_H - 1, prev_H + 1)
        

E4 DEEP EASING

scale=1 · k=3 · margin=240 · steps=3
Maximum easing: widest margin, fewest stability probes. Only after 6h extra at B0.

E3–E1

scale=1 · k=3–4 · margin=240–200 · steps=3–4
Easing profiles. Only after 6h extra at B0.

B0 BASELINE

scale=1 · k=4 · margin=185 · steps=4
Default operating profile. Balanced stability test.

H1–H5

scale=1–2 · k=4–6 · margin=175–135 · steps=4–6
Progressive hardening. Tighter margin, more probes.

H6–H9 MAX

scale=2–3 · k=6–8 · margin=130–110 · steps=6–8
Maximum hardening. H10–H12 defined in code but capped at H9.

// Zone-based decay to B0 — mining only
// Activation: max(ahead × 600s, 7200s) — floor 2 hours
stall = now - last_block_time
threshold = max(ANTISTALL_FLOOR=7200, ahead × 600)

if stall >= threshold:
    // Zone decay rates (current level determines speed):
    // H9–H7: 600s/level (fast)     — 1800s total
    // H6–H4: 900s/level (medium)   — 2700s total
    // H3–H1: 1200s/level (slow)    — 3600s total
    // Decays to B0. Easing E1–E4 only after 6h extra at B0.
    H = zone_decay(H, stall - threshold)
        

Key design properties:
• 17 profiles E4(-4) through H12(+12); H10–H12 defined but capped at H9. Active range: E4–H9.
• Lag-dominant gains (60% of total signal) prevent oscillation between E4 and H9.
• Slew rate ±1/block ensures smooth profile transitions.
• Behind schedule → cap at B0 prevents hardening when blocks are slow.
• Anti-stall: zone-based decay to B0 (H9–H7: 600s/lvl, H6–H4: 900s/lvl, H3–H1: 1200s/lvl). Easing E1–E4 only after 6h extra at B0.

CASERT_H_MIN	`-4` // E4 (deep easing)
CASERT_H_MAX	`9` // H9 (max hardening; H10-H12 defined but capped)
K_R / K_L / K_I / K_B / K_V	`0.05 / 0.40 / 0.15 / 0.05 / 0.02` // lag-dominant (60%)
SLEW_RATE	`±1` // profile level per block
ANTISTALL_FLOOR	`7200` // 2 hours minimum before decay
ANTISTALL_DECAY	`zone-based` // H9-H7: 600s/lvl, H6-H4: 900s/lvl, H3-H1: 1200s/lvl
Safety rules	Behind schedule → cap B0 · <10 blocks → cap B0

ENCODING & VALIDATION

SOSTCompact & MTP

SOSTCompact Q16.16

CONSENSUS

Difficulty is encoded as a Q16.16 fixed-point value in block headers, providing finer granularity than Bitcoin's nBits compact format. Deterministic bidirectional conversion between compact and full 256-bit target ensures consensus-safe retarget math and bit-for-bit reproducibility.

Format	Q16.16 fixed-point // uint32
GENESIS_BITSQ	`765,730` (11.6841 in Q16.16, calibrated)
MIN_BITSQ	Easiest allowed target
MAX_BITSQ	Hardest allowed target

Timestamp Discipline

CONSENSUS

Block timestamps are validated against Median Time Past (MTP) to prevent manipulation affecting difficulty. Combined with cASERT anchoring, this creates stable timing even under individually noisy blocks.

MTP_WINDOW	`11` blocks
MAX_FUTURE_DRIFT	`600` seconds
Rule: ts > MTP	Strict monotonicity
Rule: ts ≤ now + drift	Bounded acceptance

CHAIN PARAMETERS

Consensus Constants

Network Configuration

IMMUTABLE

MAINNET_GENESIS_UTC	`1773597600` // 2026-03-15 18:00:00 UTC
BLOCKS_PER_EPOCH	`131,553` // ≈2.5 years (Feigenbaum α)
TARGET_SPACING	`600` seconds // 10-minute blocks
MAGIC	`CXPOW3` + `NETWORK_ID` // unique wire identifier
NETWORK_ID	`SHA256("SOST/CONVERGENCEX/mainnet")[:4]`
Block header	`MAGIC + "HDR2" + core(72B) + cp_root(32B) + nonce(4B) + extra(4B)`
Block ID	`SHA256( header \|\| "ID" \|\| commit )`
Block key (anti-grind)	`SHA256( prev_hash \|\| "BLOCK_KEY" )` // tip-bound only
Chainwork	Bitcoin-style: `floor(2^256 / (target + 1))` per block. Cumulative = sum of all block work.
Chain selection	Best chain by cumulative work, not longest chain. The chain with the highest total accumulated work wins. This prevents attacks using many easy blocks to outpace a shorter chain with more real work. Same approach as Bitcoin.
Fork resolution	Atomic. If a better chain is found, the node disconnects current blocks, connects the new chain, and recovers orphaned transactions to the mempool. If any block in the new chain fails validation, the entire reorganization is aborted and the original chain is restored. MAX_REORG_DEPTH = 500 blocks (~3.5 days).

HARDWARE

System Requirements

Mining is memory-hard (ASIC resistant), but verification is lightweight (anyone can run a node). The miner must build and hold the full 4 GB dataset and 4 GB scratchpad in memory to solve the ConvergenceX puzzle. The node only verifies the compact Transcript V2 proof — SHA256 hashes and merkle checks, no dataset required.

FULL NODE

~500 MB RAM

RAM	~500 MB (no dataset, no scratchpad)
CPU	Any modern processor
Disk	Minimal (~1 KB per block)
System	2 GB total, any OS
Verify speed	~0.2 ms per block (Transcript V2)

MINER

8 GB RAM

RAM	8 GB min (4 GB dataset + 4 GB scratchpad)
CPU	Modern multi-core (L3 cache helps)
Disk	Minimal
System	16 GB total recommended
Per attempt	100K rounds + dataset/scratchpad I/O

DESIGN

Core Principles

DETERMINISTIC

Zero floating point in consensus. Integer-only arithmetic guarantees identical results on every architecture. Same input → same output, unconditionally.

CPU-ORIENTED

8 GB total mining memory (4 GB scratchpad + 4 GB dataset) with 100,000 sequential iterations. Node validation requires only ~500 MB. Throughput is bounded by memory bandwidth and latency, not raw compute — making ASIC development economically impractical.

ADAPTIVE

Per-block cASERT retargeting with bitsQ + equalizer. The chain converges to its target interval within hours, not days. No retarget whiplash.

LAUNCH-SAFE

cASERT degrades stability requirements under thin hashrate, ensuring the chain remains mineable and stable from genesis. Security grows with the network.

VERIFIABLE

Transcript V2 verification: cheap header/target checks for fast sync, 11-phase segment + round witness verification (~0.2ms) for standard validation, full ConvergenceX recomputation for deep validation. Merkle-committed segments and checkpoints enable SPV-friendly proof structures.

ANTI-GRINDING

Block key derives from chain tip only. All miners solve the same linear system for a given tip — per-attempt uniqueness comes from nonce/extra_nonce, not from the challenge itself.

PoW COMPARISON

Bitcoin vs Monero vs SOST

Proof-of-Work Architecture Comparison

Property	Bitcoin (SHA-256d)	Monero (RandomX)	SOST (ConvergenceX)
PoW verify cost	~1μs	~50ms	~5–30s
Memory (mining)	Negligible	256MB–2GB	8GB (4GB scratchpad + 4GB dataset)
Memory (node)	Negligible	~256MB	~500MB (no scratchpad/dataset)
ASIC resistance	None	High	Very high
Full sync time	~hours	~days	~weeks
Fast sync time	~minutes	~hours	~minutes
Verification layers	4	4	8
Difficulty adjust	Every 2016 blocks	Every block (LWMA)	Every block (cASERT exp.)
Block time	600s	120s	600s
Anti-stall	None	LWMA	cASERT Decay (2h floor, 1 level/20min)
Anti-acceleration	None	LWMA	cASERT Equalizer E4–H9 (±1/block)
Emission	Halving / 210K blocks	Tail emission	Smooth exp. decay (q=e^-¼)
Max supply	21M BTC	Infinite	~4,669,201 SOST
Constitutional reserve	None	None	25% gold + 25% PoPC

ConvergenceX Consensus Engine

Architecture Pipeline

ConvergenceX PoW

cASERT bitsQ Retargeting

cASERT Controller

SOSTCompact & MTP

Consensus Constants

System Requirements

Core Principles

Bitcoin vs Monero vs SOST

ConvergenceX
Consensus Engine