SOST Whitepaper — ConvergenceX Proof-of-Work & metals reserve (historical)

    ⚠ 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:
    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.
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.
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.
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.
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:

Block reward split: 50% miner / 50% DTD since V15, block #25,000. The Gold Funding Vault and the PoPC Pool receive no new emission — their historical balances stay on chain and auditable, but nothing new flows in.
The DTD is permissionless. No PoPC bond, no whitelist, no registration: mining one valid block is what makes an address eligible. From #30,000 (V16) eligibility additionally requires having mined within the last 288 blocks.
#30,000 activates V16: DTD-normal eligibility changes and the DTD Accumulated Reward V2 becomes an independent, node-gated, PoW-weighted draw (first V2 draw #30,186). The same activation brings on-chain the native-asset layer (asset genesis / issue / transfer / burn, conservation + supply-cap safety, reorg-safe index), four tokenization modalities (Tokenize, Auction, Draw, Project Funding) and a SOST-layer DEX — all admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled (technical availability is not regulatory authorization; ordinary SOST transfers are unaffected). It is one activation, automatic, by block height. Current release: V30000 (tag v30000) — all three binaries (node, miner, cli) changed.
SOST is not backed by gold. The metals reserve is a Foundation-held reserve with published policy; it is not a peg, not a redemption right and not a claim on the protocol. Reserve status.

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:

Hysteresis — distinct activation and deactivation thresholds (higher to turn ON, lower to turn OFF).
Persistence — the condition holds across multiple consecutive windows before it counts.
Delayed activation — detection schedules activation at a known later height; it never switches immediately.
No oscillation — the gate cannot flip ON/OFF within short horizons.
Incentive compatibility — a miner must never gain by deliberately refusing NODE_BIND.

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.

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 4 GB scratchpad per mining thread — 8 GB total. 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

Every block coinbase is 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

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.

Title	SOST: Proof of Irreversible Convergence
Version	`v4.5` — March 2026
Authors	Neob (SOST)
Format	PDF
Status	Production (mainnet)

Table of Contents

OVERVIEW

Section 1	Abstract
Section 2	The Problem — PoW design space
Section 3	ConvergenceX: Proof of Irreversible Convergence
Section 4	Monetary Policy — Epoch-based emission with smooth exponential decay
Section 5	Gold Protocol Reserve — Heritage vault
Section 6	Proof of Personal Custody (PoPC)
Section 7	Governance Model — No consensus governance
Section 8	Economic Model — Demand, deflation, equilibrium
Section 9	Security Analysis
Section 10	The Constitution — C1–C15
Section 11	Roadmap
Section 12	Technical Specifications
Appendix A	Canonical Constants (Normative)
Appendix B	Serialization (Normative)
Appendix C	PRNG Specification (Normative)
Appendix D	Test Vectors (Normative)
Appendix G	Emergency 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.

GitHub	`github.com/sost-protocol/whitepaper`
IPFS mirror	Pinned — immutable content-addressed copy
Website	`sostprotocol.org/whitepaper`
Checksum	SHA-256 published in repository

AT A GLANCE

Key Specifications

Protocol Summary

GENESIS CONSTANTS

Name / Symbol	`SOST`
Genesis	`2026-03-15 18:00:00 UTC`
Algorithm	ConvergenceX (4GB, 100k rounds, sequential)
Block time	`600` seconds target
Max supply	`4,669,201.609` SOST (hard cap)
Min unit	1 stock = 0.00000001 SOST
Epoch	`131,553` blocks (~2.5 years, Feigenbaum α)
Initial reward	`7.85100863` SOST/block
Coinbase split	50% 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)
Difficulty	cASERT 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.0%); 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
Reserve	Heritage (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 / ICO	`0` — none
Consensus governance	None — 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.

Component	SOST	Bitcoin 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 + docs	212,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:

SOST-side consensus — LIVE since #16,000 (V14.5); relay/policy flag-day #17,000 (V14.7). HTLC_LOCK (R17), HTLC_CLAIM (R19-R22), HTLC_REFUND (R23-R24) validation rules are in src/tx_validation.cpp; nodes have accepted HTLC transactions since #16,000.
Wallet, RPC, and CLI — complete. createhtlclock, claimhtlc, refundhtlc, decodehtlc, gethtlcstatus are available.
EVM counterparty leg — lab-verified (AtomicSwapHTLC.sol, 57 Foundry tests + full end-to-end run on a local Anvil node); not deployed on mainnet.
BTC counterparty leg — lab-verified on Bitcoin Core regtest (P2WSH funding, preimage claim, refund, reorg test); BTC signing is OFF by default (CMake flag) and not compiled into the official binaries.
Public use — real cross-chain swaps remain founder-testing only, pending an external cryptographic + economic review. The community OTC board can coordinate swaps, but the protocol provides no escrow, custody or dispute resolution.

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:

Load only the official URL: sostcore.com or sostprotocol.com. Never click a link from a DM.
Read the signed offer fields before signing. Counterparty address, amount, expiry — all visible, all binding.
Verify counterparty addresses against the LOCK / escrow payload. The signed payload is authoritative; chat messages are not.
Confirm txids on-chain (SOST explorer or Etherscan) before releasing anything. Screenshots are not proof.
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

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.

// 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 size	Approx TX / block	Approx 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 TPS	Transactions / 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 size	Approx TPS	Chain 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 time	Approx TPS (1 MB)	A 288-block window is…
600 s (now)	~6.7 TPS	288 blk ≈ 2 days
300 s	~13.3 TPS	288 blk ≈ 1 day
120 s	~33 TPS	288 blk ≈ 9.6 h
60 s	~67 TPS	288 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)

