⚠ V13 / V14 SCOPE UPDATE — REVISION TO v4.6 IN PROGRESS. Whitepaper v4.6: the current-state summary above and the correction banners are current (October 2026); the sections below remain the v4.5 base architecture (March 2026, consensus, monetary policy, four pillars), with each delta noted inline. It predates the 2026-05-18 V13 scope decisions and predates the V13 RC1 release. For the canonical current scope, read docs/V13_PUBLIC_SCOPE_UPDATE.md, docs/V13_GOLD_VAULT_GOVERNANCE_GATES.md, docs/V13_POPC_ESCROW_AUTO_ACTIVATION_GAPS.md and docs/V13_DTD_FLIP_12100_AUTOMATIC.md. The four critical updates relative to v4.5 are:
  1. V13 confirmed at block 12,000 — full cASERT equalizer range E7-H35 (not the H20 ceiling described in §PILLAR 1 below), DTD reward cooldown 5 → 6, future-timestamp drift cap 60 s → 30 s (NTP synchronisation strongly recommended post-V13), Beacon Phase II-A. RC1 metadata is signed (release_status = signed_metadata_only); binaries upload is the next manual operator step.
  2. V13 verified automatic flip at block 12,100 — the V11 Phase 2 lottery cadence transitions from 2-of-3 bootstrap to 1-of-3 permanent without any operator action, restart, RPC, Beacon notice or config flag. Six audit gates GREEN on main.
  3. V13 anti-dominance DTD gate at block 12,100 — bundled with the cadence flip, any miner whose share of the previous 288 blocks is ≥ 10 % is automatically excluded from the DTD reward eligibility set until their rolling share drops below 10 %. A companion SbPoW-activity gate admits only miners that have produced at least one SbPoW-signed block (most recent block at height ≥ 7,100), excluding dormant pre-SbPoW addresses. Dominant miners keep their 50 % miner share on every block they produce; they only miss the redistributed 25 % + 25 % network-side share on DTD-triggered blocks. The exclusion is reversible per-block, no admin authority, no slash, no permanent ban. Independent of the recent-winner cooldown (which continues to apply). See docs/V13_DTD_DOMINANCE_GATE.md.
  4. V14 at block 15,000 — Phase I governance + PoPC automation block — activated at block 15,000 (now live on mainnet). Activates: Gold Vault Phase I governance (90 % miner approval over a 67-block window + 10 % quality boost or single-signer veto from developer / genesis, silence = accept, single destination = genesis miner, cap 1,000 SOST per spend / 5,000 SOST per rolling 1,008-block week); the single-model PoPC bond migrated out of popc_registry.json into deterministic chain-state (note: the PoPC redesign moved the base single-bond model activation to V15 / block 25,000, — superseded: the DTD does NOT require a PoPC bond at any height. The mainnet gate ships deactivated (DTD_POPC_GATE_CONSENSUS_ACTIVE = false) and the lottery is permissionless; the native SOST bond is the only collateral and the only slashable asset, slashed only on a consensus-defined bond failure); Beacon II-A real operator pubkey replaces the placeholder (canonical fingerprint bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b = sha256 of the lowercase uncompressed pubkey hex; recompute against src/beacon.cpp to detect a substituted key); threshold sync 95 % → 90 %. Conditional in V14: atomic swap HTLC activates only if the libwally-core sprint + end-to-end testnet pass before block 15,000 (this ultimately activated at V14.5 / #16,000; relay/policy flag-day #17,000); ⚠ historical: the former PoPC Model B (gold escrow via an Ethereum SOSTEscrow contract, including any "supervised mode") is superseded by the single native SOST bond — there is no gold-escrow PoPC in the current design; gold is an optional reward boost only, never collateral, never escrow, never slashed.
  5. Threshold revised: 75 % → 95 % → 90 % — the Gold Vault miner-signaling supermajority finalised at ≥90 % over a 67-block window (~12 h, ceil = 61 blocks). The live normative threshold in §Protocol Summary and §Decentralization now reads ≥90 %; any "≥95 %" that remains there is shown only as historical context (the V6-era V14-deferred design). PDF v4.6 regeneration is an operator step.
Memory-Lock per-instance, mentioned in earlier drafts as a second anti-pool defense, was rejected outright after numerical analysis (penalises small miners proportionally more than large rigs). SbPoW (active since block 7,100) remains SOST's only anti-pool defense.
WHAT THE PROTOCOL DOES TODAY — read this before the sections below.
This whitepaper still describes the original gold/PoPC economics in several places. They were superseded on chain:
How the DTD works · deterministic & auditable

In plain terms, deterministic token distribution means the split is computed from fixed, reproducible rules — never chosen by anyone.

If two people look at the same blockchain data, they must get exactly the same result.

It does not depend on who runs the calculation, which phone or computer, the browser, the internet speed, or any manual decision.

✓ Deterministic
Rule: “Distribute 100 SOST among every eligible address of the last 288 blocks by this exact formula.” If there are 193 eligible and the formula is fixed, every node that computes it gets the same 193 eligible and the same split.
✗ Not deterministic
Rule: “If an RPC call fails, skip that block.” A slow phone could skip more blocks than a laptop and read 111 eligible while another reads 193 — exactly the kind of defect SOST fixed.
same blocks + same rules + same state = same result

Auditable by anyone. Because the outcome is pure consensus data, anyone can re-derive the eligible set and the winner straight from the public chain and confirm it matches — via the explorer’s getlotteryaudit (per jackpot) or by recomputing the eligibility set over the last 288 blocks. You never have to trust a website or a person.

Adaptive Node Participation for Normal DTD — Future Design
DESIGN PROPOSAL · NOT ACTIVE · NO THRESHOLD · NO ACTIVATION HEIGHT · NO CONSENSUS CHANGE

Rationale. Independent validating nodes are what make the chain hard to censor and hard to mislead. Jackpot V2 already makes a bound node identity (NODE_BIND + heartbeats) a condition for the jackpot. Extending that condition to the normal DTD would convert more miners into node operators, but applying it while the network is small would raise the cost of entry for new miners. The proposal is therefore adaptive: the requirement could appear only once the network is demonstrably mature.

Current state (V30000, unchanged by this note)
MINER REWARD valid mining; never depends on NODE_BIND DTD NORMAL every block; mined within the last 288 blocks; recent-producer cooldown (producers of the previous 6 blocks skipped), dropped by a fallback if it would leave the set empty; anti-dominance (share of the last 288 blocks ≥ 10% excluded) only when ≥ 11 distinct miners are active; uniform pick; NO NODE_BIND; NO heartbeats DTD JACKPOT V2 every 288 blocks, independent draw (separate domain-tagged seed); ≥ 3 SbPoW blocks in the last 2,016; NODE_BIND; heartbeats (ramping to 3 of the last 4 epochs); pick weighted by PoW blocks
Proposed transition
EARLY NETWORK normal DTD open to recent miners; NODE_BIND optional for it MATURE NETWORK normal DTD MAY additionally require an active bound node identity, only after objective maturity conditions are satisfied ALWAYS the gate affects DTD eligibility only -- never block validity, never the miner's base block reward
Measuring maturity

Not by NODE_BIND count alone. Candidate inputs: distinct active miners; distinct active bound node identities; the share of active miners with an active bound node; persistence over time; network stability; observable node diversity; a minimum duration before activation; protection against temporary spikes. Thresholds are TBD and must come from simulation and incentive analysis — no number is proposed here.

Manipulation risk and required properties

If activation depended only on a simple count of miners with a bound node, a miner could rationally decline NODE_BIND to keep the stricter gate from activating. A naive single-threshold rule is therefore ruled out. Any concrete design must provide:

Prerequisite: node UX

Before the requirement is extended, running a node should be close to one action for users (design direction, not a shipped feature): run node · run miner · create NODE_BIND · automatic heartbeats · Jackpot eligibility.

Path to consensus

Activation would require, in order: an implementation; simulation of the maturity metric and of the incentive effects; tests; review and external audit; a public notice; and an explicit, height-gated activation rule. This proposal is not tied to the planned #40,000 reward split (80% miner / 15% DTD normal / 5% DTD Jackpot); the two are separate decisions.

Terminology. NODE_BIND binds a mining key to a node key with two signatures. It proves a cryptographic link — a bound node identity, verified node participation — not the uniqueness of a physical machine.

Current operator documentation: upgrade guide · quick start · protocol spec.
WHITEPAPER

Technical
Whitepaper

SOST: Proof of Irreversible Convergence. The complete technical specification covering ConvergenceX consensus, monetary policy, Gold Reserve, PoPC, governance model, security analysis, and constitutional rules. Version 4.6.

v4.6 | October 2026 · No ICO · No Premine · No VCs
✓ SLIP-0044 | coin_type 1869902947 (0x6F747463) · path m/44'/1869902947'/0'/0/0 · merged by SatoshiLabs, slips#2004 (June 15, 2026)
FUNDAMENTALS

The Four Pillars

SOST follows a sound-money-inspired design — four orthogonal properties that must hold simultaneously and forever. Two of them enforce credibility of issuance: the chain advances at a predictable rate (Time) under a measurable, energy-bounded effort (Work). The other two enforce credibility of value: total supply is finite (Scarcity) and an explicit fraction is converted, by consensus, into a gold-funded reserve (Store-of-Value Architecture). All four are hard-coded at genesis with no governance override. Every section of this whitepaper either specifies one of these pillars or proves it.

⏱ PILLAR 1 — TIME
600-second target spacing

Block production is paced at a 10-minute target (600 s) via the cASERT unified rate controller. Difficulty (bits_q, Q16.16 fixed-point) adjusts every block from a 288-block running average against target — bidirectional and integer-only: it hardens when blocks arrive too fast and eases when too slow. Layered above it, the ConvergenceX equalizer maps chain lag onto a stability profile across the range E7 (easing floor) → B0 (baseline) → H35 (hardening ceiling). The E7 floor is immutable; the hardening ceiling was raised across forks (H13 pre-V12 → H20 from block 7,350 → H35 at V13, block 12,000). From V11 onward a triangular cascade provides emergency relief on stuck blocks without compromising the long-run schedule. (The earlier L-series profile labels are retired; the live controller uses a direct lag→profile mapping over E7–H35.)

The cadence is chosen, not arbitrary. 600 s yields 144 blocks/day = F₁₂, the 12th Fibonacci number and 12². The monetary schedule extends the same sovereign-constant aesthetic: per-block emission decays geometrically by e−1/4 ≈ 0.7788 each 131,553-block epoch — epoch length = round(52,560 × α) where the Feigenbaum constant α ≈ 2.5029 — converging on a hard supply cap of ≈ 4,669,201 SOST (SUPPLY_CAP), echoing Feigenbaum δ ≈ 4.6692. See section 3 (cASERT) and section 12.

⚙ PILLAR 2 — WORK
ConvergenceX — native, original

ConvergenceX is a native, original Proof-of-Work design. It is NOT a fork and NOT a parameter-tweaked variant of Bitcoin SHA-256, Monero RandomX, Ethereum Ethash, Equihash, CryptoNight, Scrypt, X11, BLAKE-anything, ProgPoW, RandomHash, or any other prior algorithm. A mining attempt requires solving a 32×32 SPD linear system through 100,000 sequential rounds of integer-only gradient descent and proving the solution sits in a stable basin of attraction (Proof of Irreversible Convergence). Memory-hard: 4 GB dataset (SplitMix64-indexed, state-dependent access from V11 Phase 1) plus a 4 GB scratchpad shared by all mining threads — 8 GB total (the dataset is rebuilt every block from the previous block hash; the scratchpad once per emission epoch). Per-block 256-op program changes every block. Verifiers reconstruct sampled rounds with ~500 MB of RAM in ~0.2 ms. See section 3.

◆ PILLAR 3 — SCARCITY
4,669,201 SOST — ever

The hard cap is 4,669,201 SOST — the first seven significant digits of Feigenbaum's first constant δ (≈ 4.6692016091…), the universal ratio that governs the period-doubling route to chaos in nonlinear dynamical systems. The choice is deliberate: ConvergenceX itself is built on the same family of dynamical systems. Emission follows an exponential decay per 131,553-block epoch with quotient q = e-1/4 ≈ 0.7788; epoch 0 reward = 7.85100863 SOST. No premine, no ICO, no dev tax, no minting function, no governance override. See section 4 (Monetary Policy) and Appendix A (Canonical Constants).

◈ PILLAR 4 — STORE-OF-VALUE ARCHITECTURE
Up to 50% supply → gold reserve

HISTORICAL (blocks 0–24,999; since #25,000 the split is 50% miner / 50% DTD and the vault receives nothing new): every block coinbase was split 50 / 25 / 25 by consensus (PoW miner / Gold Funding Vault / PoPC Pool). Over the full emission curve this directs up to 50% of total supply into two gold-reserve channels:

25% — Perpetual Gold Vault. Protocol-funded, one-way TWAP purchases of tokenised precious metals (XAUT / PAXG today, broader basket later) deposited into a Heritage Reserve on Ethereum mainnet. Observable reserve ratio — not a peg, not a redemption right. See section 5. For the current reserve governance status and tokenized-gold vault policy, see the Gold & Metals Reserve page.

25% — Proof of Personal Custody (PoPC). Rewards distributed from the PoPC Pool to holders who lock a single native SOST bond — the only collateral and the only slashable asset. Gold is an optional reward boost only — never collateral, never escrow, never slashed; if gold cannot be verified the user simply receives no boost (never a lock, penalty, or slash). Gold Boost is deferred / off on mainnet until a continuous gold-verification pipeline exists. The base single-bond model reached its V15 / block 25,000 height; on mainnet the DTD eligibility gate ships deactivated (DTD_POPC_GATE_CONSENSUS_ACTIVE = false) and the DTD is permissionless — no PoPC bond is required at any height. See section 6.

⚠ Historical: earlier drafts described two PoPC models — Model A (self-custody bonds) and Model B (gold escrow timelock via an Ethereum contract). Both are superseded by the single native SOST bond above; gold is no longer collateral, escrow, or slashable.

No peg. No redemption right. No price floor. No investment return. No legal claim over the reserve.

The split is enforced at validation: a block with the wrong coinbase shape is invalid. See sections 5, 6, and Constitution C1–C15 (section 10).

Hardcoded at genesis · enforced by the current consensus rules · any change needs a network-adopted upgrade

CONVERGENCEX · cASERT

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.

DOCUMENT

Whitepaper v4.5

SOST: Proof of Irreversible Convergence
TECHNICAL SPEC

A mathematically grounded Proof-of-Work based on verifiable dynamical-system certificates. The whitepaper covers the complete protocol specification including consensus algorithm, monetary policy, reserve architecture, custody protocol, and constitutional framework.

TitleSOST: Proof of Irreversible Convergence
Versionv4.5 — March 2026
AuthorsNeob (SOST)
FormatPDF
StatusProduction (mainnet)
Table of Contents
OVERVIEW
Section 1Abstract
Section 2The Problem — PoW design space
Section 3ConvergenceX: Proof of Irreversible Convergence
Section 4Monetary Policy — Epoch-based emission with smooth exponential decay
Section 5Gold Protocol Reserve — Heritage vault
Section 6Proof of Personal Custody (PoPC)
Section 7Governance Model — No consensus governance
Section 8Economic Model — Demand, deflation, equilibrium
Section 9Security Analysis
Section 10The Constitution — C1–C15
Section 11Roadmap
Section 12Technical Specifications
Appendix ACanonical Constants (Normative)
Appendix BSerialization (Normative)
Appendix CPRNG Specification (Normative)
Appendix DTest Vectors (Normative)
Appendix GEmergency Reserve Authorization (V6 5-Defense Model)
Download & Verify
AVAILABLE

The whitepaper is published on multiple channels for redundancy and tamper-resistance. Verify the document hash against the published checksum.

GitHubgithub.com/sost-protocol/whitepaper
IPFS mirrorPinned — immutable content-addressed copy
Websitesostcore.com/sost-whitepaper.html
ChecksumSHA-256 published in repository
AT A GLANCE

Key Specifications

Protocol Summary
GENESIS CONSTANTS
Name / SymbolSOST
Genesis2026-03-15 18:00:00 UTC
AlgorithmConvergenceX (4GB, 100k rounds, sequential)
Block time600 seconds target
Max supply4,669,201.609 SOST (hard cap)
Min unit1 stock = 0.00000001 SOST
Epoch131,553 blocks (~2.5 years, Feigenbaum α)
Initial reward7.85100863 SOST/block
Coinbase split50% miner / 50% DTD since V15 (#25,000) · historical 50% miner / 25% gold / 25% PoPC for blocks 0–24,999
Annual decay~9.03% (smooth, no halvings)
DifficultycASERT bitsQ Q16.16, per-block; V5 (block 5,175+): avg288-based, dynamic cap (block 5,270+: ±15 s dead band, then 0.5/1.0/2.0/≈3.03%); Equalizer 43 profiles E7–H35, direct lag map (block 5,323+), anti-stall 60 min; relief: current V12 triangular cascade (block 7,350+, up to 28 levels, floor E7) — HISTORICAL: V8 single E7 cliff at 605 s (block 5,750+) → V9 staged drop 3/60 s from 540 s (block 6,550+) → V10 granular drop 1/60 s from 600 s (block 6,700+) → V11 linear (7,000) / triangular cap 21 (7,100); historical: 48h then 24h half-life
ReserveHeritage (sealed by default), Ethereum mainnet
Emergency≥90% block-based miner signaling over 67-block window (ceil = 61 blocks) + 5-defense Gold Vault model + Transitional Guardian with 10-block pronouncement window and auto-disconnect at block 25,000. V14 height reached (#15,000); emergency-governance / Gold-Vault spend gates remain deferred on mainnet (no activation height). Historical: original V6 / block 10,000 / ≥95 % design. See V13 scope update.
Premine / ICO0 — none
Consensus governanceNone — immutable at genesis
// CODEBASE FOOTPRINT

Codebase vs Bitcoin Core

Lines-of-code totals for the SOST stack as of 2026-05-10, side by side with the Bitcoin Core reference implementation. LOC is a rough engineering metric — not a quality, security or decentralisation metric — but it gives a sense of how much surface area the project covers.

ComponentSOSTBitcoin Core
Blockchain core (C++ / protocol)36,740~280–310k
Consensus & integration tests (C++ / Python)37,187—
Front-end & explorer (HTML + JS + CSS)76,283—
Protocol scripts, tooling & services (Python)24,457—
Documentation (markdown)37,650(separate)
Total code (excl. docs)174,667~280–310k
Total code + docs212,317—

1. The blockchain core alone is 5–7× smaller than Bitcoin Core. Bitcoin Core has 15+ years of P2P hardening, scripting (Script + Taproot), thousands of tests, and dozens of network conditions handled in production. SOST does not, and pretending otherwise would be dishonest.

2. The comparison is not apples-to-apples. The SOST total includes a hand-rolled front-end and block explorer plus protocol tooling and test suites that Bitcoin Core does not contain. The comparable blockchain core is the 36,740-line figure above.

3. What the numbers do show. SOST is a serious open-source project (~212,317 LOC including documentation) with depth beyond a typical altcoin fork — the consensus is custom (ConvergenceX + cASERT), the wallet model is in-house, the front-end is hand-rolled, and SOST is integrated with two external scientific systems.

4. What the numbers do NOT show. Network effect, peer count, security audits, deployed value, decentralisation. Those are independent of LOC and Bitcoin leads on every one of them.

Counts measured 2026-05-10 with find ... | xargs wc -l over each component's own source tree, excluding build artefacts and vendored code. Bitcoin Core figure is the upstream bitcoin/bitcoin master snapshot, code + tests, no docs.

// TRADING

DEX and OTC P2P — simple & secure

SOST ships two trading surfaces. Both are non-custodial, both are simple by design, and both have an explicit security model. Fiat trades are not offered as a consensus feature — the SOST chain cannot verify a bank, so SOST refuses to pretend it can.

PoPC is a native bond — not a traded product

Proof of Personal Custody (PoPC) is a single non-tradeable native SOST bond, not a market instrument. In V15 there is no PoPC DEX and no PoPC contract / position trading: a bond is created, locked, and claimed by its owner, never bought or sold on an order book. The native SOST bond is the only collateral and the only slashable asset; gold is an optional reward boost only — never collateral, never escrowed, never slashed. The real trading surface is the Atomic Swap DEX / OTC described below.

⚠ HISTORICAL — SUPERSEDED DESIGN

The subsection below describes an earlier "SOST DEX (PoPC)" that traded PoPC contracts collateralised by tokenised gold held in an Ethereum SOSTEscrow.sol contract (the old Model B). This is historical. PoPC is now a single native SOST bond with no contract trading and no gold escrow; gold is an optional boost only. The text is kept for reference.

SOST DEX (PoPC) — historical design

The SOST DEX traded PoPC contracts (Proof of Personal Custody positions backed by tokenised or physical gold). Every trade combined three independent security layers:

  • Client-side ED25519-signed offers. The offer payload (action, position-id, maker SOST address, maker ETH address, SOST amount, gold amount, price, expiry) is signed in the user's browser. The signing key is encrypted with Argon2id from the user's passphrase and never leaves the device.
  • End-to-end encrypted relay. X25519 envelopes carry the signed offers between users. The relay server transports bytes but cannot read the cleartext, cannot alter the payload (MAC verified client-side), and cannot impersonate either party.
  • On-chain Ethereum escrow. Where gold tokens move (XAUT, PAXG), they sit in the experimental SOSTEscrow.sol contract. SOST holds no keys to that contract. Releases happen by on-chain logic the two parties trigger themselves — no admin, no operator, no oracle.

SOST cannot reverse trades, cannot recover funds sent to a wrong address, cannot compel delivery, and cannot verify off-chain promises. That was the design. What it did instead: enforced structural integrity of every signed payload, anchored every trade in cryptographic primitives, and surfaced 26 known scam patterns via the client-side Sentinel chat layer.

SOST OTC / P2P Board — crypto-to-crypto via atomic swap

The community OTC / P2P Board hosts user-to-user trades against seven counterparty assets: BTC, ETH, USDT, USDC, BNB, PAXG, XAUT. The intended settlement mechanism is the atomic swap HTLC (Hashed Time-Locked Contract): cryptography enforces that either both parties receive their funds, or both refund — no intermediate state exists in which one side walks away with everything. No SOST escrow, no admin custody, no first-mover risk, no protocol authority.

The implementation status (as of this revision) is:

The trust profile of the seven assets splits into two categories. Trust-minimized (BTC, ETH, BNB): no token-issuer freeze risk; cryptographic atomicity holds on both sides. Issuer-risk (USDT, USDC, PAXG, XAUT): the underlying token can be frozen by its issuer (Tether, Circle, Paxos, TG Commodities); if that happens mid-swap, the SOST side still refunds correctly but the counterparty side may become uncollectible. The DEX UI labels these four explicitly and recommends small amounts for them; larger amounts should stick to Category A.

OTC against fiat — deliberately not offered as a consensus feature

A trade where one leg is a SEPA transfer, wire, or cash payment cannot be made cryptographically atomic. The SOST chain has no view into a bank. Any mechanism that would "penalise the unpaid fiat side automatically" requires either (a) an oracle that reads the bank — which is arbitration and turns SOST into a regulated intermediary — or (b) one party self-declaring incumplimiento, which is a trivially-exploitable robbery primitive; both also enable Sybil collusion farms. There is no third path.

Therefore SOST does not offer fiat OTC as a consensus service. The community discussion board still permits conversations about fiat trades (people are free to do whatever they want with each other), but SOST provides no escrow, no penalty, no dispute resolution, and no implied safety. SOST's strong recommendation is to keep all trades in the crypto-to-crypto path (atomic swap) where the cryptography itself can enforce safety. Any fiat trade is off-protocol, at user risk, with no protocol safety net.

The simplicity rule

Both surfaces follow the same five-step UI discipline so the user can be safe without becoming a cryptographer:

  1. Load only the official URL: sostcore.com (the only official domain; the former sostprotocol.com is being retired). Never click a link from a DM.
  2. Read the signed offer fields before signing. Counterparty address, amount, expiry — all visible, all binding.
  3. Verify counterparty addresses against the LOCK / escrow payload. The signed payload is authoritative; chat messages are not.
  4. Confirm txids on-chain (SOST explorer or Etherscan) before releasing anything. Screenshots are not proof.
  5. Do a small test transaction before any larger amount. Always. Without exception.

Anything sold outside this flow — Telegram DMs, "official escrow admin", address changes by chat, advance fees, screenshot proofs — is a scam pattern. The client-side Sentinel flags 26 known variants at the chat layer. The OTC and DEX pages document each pattern with worked examples. If a counterparty pushes you off the official flow, stop the trade.

// AUTONOMOUS CHAIN SAFETY · updated 2026-09-29

Autonomous Chain Safety (SACS)

SOST is an open Proof-of-Work chain: every node independently verifies blocks and follows the chain with the highest cumulative verified work (not the longest, and never a peer's self-reported work). SOST does not use ChainLocks, masternodes, validator quorums, miner votes or a developer-selected chain. It therefore offers probabilistic PoW security, not mathematically irreversible finality: a sufficiently powerful adversary that produces a valid higher-work chain cannot be excluded by software alone.

SACS (SOST Autonomous Chain Safety) is a safety layer with two clearly separated parts:

  • Current mainnet. Best-chain-by-cumulative-work selection; atomic reorg with full rollback; MAX_REORG_DEPTH = 500 blocks (~3.5 days) — a reorg-depth rule enforced in code: a reorg at/below the cap converges to the most-work chain, a reorg deeper than the cap is rejected (the node keeps its chain even against more valid work — confirmed in a scaled devnet lab), which bounds deep reorgs but can prevent automatic convergence after a very long partition; hard checkpoints (≤ height 3,554) reject a contradicting chain; 1,000-block coinbase maturity. The 500-block rule bounds deep reorgs but, after a long partition, can prevent automatic convergence to a valid higher-work chain (confirmed in a scaled devnet lab: at/below the cap converges, above it splits persistently). Resolving that safely — treating the depth as an alert plus full re-verification — is the devnet-only deep-reorg research, post-fork.
  • SACS Core — LAB VERIFIED (V16-compatible, not yet deployed). Fork/reorg monitoring, structured chain-safety events, a read-only getchainsafety RPC, a transaction-safety state machine (CONFIRMED → REORGED → REENTERED_MEMPOOL → CONFLICTED) and reconciliation for the wallet, Explorer, DEX and exchanges, plus recovery/persistence hardening. This is observability and application protection — it changes no consensus rule: a SACS alert can make an application wait or pause, never turn a valid block invalid, never halt honest mining. Blockchain truth outranks any local database or UI.
  • SACS Deep-Reorg Recovery — FUTURE RESEARCH (devnet only). Studies treating the 500-block depth as an operational alert rather than an automatic rejection, so that after a long partition a node can fully re-verify the alternative branch (work, UTXO, emission, difficulty), protect sensitive operations, and converge on the valid higher-work chain. Any such change is consensus-affecting and would require a future coordinated upgrade — it is not part of the V16 fork at block #30,000.

Status: SACS Core is code-complete and lab-verified on a research branch; it is not live on mainnet and no node binary is swapped before #30,000. SACS provides autonomous detection, recovery support and transaction-safety signals — it does not provide absolute, irreversible finality.

⬢ MOST LIKELY CURRENT RESEARCH SCENARIO — NOT CONSENSUS

The current leading scenario under study is a future activation around block #40,000 or #50,000, subject to network maturity, miner distribution and further simulation. 80/15/5 supersedes 75/20/5 as the current leading research scenario.

80%
direct PoW miner reward
15%
normal DTD per block
5%
into the existing DTD Jackpot pool

80% — direct PoW miner reward. Miners contribute measurable hashpower, valid block production and computational/economic chain security.
15% — normal DTD distribution continues per block.
5% — into the existing DTD Jackpot pool. This 5% accumulates in the DTD Jackpot pool that V30000 already distributes — it is NOT a direct 5% node payment per block. When jackpots are paid, the existing V30000 DTD Jackpot eligibility framework remains applicable, including the node / NODE_BIND eligibility requirements.

This gives two complementary incentives: (1) a direct PoW incentive for the miners securing the chain, and (2) an accumulated Jackpot incentive for eligible network participants that maintain the required network infrastructure.

80% → direct PoW miner reward (chain security)
15% → continuous normal DTD per block
5% → accumulates in the existing DTD Jackpot pool (not a direct node payment)

No new supply. All three allocations come from the existing block emission. Not consensus. Blocks #40,000 and #50,000 are the two most likely activation scenarios — neither height is final. The 80/15/5 structure is the leading research candidate, not active consensus (current consensus is unchanged: 50% miner / 50% DTD) and supersedes 75/20/5 as the leading scenario. Any implementation would require explicit consensus rules and a future hard fork. SOST is also actively pursuing full decentralization of the system as soon as possible.

// DECENTRALIZATION

Honest Assessment

The network and mining layers are already partially decentralized: multiple independent nodes, multiple active miners, open-source code, and no admin keys for block production.

However, two economic custody components are still temporarily centralized during Phase I (until governance activates — originally targeted for V6 / block 10,000, deferred to V14 / block 15,000 after the 2026-05-18 scope review; see banner above and docs/V13_PUBLIC_SCOPE_UPDATE.md):

  • Gold Vault (25% of every block reward (until #25,000; 0 since)): the 5-defense governance model once targeted for V14 / block 15,000 was deferred and never activated and is now paused indefinitely / legacy. From V15 (block 25,000) the accumulated reserve is redistributed on-chain to miners via the DTD / DTD Jackpot architecture (supply-neutral). Historical audit at docs/V13_GOLD_VAULT_GOVERNANCE_GATES.md.
  • PoPC Pool (25% of every block reward until block #25,000 — 0% since): developer-held custody of what it already received. The single-model PoPC bond (native SOST bond only — gold is an optional reward boost, never PoPC collateral, never escrow, never slashed) is not operational. Correction: an earlier draft of this paragraph said the DTD reward would require an active PoPC bond from block 30,000. It does not. On mainnet the PoPC eligibility gate ships deactivated (DTD_POPC_GATE_CONSENSUS_ACTIVE = false): the DTD is permissionless — mining one valid block is the only requirement, and V16 at #30,000 changes which miners qualify, not whether a bond is needed. The Gold Vault / Metals Reserve (the other 25%) is a separate channel and is not the PoPC reward source. Full audit at docs/V13_POPC_ESCROW_AUTO_ACTIVATION_GAPS.md

SOST developer cannot change the constitutional 50/25/25 split (blocks 0–24,999; 50/50 miner/DTD since #25,000), because it is hardcoded at genesis. What remains centralized during Phase I is custody, not the emission rule itself.

Custody transition roadmap:

  • Block 15,000 (V14 hard fork): H3/H4 consensus hardening. The Gold Vault governance model (5-defense: purpose restriction, dual destination whitelists, per-spend cap, rate limiting, ≥90 % miner signaling over a 67-block window, plus the Transitional Guardian role) and the PoPC single-bond once proposed for enforcement here / at V15 were deferred and never activated. Both are now paused indefinitely / legacy, superseded by the DTD / DTD Jackpot architecture: from V15 (block 25,000) the accumulated Gold Vault + PoPC reserve is redistributed to miners on-chain (supply-neutral), and from V16 (block 30,000) the DTD Accumulated Reward V2 becomes an independent node-gated draw. Governance threshold history retained for reference: 75 % (original whitepaper) → 95 % (V6 internal review) → 90 % (V13 review).
  • Gold reserve purchases become externally verifiable on Ethereum (already started: 1.2 oz committed)
  • Phase III (12–24 months): Migration from tokenized gold (XAUT/PAXG) to physical gold custody in a regulated vault. No bridges, no wSOST, no cross-chain attack surface.

The custody arrangement during Phase I is at SOST developer’s operational discretion. The transition to network custody at block 10,000 has a hard date encoded in the consensus rules — it is not subject to the developer’s later willingness to step back. The Gold Vault must be able to change form, but not purpose.

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.
RESEARCH HORIZON #40,000

Automated Bridge (in development, not active), Gold Reserve V2 & governance

STATUS: RESEARCH / DEVELOPMENT · NOT ACTIVE · NOT READY FOR PRODUCTION

SOST Atomic Bridge (Atomic Reserve Vault), Gold Access Key, Gold Reserve V2 and governance (#40,000 research horizon)

The target architecture of the bridge is the SOST Atomic Bridge (3.16.1). C701 replaced the previous federated design with automated verification; its lock/mint model is now the conventional reference (3.16.2). The bridge, wSOST and Gold Reserve V2 exist only as development contracts, a verification-engine prototype and tests on a local development chain. Nothing is deployed on any public chain, no contract is live, no funds exist and there is no launch date; real operations are blocked by design until the open blockers below are closed, and any future activation is subject to security work, an external audit and legal/regulatory review. Current consensus (50% miner / 50% DTD) is unchanged; #40,000 is a research horizon, not an activation commitment. Public explanation and DEMO: wSOST & Gold Vault.

Two services only

SOST Bridge native SOST ↔ wSOST on Ethereum, 1:1 (this section) SOST Atomic Swap separate P2P HTLC service: no SOST↔wSOST pair, no Gold Access Key, never touches Gold Reserve V2

3.16.1 Target architecture — SOST Atomic Bridge (Atomic Reserve Vault)

STATUS: TARGET ARCHITECTURE · RESEARCH / DEVELOPMENT · NOT ACTIVE · NOT MAINNET · NOT AUDITED · NOT YET PROVEN

On 2026-10-26 SOST fixed one target architecture for the bridge: the SOST Atomic Bridge, an Atomic Reserve Vault (ARV). SOST does not intend to mint a new wSOST for every bridge operation. The target uses a preissued, immobilized wSOST reserve on Ethereum and bidirectional atomic swaps; native SOST received by the bridge forms the corresponding reserve. The conventional lock/mint design of 3.16.2 (C701/C703) is kept as the reference model and as the prototype whose components are reused; it is not a second product.

Premint accounting:

TOTAL_PREMINTED_wSOST fixed at deployment, no minter afterwards IMMOBILIZED_wSOST free inventory held by the Ethereum Atomic Vault PENDING_wSOST inside entry / exit HTLCs of the vault CIRCULATING_wSOST TOTAL - IMMOBILIZED - PENDING BACKING_NATIVE_SOST confirmed native reserve outputs (+ PENDING_NATIVE_SOST in HTLCs) rule CIRCULATING_wSOST <= CONFIRMED_NATIVE_SOST_RESERVE (equal after every swap) not totalSupply(wSOST) <= reserve (totalSupply includes the immobilized inventory) example premint 1,000,000 = 990,000 immobilized + 10,000 circulating; reserve 10,000 → 100%

Native SOST is never burned. Returned wSOST goes back to the inventory: no burn is required. A large inventory is itself a target; it would be sized to the exposure caps and topped up in tranches (the 1,000,000 figure is illustrative).

Entry (SOST → wSOST, 1,000) with the native HTLC active since #16,000 and an Ethereum HTLC with the same sha256 hashlock:

1 wallet creates s, H = sha256(s); request bound to H, amount, recipient; XAUT escrowed 2 user locks 1,000 SOST: OUT_HTLC_LOCK(H, claim = reserve, refund = user, +288 blocks) 3 engine waits 30 confirmations and checks the lock 4 vault moves 1,000 EXISTING wSOST into an HTLC(H, beneficiary = user, refund to vault, ~12 h) 5 user claims with s: wSOST to user, escrowed XAUT to Gold Reserve V2 (no mint) 6 reserve claims the SOST with the revealed s reserve 10,000 → 11,000 · circulating 10,000 → 11,000 · inventory 990,000 → 989,000

Step 4 must not happen for a SOST lock that does not exist, so the entry still needs a verifier: today the engine's authorization (a threshold of keys is possible), later possibly a SOST light client on Ethereum. Mint authority becomes release-from-inventory authority, bounded by the inventory and the caps, not removed.

Exit (wSOST → SOST, 500):

1 user creates s', H' = sha256(s'); locks 500 wSOST in HTLC(H', beneficiary = vault, ~48 h) 2 engine waits for Ethereum finality 3 reserve funds OUT_HTLC_LOCK(H', claim = user, refund = reserve, +72 blocks), 500 - fee 4 user claims the SOST with s' 5 anyone settles the Ethereum HTLC with s': 500 wSOST back to the inventory (no burn) reserve 10,000 → 9,500 · circulating 10,000 → 9,500 · inventory 990,000 → 990,500

Failure and refund: the side that moves first gets the longer deadline. If the vault never releases, the user refunds the SOST; if the user never claims, the vault HTLC returns to the inventory and the user refunds; the XAUT escrow returns on expiry; secrets and swap ids are single-use. Two risks stay open: (a) if the user claims wSOST and the reserve fails to claim the SOST before the user's deadline, the user could refund and keep the wSOST (only the claim key can claim a SOST HTLC, so watchtowers cannot help); (b) a reorg of the SOST lock after the vault released is bounded only by the 30-confirmation depth. The Gold Access Key is escrowed before the claim because a secret revealed in a reverted claim would otherwise let the reserve take the SOST while the user received nothing.

The central problem — who controls the native SOST reserve? An atomic swap coordinates the exchange; it does not decide who controls the SOST afterwards. The native HTLC has single-key claim and refund keys. V17 native multisig (OUT_MULTISIG, M-of-N <= 15, no script engine) may fund an HTLC and receive an HTLC claim, but cannot be an HTLC claimant or refund key, and has no timelocked recovery path. A 3-of-5 reserve reduces single-key risk; three signers can still move the whole reserve, and they decide off-chain when to fund an exit. With current and V17 primitives, arbitrary withdrawal by the reserve signers is NOT impossible. Missing primitives (research only, none authorized, consensus unchanged):

P1 destination-committed HTLC: claim output fixed at lock time, claimable with the secret alone P2 HTLC with a multisig claimant / refund key P3 reserve vault with delayed spending and a recovery path P4 covenant: reserve spendable only into exit HTLCs refunding to the reserve, rate-limited P5 SOST able to verify Ethereum state (light client / proof)

Cross-chain proofs keep a role, no longer for every exchange: the entry release, public reserve verification, settlement checks, reorg detection and recovery. ConvergenceX has a compact transcript proof (about 10-20 ms natively, no 4 GB dataset), so a SOST light client on Ethereum is not ruled out; its EVM cost with the cASERT rules is unmeasured and expected to be high.

Comparison (official documentation, 2026-10): Atomiq verifies Bitcoin PoW with an on-chain light client and releases LP liquidity from UTXO-controlled vaults; THORChain uses a bonded validator set, TSS vaults and liquidity pools; Chainflip uses 150 validators and an aggregate key with FROST 100-of-150 signing. The SOST design aims to avoid a separate validator network and a pool; it is not claimed to be more secure, more advanced or novel. Neither model A (lock/mint) nor model B (ARV) is automatically trustless.

Proof of concept (testnet / devnet only, NOT STARTED): 100 fictitious preminted wSOST; entry, exit, counterparty disappears, deadline ordering, engine stops, secret replay, concurrent swaps, reserve insufficient, reorg, attempted reserve theft; decisive test 500 SOST → 500 wSOST → 500 SOST with 1:1 kept and no operator permission. The theft test is expected to fail with today's primitives. Until all of it is shown, the Atomic Reserve Vault is RESEARCH ONLY.

C705 feasibility result — a keyless native reserve

A reserve that nobody holds a key to can only react to events its own chain can verify. Hashlocks alone cannot protect it: with no deciding counterparty, anyone could make it lock SOST under a secret of their own choosing. The keyless form of the Atomic Bridge therefore replaces "who signs" with "what is proven", in both directions: the Ethereum vault releases inventory only against a proof of a confirmed SOST deposit, and SOST pays from the reserve only against a proof of a finalized Ethereum return. HTLCs remain only as an optional fast path for market makers swapping their own funds. Minimum new SOST primitives (research only, none authorized, consensus unchanged):

N1 = P4 keyless ARV outputs, no pubkey, no script, fixed spend paths: ARV_DEPOSIT (names 0x recipient, deadline, refund address, vault) → swept into the reserve on a proof of EntryReleased, or → refunded to its fixed address on a proof of EntryCancelled ARV_RESERVE singleton (chained output; holds the Ethereum light-client state) → pays proven ExitRequested events, sequential nonce, fixed destination N2 = P5 ETH_FINALITY_PROOF: sync-committee light client in consensus (BLS12-381, SSZ, keccak, RLP, Merkle-Patricia receipt proofs), finalized headers only P1, P2, P3 not needed (no key to fix, share or delay); multisig is not used for the reserve Ethereum immutable vault, no admin; SOST header relay (optimistic, bonded, fraud proof by one ConvergenceX transcript check; gas unmeasured); each entry RELEASED before its deadline xor CANCELLED after it

Every action is permissionless: amount and destination are fixed by the deposit or the Ethereum event, so execution is open and ownership does not exist. A bounded model check (research/arv/arv_model.py) explores every order of events with users, relayers and an attacker who holds funds: a key or M-of-N reserve can be taken (DESIGN FAIL); the keyless rules lose or duplicate nothing and every user can finish or cancel alone; a SOST reorg deeper than the confirmation depth breaks the backing. Evidence, not a formal proof. Remaining trust: SOST PoW majority (weak while mining is concentrated, so amounts must be capped), more than 2/3 of Ethereum's 512-member sync committee, code correctness, one honest relayer, bootstrap checkpoints; every Ethereum hard fork needs a SOST release first, or the reserve waits frozen. Both rules are a hard fork: NOT in V17 (#40,000); better as V18, after a devnet PoC of N1 + N2 and an external review. No bridge is 100% trustless; the aim is no custodian, no admin key, no multisig and no human approval.

3.16.2 Conventional reference model — lock / mint (C701/C703 prototype)

Invariants and backing (conventional reference)

Example 1,000 SOST locked in the Bridge Vault → 1,000 wSOST minted on Ethereum Native SOST never burned: it is locked, and released when wSOST is burned (only wSOST is ever burned) Backing backing of wSOST = native SOST locked = wSOST minted (in base units) The XAUT contribution never reduces the amount minted Burning N wSOST entitles the release of N SOST (minus the published SOST network fee) No wSOST without a verified, confirmed native deposit · gold never mints wSOST · DTD Jackpot funds never used

The XAUT contribution (Gold Access Key) is NOT backing of SOST or wSOST, NOT a peg, NOT a price floor, NOT a price guarantee, NOT a redemption promise and NOT 1:1 gold backing. Gold held by Gold Reserve V2 gives no individual redemption right.

Five accounts, never combined

1 native SOST · 2 bridge-locked SOST · 3 wSOST (= box 2) · 4 Gold Reserve V2 (XAUT; PAXG gated) 5 historical Gold Vault + PoPC (frozen since #25,000, committed to the DTD Jackpot)

Flow of the conventional reference prototype (lock/mint)

SOST → wSOST request (requestId = hash of chainId, contract, recipient, amount, vault, salt) → deposit to the Bridge Vault with capsule C701:0x<requestId> on that output → verification engine checks vault, exact amount, capsule, 30 conf. (provisional), unspent, unused → one EIP-712 authorization (chainId, contract, recipient, amount, txid:vout, expiry, nonce) + separately signed XAUT/EUR quote → ONE Ethereum tx: XAUT Gold Access Key → Gold Reserve V2, exactly N wSOST → user wSOST → SOST any holder burns N wSOST (no XAUT) → vault releases N SOST minus the SOST network fee (capsule C701R:0x<releaseId>) → verified and recorded on Ethereum A transaction hash typed by a user is a search hint, never proof.

Gold Access Key

feeEUR = min(250, max(0.50, bridgeValueEUR × 0.001)) 0.10% · min 0.50 EUR · max 250 EUR feeXAUT = feeEUR / verified XAUT price, rounded UP to XAUT's 6 decimals (integer math) minimum operation 100 EUR · 100% to Gold Reserve V2 · Ethereum gas paid by the user, shown separately no XAUT contribution on the return path (wSOST → SOST) fixed illustrative price 1 XAUT = 3,713.13 EUR (2026-10-19, illustrative, not a quote): 100 EUR → 0.000135 XAUT · 1,000 EUR → 0.000270 · 10,000 EUR → 0.002694 100,000 EUR → 0.026932 · ≥ 250,000 EUR → 0.067329 (cap)

The cap was revised from 50 EUR to 250 EUR on 2026-10-26: at 1,000,000 EUR the effective rate is 0.025%, against 0.005% with a 50 EUR cap. Fees of other bridges price capital, relayers and gas and are not directly comparable to this contribution.

How it differs from most bridges

family who decides a deposit is real pool who keeps the fee custodian / multisig custodian or N-of-M keys no custodian / merchants liquidity network relayers / pool protocol yes LPs, relayers, treasury guardian / messaging external guardian set no relayers / protocol issuer burn-and-mint the issuer no - (gas only) rollup / light client the destination chain itself no - (gas only) SOST bridge (design) SOST's automated engine no nobody: 100% to Gold Reserve V2

Most bridges pay their fee to liquidity providers, relayers, a treasury or token holders, and many depend on an outside key set or a pool (Ronin 2022: 5 of 9 validator keys; Harmony Horizon 2022: 2 of 5 multisig keys; Wormhole 2022: a signature-verification bug minted 120,000 wrapped ETH). The SOST design has no pool (always exactly 1:1), no outside federation, no fee on the return, and its fee builds a public gold reserve. It is not trustless: in its first version the engine is a single central point of trust, which is why it is not active. No bridge model is universally better.

State machine

CREATED → WAITING_SOST → SOST_SEEN / CONFIRMING → SOST_FINAL (30 conf.) → AUTHORIZED (EIP-712, 30 min) → WAITING_ETHEREUM → MINTED → COMPLETED exceptions: EXPIRED · PAUSED (burns continue) · RECOVERY_PENDING / REFUND_ELIGIBLE → REFUNDED (revoke on Ethereum first) · SECURITY_HOLD (reorg, inconsistency) never REFUNDED and MINTED for the same deposit · each (txid, vout) consumed once

Custody target with V17 (#40,000) native multisig: a 3-of-5 Bridge Vault, with spending keys separate from the Ethereum mint-authorization key. Status: not audited; contracts and engine are development prototypes. Full explanation, state names, comparison and worked examples: wSOST & Gold Vault.

SOST/EUR has no approved methodology: while it is absent the contract refuses every mint and the engine every request. The informational gold reference (0.8886707657 mg per SOST) is not a market price and is never used for fees.

Trust — stated plainly

Ethereum cannot read SOST, so in the current prototype backing is asserted by the operator's authorizer keys: a central point of trust. A compromised authorizer key could issue unbacked wSOST up to the per-mint, daily and exposure caps until reconciliation (BALANCED / PENDING / CRITICAL) pauses minting — this is why the design is not ready for production. Native SOST multisig is not active (planned for V17), so today the Bridge Vault could only be a single cold key with offline releases. A refund requires a final on-chain revoke and the expiry of every issued authorization, so nobody can keep both. Stronger options under study: SOST header relay with Merkle inclusion proofs, succinct validity proofs, delay/veto windows for large mints, threshold signing and native multisig.

BLOCKING SECURITY REQUIREMENT
A stolen verifier key must NOT allow minting wSOST without previously locked native SOST. Before production there must be a demonstrable property MINTED_WSOST <= VERIFIED_CONFIRMED_NATIVE_SOST_LOCKED, and the system must fail closed (no mint) whenever it cannot be demonstrated. The current prototype does not meet this yet.

Open blockers (public)

1 non-discretionary native reserve: no arbitrary withdrawal by its signers (P1-P5) 2 entry release authority: a stolen verifier key must not release unbacked wSOST 3 entry claim liveness: the reserve always claims before the user's deadline 4 secure native custody with V17 multisig (3-of-5 target) 5 testnet proof of concept (entry, exit, refunds, replay, reorg, concurrency, theft) 6 approved SOST/EUR valuation method 7 reliable XAUT price oracle 8 external security audit 9 legal / regulatory review

Gold Reserve V2 powers

withdraw(address) does not exist · issues nothing · provides no liquidity pause 2-of-5 moves nothing critical rescue 4-of-5 + delay only to the predefined Quarantine Vault final migration 4-of-5 guardians + YES ≥ ceil(2/3 × full eligible census) once governance is mature + timelock + exact successor vault named in the frozen proposal guardian recovery 4-of-5 + timelock, cancellable by any 2; never moves assets

SOST is not individually gold-backed: the reserve is restricted external ecosystem wealth with no individual right of redemption, parity, yield or guarantee.

Governance constitution

census eligible identities at the snapshot (mining + NODE_BIND + heartbeats); one identity = one vote vote self-transfer from the identity with capsule SOSTGOV1|<proposal>|S<snapshot>|YES|NO|ABSTAIN (28 of 80 bytes); last valid vote confirmed before the close counts approval YES ≥ ceil(2/3 × TOTAL census) — not of those who voted; ABSTAIN is never YES example census 12 → 8 YES needed · 8/2/2 approved · 7 YES + 5 no vote → not approved finality result final only after the close block is buried phase advisory first; binding only after objective maturity criteria (under research)

SOST votes do not execute Ethereum state: guardians do. Ignoring a valid vote would be publicly provable, not technically impossible — hence four layers: guardians, vote, timelock and destination-restricted contract. SOST and wSOST are never described as gold-backed, pegged, floored or redeemable.

HISTORICAL / SUPERSEDED DESIGN (kept for the record, never operational): the Gold → wSOST desk (selling existing treasury wSOST for XAUT at auction/TWAP prices), funding Gold Reserve V2 through that sale, 2-of-3 federated observer attestations with a relayer paying the mint gas, and the WSOST:0x… deposit capsule. It is not operational and is no longer the target architecture.

// POSITIONING

SOST vs other PoW chains

SOST is not positioned as a Bitcoin clone. It combines Bitcoin-like timing discipline, CPU-heavy original work, mathematical scarcity, and a constitutional reserve design. The four tables below place SOST against six well-known PoW chains so the reader can see exactly where the design overlaps and where it diverges.

Snapshot refreshed 2026-10-06 UTC — a point-in-time reading, not updated on every page load. The SOST row is live from the explorer; the six comparison chains are current heights as of that date. Drift = current height − expected, where expected = (now − chain genesis) ÷ canonical target spacing (computed two-phase for Monero and Zcash, which changed target). Block heights and schedule drift change every minute; see the live explorer at sost-explorer.html for the current SOST height. Sources for the comparison columns: Blockchain.info (BTC), Blockchair (LTC, DOGE, BCH, ZEC), moneroblocks.info (XMR).

1. Schedule — ahead, behind, or on time

Chain Target / block Height now Expected Drift Status
Bitcoin 600 s (10 min) 970,202 ~933,800 +36,400 Ahead ~253 days
Litecoin 150 s (2.5 min) 3,190,417 ~3,155,500 +34,900 Ahead ~61 days
Dogecoin 60 s (1 min) 6,546,187 ~6,749,600 −203,500 Behind ~141 days
Monero 120 s (60 s before 2016) 3,778,247 ~3,781,100 −2,900 Essentially on time
Bitcoin Cash 600 s 971,773 ~933,800 +37,900 Ahead ~264 days
Zcash 75 s (150 s pre-Blossom) 3,508,520 ~3,526,300 −17,800 Behind ~15 days
SOST 600 s 29,530 ~29,511 +19 Essentially on time

Reading: chains with bulk retarget (BTC, LTC) accumulate large positive drift because their hashrate has grown exponentially faster than two-week recalibration can correct. BCH switched to ASERT in 2020 and the drift growth flattened. Dogecoin’s drift is negative because its merge-mining economy with Litecoin and DigiShield retarget combine to produce blocks slower than its 1-minute target. Monero, Zcash and SOST track their schedule within a fraction of a day — the property delivered by per-block retarget.

Capacity & Scalability

Transaction capacity & scalability

Why ~7 TPS does not mean 7 transactions per block.

Why ~7 TPS ≠ 7 transactions per blockVERIFIED PARAMS

SOST is a Proof-of-Work, UTXO blockchain. Throughput comes from three verifiable consensus parameters: block size ≈ 1 MB (MAX_BLOCK_BYTES_CONSENSUS = 1,000,000), target spacing ≈ 600 s (TARGET_SPACING = 600), and a UTXO transaction whose serialized size varies with its inputs/outputs/data (a minimal 1-in / 1-out transfer ≈ 170 bytes). A block may hold up to 65,536 tx by consensus; the default miner template caps selection at 4,096.

~7 TPS does not mean each block has 7 transactions. It means: thousands of transactions fit in one block ÷ ~600 seconds ≈ average sustained TPS.

The formula
TX_per_block  ≈  usable_block_bytes / average_TX_bytes
TPS           ≈  TX_per_block / target_block_spacing

Worked example — if an average simple transaction were ~250 bytes:

1,000,000 bytes / 250 bytes  ≈  4,000 transactions / block
4,000 / 600 seconds          ≈  6.7 TPS
Capacity by transaction sizeAPPROXIMATE
Average TX sizeApprox TX / blockApprox TPS
170 bytes~5,800~9.7
200 bytes~5,000~8.3
250 bytes~4,000~6.7
300 bytes~3,300~5.5
500 bytes~2,000~3.3

Approximations, not a guaranteed maximum — they ignore header/coinbase overhead; transactions with more inputs/outputs or payload are larger. SOST can include several thousand ordinary transactions per block.

The mempool & daily capacityTHROUGHPUT

A full block does not drop transactions — the surplus waits in the mempool for the next blocks (fee-rate ordered, policy-limited):

10,000 transactions waiting
        ↓
  BLOCK 1  ~4,000 TX   →  ~6,000 remain
        ↓
  BLOCK 2  ~4,000 TX   →  ~2,000 remain
        ↓
  BLOCK 3  remaining TX
Daily capacity (illustrative)
Sustained TPSTransactions / day
5 TPS≈ 432,000
7 TPS≈ 604,800
10 TPS≈ 864,000

Theoretical/sustained illustrations — not current usage. One UTXO transaction can also pay many destinations at once (batching), so economic throughput can exceed one-payment-per-transaction.

Is 1 MB too small? What scaling would costTRADE-OFFS

For a young PoW network, ~1 MB is a conservative choice: low bandwidth, fast propagation, slow disk growth, cheap/accessible full nodes — all favouring decentralization.

Unused block capacity has no value by itself. The question is how much throughput the network actually needs while keeping node operation accessible and independently verifiable.
What a bigger block would cost (≈250-byte TX)
Block sizeApprox TPSChain growth (full blocks)
1 MB~6.7 TPS~52–53 GB/yr
2 MB~13.3 TPS~105 GB/yr
4 MB~26.7 TPS~210 GB/yr
8 MB~53 TPS~420 GB/yr

Growth figures are maxima if blocks were continuously full (~52,560 blocks/yr). Bigger blocks → more bandwidth, storage and propagation time, higher stale/orphan risk, costlier nodes, centralization pressure.

And a shorter block time?
Block timeApprox TPS (1 MB)A 288-block window is…
600 s (now)~6.7 TPS288 blk ≈ 2 days
300 s~13.3 TPS288 blk ≈ 1 day
120 s~33 TPS288 blk ≈ 9.6 h
60 s~67 TPS288 blk ≈ 4.8 h
Changing block time is not a simple performance switch. It would ripple through cASERT/difficulty, propagation, stale/orphan behaviour, forks/reorgs, SACS, DTD & Jackpot windows, emission timing, timestamps, wallets, miners, explorer math — and every rule expressed in block counts. It would require a hard fork plus a serious redesign and test.
Honest comparison — top 10 PoW + non-PoW contrastSOURCED & LABELLED
TPS figures across blockchains are not directly comparable. Transaction complexity differs (UTXO vs account), smart-contract execution differs, vote/consensus transactions may be counted differently, block/slot architectures differ, and theoretical, benchmarked and observed TPS are different metrics. This is not a marketing leaderboard.
Top Proof-of-Work chains (SOST’s camp)
NetworkConsensus / modelBlock / slotApprox TPSHow measuredTrade-off
SOSTPoW · ConvergenceX (CPU) · UTXO~1 MB / ~600 s~5–10protocol-capacity estimate — not benchmarkedsecurity + decentralization
BitcoinPoW · SHA-256d · UTXO~1–4 MB wt / ~600 s~7 (up to ~27 batched)practical, weight-dependentmaximum security; ASIC
LitecoinPoW · Scrypt · UTXO~1 MB / ~150 s~56 (capacity)capacity (faster blocks)faster settlement; ASIC
DogecoinPoW · Scrypt (merged) · UTXO~1 MB / ~60 s~33 (capacity)capacityfast/cheap; merge-mined
Bitcoin CashPoW · SHA-256d · UTXO~32 MB / ~600 s~100–200+ (capacity)capacity (big blocks)throughput → heavier nodes
MoneroPoW · RandomX (CPU)dynamic / ~120 s~a few (flexible)dynamic block + privacyprivacy + CPU mining
Ethereum ClassicPoW · Etchash · EVMgas-limited / ~13 s~15 (gas-limited)gas-limitedEVM + PoW
ZcashPoW · Equihash · shielded~2 MB / ~75 s~27 (capacity)capacity (shielded heavier)zk privacy
DashPoW · X11 · UTXO~2 MB / ~150 s~28–56 (InstantSend)capacity / InstantSendinstant & private send
KaspaPoW · kHeavyHash · BlockDAG~1 block/s~hundreds–1,000shigh block rate (GHOSTDAG)high PoW TPS → heavier bandwidth
RavencoinPoW · KAWPOW · UTXO~1 min~tens (capacity)capacityasset issuance
For contrast — high-throughput non-PoW
NetworkConsensus / modelApprox TPSHow measuredTrade-off
Ethereum (L1)PoS · account/EVM~15 (L1)gas-limited; scales on L2decentralized, L1-limited
TRONDPoS (27 super reps)~2,000 (claimed)claimed; real throughput questioned lowerfew producers → more centralized
SolanaPoH + PoS · parallel~65,000 theo. / ~1–3k realtheoretical vs observed non-votevery high TPS; high-spec validators

The high-TPS chains reach those numbers with a very different, more centralized architecture. SOST deliberately sits in the Bitcoin camp — trading raw throughput for security, decentralization and CPU-fair mining anyone can verify.

Where SOST stands & future researchFUTURE · NOT CONSENSUS
The objective is not the highest TPS number — it is the highest useful throughput SOST can safely support without compromising the ability to run and independently verify the network.

Current priority order: security → decentralization → node accessibility → reliability, before raw TPS.

Future scalability is RESEARCH, not consensus. No announced change, no activation height, no commitment to larger blocks or shorter block times. Possible research: transaction batching, more efficient serialization, UTXO consolidation, native-asset efficiency, and block-size / block-time lab experiments measuring sustained & peak TPS, propagation p50/p95/p99, CPU, RAM, disk, bandwidth, mempool, stale/orphan rate, sync and the effect on low-resource and distant nodes.

Verified from source: consensus_constants.h (1,000,000 B), params.h (600 s), transaction.cpp (input 133 B, output 30 B+), mempool.h (template 4,096). External figures are approximate and labelled by how measured; capacity ≠ current utilization, theoretical ≠ benchmarked. Sources: ethereum.org; TRON network-claimed ~2,000 TPS (real throughput questioned in public reporting); Solana docs/explorers (~65,000 theoretical vs ~1,000–3,000 real non-vote); other PoW figures are approximate protocol capacities.

2. Emission and supply

Chain Block reward (now) Next change Final supply Notes
Bitcoin 3.125 BTC 2028 → 1.5625 21,000,000 BTC Halvings every 210k blocks (~4 yr)
Litecoin 6.25 LTC ~2027 → 3.125 84,000,000 LTC Halvings every 840k blocks (~4 yr)
Dogecoin 10,000 DOGE (fixed) never No cap Perpetual inflation, ~5.26 B DOGE / yr
Monero ~0.6 XMR (tail) fixed since 2022 ~18.4 M + tail Tail emission 0.6 XMR/block forever from June 2022
Bitcoin Cash 3.125 BCH 2028 → 1.5625 21,000,000 BCH Inherited BTC’s halving calendar at the 2017 fork
Zcash 1.5625 ZEC 2028 → 0.7812521,000,000 ZEC Halvings every 4 yr
SOST 7.85100863 SOST (epoch 0) block 131,553 (~2.5 yr) 4,669,201 SOST Continuous decay q = e−1/4 ≈ 0.7788 per epoch

Bitcoin and its derivatives use discrete halvings. Monero and SOST use continuous decay. Doge does not decay at all (perpetual inflation). Monero’s tail emission means its supply has no asymptote — only a curve that flattens to a constant absolute issuance.

3. PoW algorithm and difficulty retarget

Chain PoW algorithm Dominant hardware Retarget Notable design
Bitcoin SHA-256d (double SHA-256) ASIC Bulk every 2,016 blocks (~14 d) The original. Stateless flat hash.
Litecoin Scrypt ASIC Bulk every 2,016 blocks (~3.5 d) Scrypt holds a 128 KB working buffer; ASIC-friendly since 2014.
Dogecoin Scrypt (merge-mineable with LTC) ASIC via LTC DigiShield (per-block) since Feb 2014Security tied to Litecoin’s merge-mined hashrate.
Monero RandomX CPU (deliberate)LWMA (per-block, 720-block window) CPU-oriented VM with JIT execution of randomised bytecode programs and a multi-MB-class dataset/cache plus per-execution scratchpads. ASIC-hostile by construction.
Bitcoin Cash SHA-256d (same as BTC) ASIC ASERT (per-block) since Nov 2020 Per-block since the post-fork DAA bug of 2017.
Zcash Equihash ⟨200, 9⟩ ASIC (since 2018) DigiShield-like (per-block, EMA) Originally GPU-friendly memory-hard; ASICs reached the chain by mid-2018.
SOST ConvergenceX CPU + 8 GB RAM cASERT (per-block, avg288 + E/B/H equalizer profiles) Native, original algorithm — not a fork. Solves a 32×32 SPD linear system across 100k sequential rounds of integer-only gradient descent and proves the solution sits in a stable basin (Proof of Irreversible Convergence). 256-op per-block program. 4 GB dataset + 4 GB scratchpad per mining thread.

4. Properties at a glance

Property BTC LTC DOGE XMR BCH ZEC SOST
Hard cap ✓ 21M ✓ 84M ✗ infinite ✗ tail ✓ 21M ✓ 21M ✓ 4.67M
Per-block retarget ✗ bulk ✗ bulk ✓ DigiShield ✓ LWMA ✓ ASERT ✓ DigiShield ✓ cASERT
CPU-oriented PoW ✗ ✗ ✗ ✓ RandomX ✗ ✗ (was GPU) ✓ ConvergenceX
Memory-hard footprint ✗ ~ 128 KB ✗ ✓ RandomX (multi-MB class) ✗ ~ partial ✓ 8 GB total
Native (not a fork) ✓ ✗ ✗ ~ CryptoNight lineage ✗ BTC fork ✗ Equihash ✓ ConvergenceX original
Constitutional reserve ✗ ✗ ✗ ✗ ✗ ✗ ✓ 50% gold-linked
Default-private transactions ✗ ✗ ✗ ✓ ring + stealth ✗ ~ shielded opt-in ✗ (E2E layer in DEX/Talk)
Hard cap derived from a math constant ✗ ✗ n/a n/a ✗ ✗ ✓ Feigenbaum δ

Where SOST stands out among the chains in this table

  1. The only PoW algorithm in this table that is genuinely native and not derived. SHA-256d was Bitcoin’s original; Scrypt comes from Tarsnap; Equihash from Wagner’s generalised birthday. Monero’s RandomX is the closest other example of an originally designed algorithm, but it carries CryptoNight ancestry. ConvergenceX shares no core structure with any of these.
  2. The only hard cap in this table derived from a universal mathematical constant (Feigenbaum’s δ). The other caps are round numbers chosen for marketing alignment.
  3. The only chain in this table with a consensus-level allocation toward gold-linked reserves and custody mechanisms in its history: 25% Gold Vault plus 25% PoPC until block 24,999 (now frozen and funding the DTD Jackpot; 0% of new emission since V15). This is not a peg, not a redemption claim, not a stablecoin mechanic. The reserve ratio is observable on-chain, not contracted.
  4. Among the chains in this table, SOST combines per-block retarget with the largest mining-RAM footprint (8 GB) of any production CPU-oriented design. Monero is the only direct competitor on the CPU-friendly axis but uses a smaller working set.
  5. Tightest schedule alignment in the comparison: SOST is currently within ~13 blocks of its target, helped by cASERT’s 288-block average and dynamic delta cap (0% within ±15 s, then 0.5% / 1% / 2% / 3% by deviation).
  6. Hard cap lower than the major PoW comparables in this table. With 4.67M coins capped, SOST’s long-run scarcity is steeper than BTC, LTC, BCH, or ZEC. Whether that matters in market terms is a separate question.

Where SOST does not stand out — honestly

Comparison block last updated alongside the snapshot above. Tables refresh on each whitepaper revision.