HISTORICAL ECONOMICS ON THIS PAGE. Text below describing a 50/25/25 split, a Gold Funding Vault emission stream or a PoPC Pool share is true only for blocks below #25,000. Since V15 the split is 50% miner / 50% DTD and the gold and PoPC emission shares are zero; the DTD is permissionless (no PoPC bond required). Current: protocol spec · operator guide.
TECHNOLOGY

ConvergenceX
Consensus Engine

A deterministic, CPU-oriented, security-first consensus engine combining gradient-descent proof-of-work, per-block adaptive difficulty, and a real-time stability overlay. Designed for predictable issuance, controlled growth, and resistance to chaotic retarget behavior.

CONSENSUS | Integer-only arithmetic · Zero floating point · Deterministic across all nodes
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 m[0..3] = scratchpad[ idx(state, r) ] // 4 state-dependent reads (4 GB) m[0..1] ^= program( dataset[ state ], r ) // per-block program on the 4 GB dataset (state-indexed since #7,000) x[j] ^= / += m[k] // mix into 4 coordinates state = SHA256( state || m || x[j] || r ) // the next round needs this result // 4. Verify stability basin (k probes x steps, set by the active Equalizer profile) (is_stable, metric) = verify_convergence_stability_basin( x_final, M, b, ... ) // 5. Compute commitment commit = SHA256( MAGIC || "COMMIT" || header_core || seed || state || x || cp_root || segments_root || metric || profile_index ) 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
Stability probes (k) 1–20 // set by the active Equalizer profile (B0 = 4, E7 = 1, H35 = 20)
Refinement steps per probe 1–20 // set by the active Equalizer profile (B0 = 4, E7 = 1, H35 = 20)
Scratchpad derivation Sequential SHA-256 chain // epoch-keyed, mmap-friendly
Verification Two-stage pipeline // cheap header check → full recompute
SbPoW (since #7,100) Signature-Bound PoW // every valid block carries a signature from the miner identity key over the header — pools that delegate work without sharing the key are cryptographically self-defeating
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 1–2 // uniform in [-scale, +scale]; set by the Equalizer profile (E7–H4 = 1, H5–H35 = 2)
Stability LR shift 20 // lr_shift + 2 (more conservative)
Strong ASIC resistance by design
PROTOCOL PROPERTY

ConvergenceX is intentionally hostile to fixed-function mining hardware. Unlike Bitcoin's massively parallel SHA-256d search, each ConvergenceX attempt combines a large memory working set, state-dependent memory access, a program derived from the previous block and 100,000 sequential rounds. The output of one round decides which memory the next round reads, so a single attempt cannot be split into independent pieces.

~8 GB
working memory
4 GB dataset + 4 GB scratchpad
100,000
sequential rounds
per attempt
32×32
integer linear system
gradient descent
bitsQ + Equalizer
numeric target +
structural work profile

Bitcoin ASIC

80-byte header
  ↓ SHA-256d    nonce 0
  ↓ SHA-256d    nonce 1
  ↓ SHA-256d    nonce 2
  …
trillions of independent hashes / s
(every nonce can be tried in parallel)

ConvergenceX attempt

~8 GB working set
  ↓ round 1 → state
  ↓ round 2 → state   (reads chosen by state)
  …
  ↓ round 100,000
stability basin   (Equalizer profile)
  ↓ commit ≤ target   (bitsQ)
ConvergenceX does not try to beat ASICs at SHA-256. It changes the computational problem.

A Bitcoin ASIC is extraordinarily efficient because its silicon is built for one narrow task: hashing 80-byte Bitcoin headers with SHA-256d while sweeping a nonce. It takes header fields in and only reports nonces that pass a target — it does not run programs, hold gigabytes of state or return intermediate results. ConvergenceX uses single SHA-256 as the link between memory-bound, state-dependent steps, so fixed-function Bitcoin SHA-256d ASICs cannot directly mine ConvergenceX, and Bitcoin TH/s cannot be converted into ConvergenceX attempts per second.

Difficulty is controlled by two complementary consensus mechanisms: bitsQ regulates the numerical target the commit must meet, and the Equalizer (43 profiles, E7–H35) regulates the structural work profile — how many perturbation probes and refinement steps a valid stability proof must survive. The profile index is bound into the commit, so a miner cannot use an easier profile than consensus requires.

This does not claim that specialized hardware can never be built. ConvergenceX is designed to substantially reduce the advantage of fixed-function ASIC specialization: a useful accelerator would have to implement the actual workload — low-latency random access to gigabytes of memory, the sequential dependency chain and the per-block program — rather than reuse conventional Bitcoin ASIC hashrate.

Sources (public, Neob1844/sost-core): src/pow/convergencex.cpp (attempt loop, state update, commit), include/sost/params.h (CX_N, CX_ROUNDS_M, CX_SCRATCH_M, CASERT_PROFILES), src/pow/casert.cpp (bitsQ, Equalizer).

DIFFICULTY CONTROL

One Proof of Work, two dials

CURRENT MAINNET RULE · VERIFIED AGAINST THE NODE SOURCE

One Proof of Work, two dials: ConvergenceX + bitsQ + Equalizer

SOST keeps blocks at about 600 seconds with two independent controls acting on the same Proof of Work. One decides how rare a winning result must be; the other decides how demanding each attempt is. Every node recomputes both and rejects a block that declares anything else.

CONVERGENCEX the work of every attempt ~8 GB (4 GB dataset + 4 GB scratchpad) · 100,000 rounds 32×32 integer problem · state-dependent memory per-block program · chained SHA-256 │ ┌──────────────┴──────────────┐ │ │ bitsQ EQUALIZER numeric difficulty structural hardness │ │ how rare must the which ConvergenceX profile commit be to win? must each attempt pass? commit ≤ target(bitsQ) E7 … B0 … H35 (43 profiles) │ │ └──────────────┬──────────────┘ ▼ TARGET ≈ 600 s
CONVERGENCEX
Decides what work a miner must run: about 8 GB of memory, 100,000 sequential rounds over a 32×32 integer problem, memory reads that depend on the running state, a program generated for each block, and a stability check. The result is a 32-byte commit.
bitsQ
Decides how exceptional the commit must be. A block is valid only if commit ≤ target(bitsQ). Blocks too fast → bitsQ up, target down, harder. Too slow → bitsQ down, target up, easier. Q16.16 fixed point, integer-only.
EQUALIZER
Does not touch the target. It selects one of 43 profiles (E7 easing … B0 normal … H35 maximum hardening) that sets the stability parameters every ConvergenceX attempt must satisfy.
THE IDEA THAT MATTERS
SOST keeps two different things apart: the difficulty of hitting a winning result (bitsQ) and the cost of making one attempt (Equalizer). Bitcoin has only the first: one SHA-256d attempt always costs the same, and only the target moves. This does not make SOST "better than Bitcoin" by itself; it is a richer control architecture for a young network.

bitsQ — the exact current rule (block 5,270+)

avg = average of the last 288 block intervals (each clamped to 1 s … 1 day) dev = avg - 600 s |dev| ≤ 15 s no change dead band |dev| ≤ 60 s at most 0.5 % per block |dev| ≤ 120 s at most 1 % |dev| ≤ 240 s at most 2 % |dev| > 240 s at most ≈3.03 % (prev / 33) inside the cap the step is proportional: prev × (|dev| - 15) / 2400 Slingshot (block 7,350+), same block, if the previous block was slow: >20 min -6.5 % · >30 min -12.5 % · >1 h -25 % · >2 h -37.5 % · >3 h -50 %

Equalizer — the exact current rule (direct lag map, block 5,323+)

lag = (h - 1) - floor((prev.time - genesis) / 600) positive = chain AHEAD of schedule lag ≤ 0 → at most B0 never harden when behind schedule lag > 0 → H(lag), up to H35 up immediately; down by at most max(1, elapsed/600) levels per block Easing profiles (E1…E7) come only from: V12 cascade (block 7,350+): this block already took ≥ 540 s drop 1 · 3 · 6 · 10 · 15 · 21 · 28 levels at 540 · 600 · 660 · 720 · 780 · 840 · ≥900 s anti-stall: no block for 60 min → step down toward B0, then toward E7 after 6 more hours The Equalizer changes only stab_scale / stab_steps / stab_k / stab_margin — never bitsQ. Validators recompute the profile; the block's declared profile must match exactly.

Worked example

1. The chain is 4 blocks ahead of the 600 s schedule → lag = 4 → profile H4 Each attempt must pass stricter stability parameters. bitsQ is unchanged. 2. The next block has already taken 11 minutes (660 s) → cascade drops 6 levels H4 → E2 for this block only: the attempt becomes cheaper, the chain catches up. 3. The last 288 blocks averaged 640 s → dev = +40 s proportional step = 25/2400 ≈ 1.04 %, capped at 0.5 % → target slightly easier.
IN SIMPLE TERMS
ConvergenceX is the exam. bitsQ is the pass mark. The Equalizer is how long and hard each exam paper is. If students finish too fast, SOST can raise the pass mark (bitsQ) and, when the class is clearly ahead of schedule, hand out a harder paper (Equalizer). If they are late, the paper gets easier first, and the pass mark follows the 288-block average.

Historical designs — the five-signal PID/EWMA equalizer used before block 5,323, the H13/H20 ceilings of earlier versions, and the pre-genesis "L1–L6" level concept — are not current rules. They are kept for reference in the historical appendix only.

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. The bitsQ controller performs per-block 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. Historical: anchor-based exponential with 48-hour half-life (cap 6.25%, before block 1,450), then 24-hour half-life (V2, blocks 1,450–5,174) and 12.5% delta cap. Current (V5, block 5,175+): avg288-based — compares average of last 288 block intervals against 600s target, replacing the anchor-based exponential. Dynamic cap (block 5,270+): 0% dead band ±15s, then 0%/0.5%/1.0%/2.0%/≈3.03% max based on deviation. Median288 override (blocks 5,260–5,269, ±30 s dead band) is HISTORICAL; removed from consensus at block 5,270.

// V5 (block 5175+): avg288-based retarget avg_interval = average(last 288 block intervals) deviation = avg_interval - 600 // compare against target // Dynamic cap (block 5270+): tiered by deviation magnitude // |deviation| ≤ 15s: 0% (dead band) // |deviation| ≤ 60s: 0.5% max // |deviation| ≤ 120s: 1.0% max // |deviation| ≤ 240s: 2.0% max // |deviation| > 240s: ≈3.03% max (prev/33) cap = dynamic_cap(deviation) // Median removed from consensus (block 5,270+) // V12 slingshot (block 7,350+), on current block elapsed: >1200s -6.5%, >1800s -12.5%, // >3600s -25%, >7200s -37.5%, >10800s -50% new_powDiffQ = clamp( adjusted, MIN_BITSQ, MAX_BITSQ )
TARGET_SPACING 600 seconds // 10-minute target block time
bitsQ Model V5 (block 5,175+): avg288-based // historical V2: 24h half-life exponential
MIN_BITSQ 65,536 // Q16_ONE — minimum difficulty
MAX_BITSQ 16,711,680 // 255 × Q16_ONE — maximum difficulty
Anchor rotation Per-epoch (historical V1/V2 only) // V5: no anchors, uses avg288
Encoding SOSTCompact Q16.16 // finer granularity than Bitcoin nBits
Arithmetic Integer-only // no floating point, no consensus drift
EQUALIZER

cASERT Controller

cASERT Equalizer (direct lag map)
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) the Equalizer with 43 profiles (pre-V12 #5,750..#7,349: 21 active E7–H13, 22 reserved H14–H35; V12 #7,350..#11,999: 28 active E7–H20, 15 reserved H21–H35; V13 #12,000+: 43 active E7–H35, 0 reserved) that adjust ConvergenceX stability parameters, and (3) anti-stall recovery. Ceiling: H35 since V13 (#12,000+) — historically H13 pre-V12 / H20 V12 (#7,350..#11,999).

CONVERGENCEX DIFFICULTY CONTROL = bitsQ + Equalizer. bitsQ regulates the numeric difficulty of the target; the Equalizer regulates the structural cost profile of each ConvergenceX attempt under the cASERT rules. Both are recomputed and verified by every node.

CURRENT MAINNET RULE: target 600 s · bitsQ Q16.16 recomputed every block · dead band ±15 s · steps 0.5% / 1.0% / 2.0% / ≈3.03% (block 5,270+) · Equalizer: 43 profiles E7–H35, direct lag map (block 5,323+), anti-stall at 60 min, V12 triangular cascade (block 7,350+).

lag = (h - 1) - floor((prev.time - GENESIS_TIME) / 600) // positive = chain AHEAD target = (lag <= 0) ? B0 : min(lag, ceiling) // ceiling H35 (#12,000+) // Up (hardening): immediate. Down (easing): at most max(1, elapsed/600) levels per block. // lag <= 0 → at most B0. // V12 triangular cascade (block 7,350+), on current block elapsed time: if elapsed >= 540: n = min(1 + (elapsed - 540) / 60, 7) drop = n(n+1)/2 // 1,3,6,10,15,21,28 levels at 540/600/660/720/780/840/≥900 s H = max(H - drop, E7) // Validator recomputes H; the declared profile_index must equal it. // The Equalizer changes only stab_scale/stab_steps/stab_k/stab_margin — never bitsQ.
HISTORICAL APPENDIX — pre-#5,323 five-signal PID/EWMA equalizer (NOT the current rule)

HISTORICAL (before block 5,323): the equalizer used 5 EWMA signals (PID-style) to compute a weighted control signal U. This controller is bypassed since block 5,323 and is shown below for reference only.

// 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, E7=-7, ceiling) // ceiling: H13=13 pre-V12 / H20=20 V12 (#7,350+) // 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 (V6, block 5,000+) H = clamp(H, prev_H - 1, prev_H + 1) // prev_H from stored profile_index in BlockMeta (V3.1+)
E7 DEEPEST EASING
scale=1 · k=1 · margin=200 · steps=1
Deepest easing / relief valve target (block 5,750+). Compute=1. Only after relief or extended stall.
E6–E1
scale=1 · k=1–4 · margin=195–170 · steps=2–4
Extended easing profiles (E7-E5 added block 5,750). Reached via the V12 cascade or anti-stall.
B0 BASELINE
scale=1 · k=4 · margin=165 · steps=4
Default operating profile. Balanced stability test.
H1–H5
scale=1 (H1–H4) / 2 (H5) · k=4–6 · margin=160–140 · steps=5–6
Progressive hardening. Tighter margin, more probes.
H6–H35 HARDENING
scale=2 · k=5–20 · margin=135–115 · steps=6–20
Progressive hardening. V13 (#12,000+): all of H6–H35 active, H35 ceiling (k=20, steps=20, margin=115). Historical: H13 ceiling pre-V12 (#5,750..#7,349); H20 ceiling V12 (#7,350..#11,999). Relief: current V12 triangular cascade (#7,350+, 1/3/6/10/15/21/28 levels from 540 s, floor E7) — historical: V10 granular drop of 1 level per 60 s from 600 s (#6,700..#6,999), V11 (#7,000 linear / #7,100 triangular cap 21), V8 single E7 cliff at 605 s.
// Zone-based decay to B0 — mining only // Activation: 3,600s (60 min) — current (V5 #4,300+); 7,200s was HISTORICAL (before #4,300) stall = now - last_block_time threshold = ANTISTALL_FLOOR_V6C = 3600 // 60 min (current) if stall >= threshold: // Zone decay rates (current level determines speed): // First drop immediate, then: // H≥7: 600s/level (fast) // H6–H4: 900s/level (medium) // H3–H1: 1200s/level (slow) // Decays to B0. After 6h extra at B0: -1 level per 1800s down to E7. H = zone_decay(H, stall - threshold)

Key design properties:
• 43 profiles. Pre-V12 (#5,750..#7,349): 21 active A: E7–H13, 22 reserved R: H14–H35. V12 (#7,350..#11,999): 28 active E7–H20, 15 reserved H21–H35. V13 (#12,000+): 43 active E7–H35, 0 reserved (full range live). H35 max profile, H10–H35 margin=115. Equalizer is emergency-only.
• Current selector: direct lag map (block 5,323+) — up immediate, down at least 1 level/block. HISTORICAL (pre-#5,323): lag-dominant PID/EWMA gains and slew rate ±1/block (V6, block 5,000+).
• Behind schedule → cap at B0 prevents hardening when blocks are slow.
• Anti-stall: 3,600s (60 min, current since #4,300; 7,200s HISTORICAL before #4,300), first drop immediate then zone-based decay to B0 (H≥7: 600s/lvl, H6–H4: 900s/lvl, H3–H1: 1200s/lvl). After 6h extra at B0: −1 level per 1,800s down to E7. Relief: V12 triangular cascade (#7,350+, up to 28 levels, floor E7) — historical: V10 granular drop 1 level/60 s from 600 s (#6,700..#6,999), V8 single E7 cliff at 605 s.

CASERT_H_MIN -7 // E7 (deepest easing / relief valve target)
CASERT_H_MAX 35 // H35 ceiling since V13 (#12,000+), all 43 profiles active. Historical: H13 pre-V12, H20 V12 (#7,350..#11,999).
K_R / K_L / K_I / K_B / K_V 0.05 / 0.40 / 0.15 / 0.05 / 0.02 // HISTORICAL (PID/EWMA, bypassed since #5,323)
SLEW_RATE ±1 // HISTORICAL (V6, blocks 5,000–5,322); current: up immediate, down ≥1 level/block
ANTISTALL_FLOOR_V6C 3600 // 60 min before decay (current; 7200 HISTORICAL before #4,300)
ANTISTALL_DECAY zone-based // H≥7: 600s/lvl, H6-H4: 900s/lvl, H3-H1: 1200s/lvl; after 6h at B0: -1/1800s to E7
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 30 seconds // current since V13 (#12,000); HISTORICAL: 600 s before #6,550, 60 s #6,550–#11,999
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): a node refuses a reorganization that would disconnect more than 500 blocks of its own active chain, even if the other chain has more work. This protects the history held by that node; it is not a global finality guarantee. SACS V2 (which would turn this limit into an alarm for forks after its activation) was prepared for #30,000 but deferred on 8 October 2026, before that height: it is not active on mainnet.
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)
CPUAny modern processor
DiskMinimal (~1 KB per block)
System2 GB total, any OS
Verify speed~0.2 ms per block (Transcript V2)
Full sync~25 min genesis → tip (measured 25m06s to #28,077, V30000)
MINER
8 GB RAM
RAM8 GB min (4 GB dataset + 4 GB scratchpad)
CPUModern multi-core (L3 cache helps)
DiskMinimal
System16 GB total recommended
Per attempt100K 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 — substantially reducing the advantage of fixed-function ASICs.
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.
SOVEREIGN VALUE STACK

E2E, SOST DEX, PoPC Contracts

HISTORICAL design (superseded)
Superseded. The gold-escrow / Model-B DEX described below is a retired design kept for reference. Public atomic swaps are not currently authorized (the HTLC atomic swap contracts were retired after security finding H-01); a SOST-layer DEX activates at #30,000 (admin-gated under S14 restricted developer mode, public access disabled). PoPC is now a single native-SOST bond — no gold escrow and no PoPC DEX. The tables that follow document the original architecture only.
E2E Encrypted Coordination
Message typesSigned offers, acceptances, cancellations, settlement notices
TransportOff-chain, replay-resistant, cryptographically authenticated
IntegrityCanonical hashes, deterministic serialization
Design principleNot chat — private economic coordination between sovereign counterparties
DEX & Settlement Layer for Tokenized Gold
Trading pairsSOST ↔ XAUT/PAXG and native precious-metal positions
ArchitecturePeer-to-peer, thin-chain / fat-edge — Ethereum as minimal onboarding rail, SOST as sovereign center
Deal engineState machine with watchers and settlement daemon
Position registryModel B (transferable escrow) and Model A (reward rights)
PoPC Contract Layer
MechanismTimelocked collateral for self-custodied gold participation
GuaranteesNo admin key, no proxy, no pause, no emergency withdrawal
PhilosophyConstitutional and immutable — code is the only authority
Base contractSOSTEscrow.sol
SECURITY

Post-Quantum Security

SOST uses the same secp256k1 ECDSA signatures as Bitcoin. For the post-quantum era, SOST is studying ML-DSA (NIST FIPS 204) as the leading candidate — a candidate, not adopted. The address prefix sost2 is reserved (not active) for post-quantum addresses. This is research direction, not a committed deployment schedule. SHA-256 hashing remains quantum-safe.

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~0.2 ms proof check (Transcript V2) · full recompute only for deep validation
Memory (mining)Negligible256MB–2GB8GB (4GB scratchpad + 4GB dataset)
Memory (node)Negligible~256MB~500MB (no scratchpad/dataset)
ASIC resistanceNoneHighHigh by design (memory-hard, sequential)
Full sync time~hours~days~25 min — measured: genesis → #28,077 in 25m06s, tip + 5 checkpoint hashes matched the live chain (V30000 release); checkpointed blocks skip only the full ConvergenceX recompute (--full-verify forces it)
Fast sync time~minutes~hoursnot needed — the full verified sync above is the normal path
Verification layers448
Difficulty adjustEvery 2,016 blocks (~2 weeks)Every block (LWMA)Every block (cASERT bitsQ avg288 + Equalizer direct lag map)
Response speed2-week lag~720-block EWMA (~24h)288-block average (bitsQ) + per-block lag map (Equalizer)
Halflife~2 weeks (fixed)~720 blocks (~24h)V5: avg288-based (historical: 48h half-life, then 24h from #1,450)
Max change/blockN/A (bulk adjust)EWMA smoothedDynamic cap #5,270+: 0% within ±15 s, then 0.5/1.0/2.0/≈3.03%
Control signals1 (time delta)1 (timestamp EWMA)2 (288-block average interval; schedule lag). HISTORICAL pre-#5,323: 5-signal PID/EWMA
Dynamic profilesNone (1 formula)None (1 formula)43 profiles (V13 #12,000+: all 43 active E7–H35, 0 reserved)
Math typeFloating-point128-bit integerQ16.16 fixed-point (zero float)
Block time600s120s600s
Anti-stallNoneLWMAZone-based decay to B0 at 3,600s (60 min) stall, then down to E7 after 6h; V12 triangular cascade + slingshot relief
Anti-accelerationNoneLWMAcASERT Equalizer E7–H35 since V13 (#12,000+) (direct lag map #5,323+: up immediate, down ≥1 level/block)
EmissionHalving / 210K blocksTail emissionSmooth exp. decay (q=e-¼)
Max supply21M BTCInfinite~4,669,201 SOST
Constitutional reserveNoneNoneNone since V15 (#25,000): 50% miner / 50% DTD (pre-V15: 25% gold + 25% PoPC)
SECURITY & INCENTIVES

SOST vs Bitcoin vs Ethereum

SECURITY MODELS · SIMPLE COMPARISON WITH EXAMPLES

SOST vs Bitcoin vs Ethereum: who secures the chain, and how are they paid?

Two different questions are mixed up all the time: how a protocol is designed, and how decentralized its real network is. Bitcoin and Ethereum are remarkable not only for their design but because thousands of independent people and organisations run them, verify them and have real money at stake, year after year. SOST shares the design principles of permissionless consensus; it does not yet have that maturity.

BITCOIN · WORK
SHA-256d Proof of Work on specialised ASICs. A block about every 10 minutes; difficulty retargets every 2,016 blocks. The block finder (in practice usually a pool) takes the whole subsidy — 3.125 BTC since the 2024 halving — plus fees. Full nodes are not paid, but each one verifies every rule on its own.
ASIC + electricity → SHA-256d attempts → hash < target → block → BTC
ETHEREUM · STAKE
Proof of Stake since 2022. A solo validator deposits 32 ETH. Time runs in 12-second slots; 32 slots = one epoch (6.4 min). Validators vote (attest) about once per epoch and are occasionally chosen to propose a block. Rewards come from issuance plus, for proposers, priority fees and MEV; the base fee is burned. Equivocation is slashed.
32 ETH deposit → validator → votes + occasional block → ETH
SOST · WORK + PARTICIPATION
ConvergenceX Proof of Work on ordinary CPUs and RAM. A block about every 10 minutes; bitsQ and the Equalizer adjust every block. The block reward is split 50% to the finder and 50% to the DTD draw among recent miners. A separate Jackpot every 288 blocks rewards miners who also run a bound node.
CPU + RAM + electricity → ConvergenceX → commit ≤ target → block → 50% + DTD

The same day, three ways — worked examples

BITCOIN A miner with 1 % of the network hashrate finds on average 1 % of ~144 daily blocks ≈ 1.4 blocks/day, each worth 3.125 BTC + fees. Nothing else. Running a node earns nothing, but it lets you reject any block that breaks the rules — even one from the largest pool. ETHEREUM A validator with 32 ETH attests roughly once every 6.4 minutes and, now and then, is selected to propose a block (bigger reward). The yearly rate is a few percent and moves with the total amount staked. Offline: small penalties, not slashing. Signing two conflicting blocks or votes: slashed — part of the 32 ETH is destroyed. SOST Epoch-0 subsidy is 7.85100863 SOST per block. Miner A finds a block with no fees: A, the finder, receives 3.92550432 SOST (odd stock goes to the miner) DTD half 3.92550431 SOST The DTD half goes to ONE eligible recent miner drawn uniformly — it may be A, or it may be B, a much smaller miner. Every 288 blocks the DTD Jackpot (100 SOST base, up to 500 with rollover, paid from the frozen historical reserve, no new coins) goes to a miner who has ≥ 3 PoW blocks in the last 2,016, an active NODE_BIND and the heartbeat history; the draw is weighted by PoW blocks.

Side by side

BitcoinEthereumSOST
SecurityProof of Work (SHA-256d)Proof of StakeProof of Work (ConvergenceX)
What you commitASICs + energy32 ETH (solo validator)CPU + RAM + energy; no deposit
Block producerwhoever finds the PoWvalidator selected per slotwhoever finds the PoW
Votes / attestationsnoyesno
Slashingnoyesno
Direct reward100% subsidy + fees to the finderissuance; proposer also gets fees/MEV50% of subsidy + fees to the finder
Extra reward—occasional block proposalDTD every block · Jackpot every 288 blocks
Are nodes paid?noonly as validatorsno — a bound node is a Jackpot condition, never a multiplier
Sybil resistancehashratestaked ETHreal PoW blocks (SbPoW-signed identities)
Coins locked to take partnoyesno
Finalityprobabilistic (more blocks = safer)explicit, after ~2 epochs (~13 min)probabilistic
Difficulty adjustmentevery 2,016 blocksn/aevery block: bitsQ + Equalizer
Long-term security budgetfees after the last halvingissuance + feesfees only after the cap (no tail emission); under current rules half of fees also go to DTD

Why SOST does not pay nodes simply for existing

Paying every node invites a Sybil attack: one person rents 10,000 cheap servers and claims 10,000 rewards. The Internet cannot tell 100 IPs that are 100 people from 100 IPs that are one person. Jackpot V2 therefore uses the node only as a door, and real PoW as the weight:

1 miner · 100 nodes · 100 PoW blocks → weight 100 1 miner · 1 node · 100 PoW blocks → weight 100 1 miner · 5 nodes · 2 PoW blocks → not eligible (minimum 3) Creating nodes adds nothing. Doing work does.

Normal DTD today: an address must have mined in the last 288 blocks; addresses that mined any of the previous 6 blocks are skipped (with a fallback if that would leave nobody); the draw is uniform among the eligible, not proportional to hashrate. An anti-dominance rule (an address with ≥10% of the last 288 blocks is skipped) exists but switches on only when at least 11 distinct miners are active — so with today's small miner set it is not in effect. Jackpot V2 has no cooldown and no anti-dominance.

The honest test of decentralization: what can you switch off?

BITCOIN
Switch off bitcoin.org, the largest exchanges, the largest pool, GitHub and a thousand nodes: blocks keep coming. That is the standard.
ETHEREUM
Switch off ethereum.org, the Foundation, a large RPC provider, a major staking service or one client implementation: with enough remaining validators, the chain continues.
SOST TODAY
The project still provides key infrastructure (seed nodes, the public explorer and RPC, release distribution), only a few independent operators exist, and two addresses produced the last 288 blocks. The goal is that switching off everything run by SOSTCore changes nothing for the chain. We are not there yet.
PropertyBitcoinEthereumSOST (goal, if reached)
Permissionless consensusyesyesyes (today too)
Your own node verifies all rulesyesyesyes (today too)
Home hardware competitive in block productionno (ASICs)node yes; validating needs 32 ETHthe design goal — not yet proven under adversaries
Client diversitymoderatevery highone implementation today
Independent operatorsenormousenormousmust grow a lot
Years under attack~17~11months
Dependence on the creatornonevery lowgoal: none
IN ONE SENTENCE EACH
Bitcoin is minimalist decentralized money: it does few things and does them with extraordinary resistance. Ethereum is decentralized computation: it accepts much more complexity to run programs, tokens and markets. SOST aims to be Proof-of-Work money on a Bitcoin-like base (UTXO, 10-minute blocks), with ConvergenceX for broad CPU mining, per-block difficulty control, and DTD incentives that reward work and node participation — without turning into a staking chain. There is no "lock SOST and earn" product, by design.
WHAT CANNOT BE WRITTEN IN C++
ConvergenceX, bitsQ and the Equalizer can build a good architecture. The final decentralization is not in the code: it comes from independent people running that code without needing us. ASIC resistance by memory hardness is a design goal that has to survive years of adversaries; it is not a proven fact.
// BEACON

Beacon — Advisory Channel

Signed operator notices, propagated between nodes. Advisory only. Does not affect mining rewards, block validity, chain selection, transaction validation, wallet balances, PoPC, Gold Vault, or consensus.

Phase II-A — local notices

Each node reads notices.json on startup. ECDSA-SHA256 signature verification against a hardcoded operator pubkey. Failure modes (bad signature, wrong network, expired, malformed) are silent drops. Active at V13_HEIGHT (12,000).

Phase II-B — threshold + revocation

Adds N-of-M threshold signatures (default 3-of-5), revocation by notice ID (only threshold-signed notices can revoke), and an optional mirror_url metadata field (never fetched by the node). Active at V13_HEIGHT.

Phase III — P2P gossip

Nodes gossip verified notices via a BCNN dispatcher with hard limits: 4 KB max notice, 32-notice LRU dedup cache, 8 notices/peer/min rate limit. Bad-signature notices are silently dropped; oversized/malformed/rate-limit hits earn peer misbehavior. Active at V13_HEIGHT.

Hard invariant. No Beacon code path links into block validation, mining validity, or chain commit. Beacon cannot reject, invalidate, or affect the canonical chain. Rollback is a single-line constant revert (BEACON_P2P_ACTIVATION_HEIGHT to INT64_MAX in include/sost/params.h).