Network	Consensus / model	Block / slot	Approx TPS	How measured	Trade-off
SOST	PoW · ConvergenceX (CPU) · UTXO	~1 MB / ~600 s	~5–10	protocol-capacity estimate — not benchmarked	security + decentralization
Bitcoin	PoW · SHA-256d · UTXO	~1–4 MB wt / ~600 s	~7 (up to ~27 batched)	practical, weight-dependent	maximum security; ASIC
Litecoin	PoW · Scrypt · UTXO	~1 MB / ~150 s	~56 (capacity)	capacity (faster blocks)	faster settlement; ASIC
Dogecoin	PoW · Scrypt (merged) · UTXO	~1 MB / ~60 s	~33 (capacity)	capacity	fast/cheap; merge-mined
Bitcoin Cash	PoW · SHA-256d · UTXO	~32 MB / ~600 s	~100–200+ (capacity)	capacity (big blocks)	throughput → heavier nodes
Monero	PoW · RandomX (CPU)	dynamic / ~120 s	~a few (flexible)	dynamic block + privacy	privacy + CPU mining
Ethereum Classic	PoW · Etchash · EVM	gas-limited / ~13 s	~15 (gas-limited)	gas-limited	EVM + PoW
Zcash	PoW · Equihash · shielded	~2 MB / ~75 s	~27 (capacity)	capacity (shielded heavier)	zk privacy
Dash	PoW · X11 · UTXO	~2 MB / ~150 s	~28–56 (InstantSend)	capacity / InstantSend	instant & private send
Kaspa	PoW · kHeavyHash · BlockDAG	~1 block/s	~hundreds–1,000s	high block rate (GHOSTDAG)	high PoW TPS → heavier bandwidth
Ravencoin	PoW · KAWPOW · UTXO	~1 min	~tens (capacity)	capacity	asset issuance

For contrast — high-throughput non-PoW

Network	Consensus / model	Approx TPS	How measured	Trade-off
Ethereum (L1)	PoS · account/EVM	~15 (L1)	gas-limited; scales on L2	decentralized, L1-limited
TRON	DPoS (27 super reps)	~2,000 (claimed)	claimed; real throughput questioned lower	few producers → more centralized
Solana	PoH + PoS · parallel	~65,000 theo. / ~1–3k real	theoretical vs observed non-vote	very 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.78125	21,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 2014	Security 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

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.
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.
The only chain in this table with a consensus-level allocation toward gold-linked reserves and custody mechanisms: 25% Perpetual Gold Vault one-way TWAP purchases, plus 25% PoPC. This is not a peg, not a redemption claim, not a stablecoin mechanic. The reserve ratio is observable on-chain, not contracted.
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.
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).
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

Default privacy: Monero wins on transaction privacy by default. SOST has end-to-end encryption in DEX/Talk but the base ledger is transparent like Bitcoin.
Track record / hashrate / market depth: SOST is days–months old; BTC is 17 years old. Comparing security-economic depth today would be misleading.
Liquidity and exchange listings: SOST is pre-market — no exchange listings yet; exchange outreach is in progress. The chains in this table all have active markets.
External security audit: none yet. Independent reviewers welcome.
Post-quantum signature safety: the current scheme uses ECDSA over secp256k1 (canonical LOW-S) for transaction signatures and is not PQ-resistant; BIP-340 Schnorr is used only for SbPoW block-identity binding, not for spending. PQ migration is on the roadmap as a future hard fork.

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

Technical Whitepaper