Every SOST hard fork, network upgrade and milestone since genesis (2026-03-15) — ordered newest-first and explained in detail. This is the canonical changelog. Public announcements are cross-posted on the BitcoinTalk ANN thread. Public launch: 2026-06-16.
// MAINNET · VERIFIED ON-CHAIN · 11 OCT 2026
NODE_BIND is open: first bind #30,194, first heartbeat #30,196
DTD Jackpot V2 now has an eligible candidate for the next draw, #30,474
#30,194 — NODE_BIND (tx type 0x20) 36c2fc8c…cd90111 ✓ two signatures: mining key + node key #30,196 — NODE_HEARTBEAT (tx type 0x21) 4a7380a9…01e7268 ✓ emitted automatically by the bound node #30,474 — Jackpot V2 audit at #30,205: PoW candidates 2 · eligible 1 (NODE_BIND ✓, heartbeat 1/1) · pot 200 SOST (100 base + 100 rolled over from #30,186)
The first NODE_BIND under the V30000 two-signature rule was mined in block #30,194 — by a different miner from the one it binds, whose operator has confirmed running V30000 FINAL.1 — and the chain has kept building on it. Two blocks later, at #30,196, the bound node's automatic heartbeat confirmed. The go-ahead is therefore given: NODE_BIND is open for every miner running V30000 FINAL.
For miners who want the Jackpot
Create the bind with the V30000 FINAL CLI and broadcast it (step 7 of the upgrade guide).
Run your node with --node-key-file: from then on it signs one heartbeat per 288-block epoch by itself.
Check the result with checkhistoricaljackpoteligibility: node_bound, heartbeats_valid / heartbeats_required and pow_blocks.
For #30,474 the requirement is one heartbeat in epoch 0 (blocks #30,000–#30,287). A bind takes effect the block after it confirms, and the node stops attempting its epoch-0 heartbeat after #30,284, so a bind confirmed in good time before that still counts for #30,474. Later draws ramp up to 3 heartbeats in the last 4 epochs. Eligibility is decided at the draw by consensus; the audit above is a snapshot, not a result.
Explorer DTD Jackpot panel, snapshot at #30,197.
Sources: getblock #30,194 / #30,196 and getrawtransaction (tx types 0x20 / 0x21) and getjackpotv2audit 30474 on the public node; heartbeat window and bind activation in src/jackpot_v2.cpp and src/sost-node.cpp.
// MAINNET · VERIFIED ON-CHAIN · 11 OCT 2026
First Jackpot V2 draw #30,186: no eligible winner, 100 SOST rolled over
And why the normal DTD and the Jackpot are two independent draws
BLOCK #30,186
├ NORMAL DTD (every block) — winner paid 3.9255 SOST ✓
└ JACKPOT V2 (jackpot height) — PoW candidates 2 · eligible 0 (no NODE_BIND) → no winner · 0 SOST paid · +100 SOST rolled over
→ next draw #30,474 · pot 200 SOST
What happened
Block #30,186 was the first DTD Jackpot draw under the V2 rules active since #30,000. The node's canonical audit (getjackpotv2audit 30186) lists two miner identities with enough SbPoW blocks, but neither had a confirmed NODE_BIND, so no address was eligible. As the rule says, nothing was paid and the 100 SOST pot rolled over: the next draw at #30,474 carries 200 SOST (the cap is 500). Consensus behaved exactly as specified; the reserve was not touched.
The same block also paid its normal DTD — 3.9255 SOST to that block's DTD winner. That payment is not the jackpot. Earlier Explorer labels showed it as a "lottery winner" next to the jackpot panel, which made it look as if the jackpot had been won; the Explorer now separates the two draws everywhere (block detail, jackpot panel, archive) and counts draws, jackpots paid and no-winner draws separately.
Two draws, one block
Normal DTD — every block. Miners active in the recent window, minus the recent-producer cooldown (with a fallback when the cooldown would leave nobody) and the anti-dominance rule (applied when enough miners are active). Uniform pick. Pays 50% of the block subsidy.
Jackpot V2 — every 288 blocks.NODE_BIND + the required heartbeats (0 for the first draw, then one per completed 288-block epoch, ramping to 3 of the last 4) + at least 3 SbPoW blocks in the last 2,016. Pick weighted by those blocks. No cooldown, no anti-dominance.
Because the eligible sets and the rules are different, the two draws can pick different winners in the same block — one miner can take the normal DTD while another takes the jackpot. The same miner can also win both, if both draws select it.
Same public entropy, separate seeds
Both draws read the same public inputs: the hashes of the 16 previous blocks and the height. Each hashes them under its own domain tag — SOST_LOTTERY_V11 for the normal DTD, SOST_HIST_JACKPOT for the Jackpot — so each draw has its own seed and its own roll. Nothing is secret: anyone can recompute both winners (or the absence of one) from the chain.
For miners
To be eligible for #30,474 a miner needs a confirmed NODE_BIND and one heartbeat in epoch 0 (blocks #30,000–#30,287), emitted automatically by a node started with --node-key-file once its bind has confirmed. After #30,287 an epoch-0 heartbeat can no longer be added, so a miner that misses it is not eligible for #30,474; heartbeats in later epochs count toward later draws as the requirement ramps up.
Sources: getjackpotv2audit on the public node; consensus code src/jackpot_v2.cpp (eligibility, heartbeat window, weighted pick, seed domain), include/sost/lottery.h (normal DTD seed), src/node_participation.cpp (NODE_BIND / heartbeat checks).
// PROTOCOL · RESEARCH · 10 OCT 2026
Inside ConvergenceX: ASIC Resistance by Architecture
ConvergenceX: why Bitcoin ASIC hashrate does not translate to SOST
ConvergenceX does not try to beat ASICs at SHA-256. It changes the computational problem.
The problem it solves
Bitcoin's proof of work is a search: hash an 80-byte header with SHA-256d, change the nonce, repeat. Every try is independent, so the work parallelizes perfectly and fixed-function silicon wins by orders of magnitude. ConvergenceX was designed so that a single attempt is a long, memory-bound, sequential computation instead of one cheap, independent hash.
What one ConvergenceX attempt does
~8 GB working memory: a 4 GB dataset regenerated per block and a 4 GB scratchpad keyed per epoch.
100,000 sequential rounds. Each round runs a gradient step on a 32×32 integer linear system, reads four scratchpad words and one dataset word at addresses chosen by the current state, applies an instruction from a program derived from the previous block, and hashes the result into the next state. Round r+1 cannot start before round r finishes.
Stability basin: the final solution must survive perturbation probes — how many, and how strict, is set by consensus.
Checkpoints and Transcript V2: Merkle-committed checkpoints and segments let nodes verify a block in milliseconds without the 8 GB.
Commit: one hash binding all of the above, which must meet the target.
Two difficulty controls, not one
bitsQ sets the numerical target the commit must meet (Q16.16, adjusted every block). The Equalizer (43 profiles, E7–H35) sets the structural work profile — the perturbation probes and refinement steps a valid stability proof must survive. The profile index is bound into the commit, so nobody can mine with an easier profile than consensus requires.
Why Bitcoin TH/s does not carry over
A Bitcoin ASIC takes header fields in, sweeps nonces internally and only reports nonces that pass a target. It does not run programs, hold gigabytes of state or hand back intermediate hashes. ConvergenceX does use SHA-256, but as single SHA-256 on its own message formats, linking memory-bound and state-dependent steps whose next input depends on the previous output. So fixed-function Bitcoin SHA-256d ASICs cannot directly mine ConvergenceX, and a 4.8 TH/s Bitcoin miner is not a 4.8 TH/s SOST miner — the units measure different work. ConvergenceX performance is measured in valid attempts per second under the active bitsQ target and Equalizer profile.
What "ASIC-resistant" does and does not mean
ConvergenceX is ASIC-resistant by design: it is built to substantially reduce the advantage of fixed-function ASIC specialization. It is not a claim that specialized hardware can never exist. Any useful accelerator would have to implement the actual ConvergenceX workload — low-latency random access to gigabytes of memory, the sequential dependency chain and the per-block program — where today's CPUs are already well matched.
V30000 is active — optional node-only hardening (v30000-final.1)
Block #30,000 activated on schedule with no reorg, no rejected block and no node restart. Nodes and miners on V30000 FINAL need no action.
v30000-final.1 is an optional, recommended update for node operators: it replaces only sost-node and changes no consensus rule (blocks, rewards 50/50, supply and NODE_BIND unchanged). It hardens chain replay (a damaged chain file is never half-loaded), failed-reorg recovery (stop rather than serve partial state) and chain-file persistence during reorgs. sost-miner and sost-cli are byte-identical — miners do not recompile.
Release: releases/tag/v30000-final.1. Install: stop node → replace sost-node → verify SHA256 → start node (chain data kept). Update 11 Oct: NODE_BIND is open — first bind #30,194, first heartbeat #30,196 (see the NODE_BIND article above). Still on an older binary? Update to V30000 FINAL now.
// OPERATOR NOTICE · V30000 FINAL SECURITY BUILD · 2026-10-08
V30000 FINAL SECURITY BUILD — update node + miner + CLI before #30,000
A final pre-activation security review of V30000 found and fixed issues in transaction admission, native-asset validation, peer recovery after a chain split and NODE_BIND ownership. All earlier V30000 builds — the original v30000 release, v30000-rc1 and the intermediate emergency build — are SUPERSEDED. Do not install them. All three binaries changed; verify each against the official SHA256SUMS.
V30000 FINAL SECURITY BUILD commit 3acd952bd2c3
sost-node ef608cf9e7f6434f8d60b29c3287ca7045cb83de1be1ddf585a9176bf45b39cd
sost-miner 53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75
sost-cli 09d9a5022b3c03dfbe85df1ea728f931f5287712739921e17138e89dad14f62b
sha256sum -c SHA256SUMS # all three must print: OK
Activation is automatic at #30,000 by block height. Nothing needs to be restarted exactly at #30,000 — but every validating node and every miner must restart on this build between #29,900 and #30,000 and still run it at #30,000; older software may split from the chain and will not apply the new protocol rules.
Update 11 Oct 2026: the go-ahead is given — NODE_BIND is open. Until then the instruction here was to wait; the first bind confirmed at #30,194 and its first heartbeat at #30,196. Every miner must still be on this build.
NODE_BIND (after #30,000): a bind now carries a second signature by your node key, so only the holder of a node key can bind it. Command (unchanged): sost-cli --wallet <wallet.json> --mining-key-label <label> createnodebind 1 --node-key-file ~/.sost/node.key. After it confirms, check that the registered owner is your mining address and that your heartbeats follow. NODE_BIND only affects Jackpot eligibility; it gives no access to wallets and cannot create, spend or burn SOST.
Native Assets: DEFERRED / FAIL-CLOSED on mainnet. SACS V2: DEFERRED on mainnet.
Monetary rule unchanged: 50% miner / 50% DTD. SOST has no burn mechanism — none supported, none planned.
⚠ ALL NODES AND ALL MINERS: RECOMPILE (OR DOWNLOAD AND VERIFY) THE NEW BINARIES AND RESTART NODE AND MINER AFTER BLOCK #29,900 AND BEFORE BLOCK #30,000. Now — you can already build or download the FINAL binaries and verify their SHA256 (steps below). #29,900 → #30,000 — MANDATORY: restart your node and your miner on the FINAL binaries, and keep them running through #30,000. #30,000 — activation is automatic by block height. Otherwise there is a real danger of a CHAIN SPLIT, and the new protocol changes will NOT apply to your node or miner.
OPTION A · RECOMPILE FROM SOURCE (Ubuntu / Debian / WSL2)
Verified: a clean clone of the tag built exactly like this reproduces the three official hashes byte-for-byte (Ubuntu 22.04, gcc 11.4).
# 1. build dependencies (once)
sudo apt update
sudo apt install -y build-essential cmake git libssl-dev libsecp256k1-dev
# 2. get the FINAL source
git clone https://github.com/Neob1844/sost-core.git sost-v30000-final
cd sost-v30000-final
git checkout v30000-final
git log -1 --format=%H # must print 3acd952bd2c321fe9c6cb276259ff712d6b466bb
# 3. build — the build directory MUST be named "build"
cmake -S . -B build -DSOST_ENABLE_PHASE2_SBPOW=ON -DSOST_TESTNET_FORKS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target sost-node sost-miner sost-cli -j"$(nproc)"
# 4. verify
sha256sum build/sost-node build/sost-miner build/sost-cli
# ef608cf9e7f6434f8d60b29c3287ca7045cb83de1be1ddf585a9176bf45b39cd build/sost-node
# 53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75 build/sost-miner
# 09d9a5022b3c03dfbe85df1ea728f931f5287712739921e17138e89dad14f62b build/sost-cli
Different hashes? Your compiler or libraries differ from the reference build — use Option B. Never run a binary whose hash you cannot match.
OPTION B · DOWNLOAD THE OFFICIAL BINARIES
mkdir sost-v30000-final && cd sost-v30000-final
for f in sost-node sost-miner sost-cli SHA256SUMS; do
wget -q https://github.com/Neob1844/sost-core/releases/download/v30000-final/$f
done
sha256sum -c SHA256SUMS # all three MUST print: OK
chmod +x sost-node sost-miner sost-cli
RESTART YOUR NODE ON THE NEW sost-node — between #29,900 and #30,000
# systemd:
sudo systemctl stop sost-node
sudo cp /path/to/your/sost-node /path/to/your/sost-node.bak-before-final # rollback copy
sudo install -m 0755 build/sost-node /path/to/your/sost-node # (Option B: ./sost-node)
sha256sum /path/to/your/sost-node # ef608cf9e7f6434f...
sudo systemctl start sost-node
# by hand: stop it (Ctrl+C), then start the NEW binary with your usual flags
./sost-node --genesis genesis_block.json --chain chain.json \
--rpc-user <your-user> --rpc-pass-file ~/.sost/rpc.pass \
--profile mainnet --p2p-enc on
# check: up, on the chain, with peers
curl -s -u <your-user>:$(cat ~/.sost/rpc.pass) -H 'content-type: application/json' \
--data '{"method":"getblockcount","params":[],"id":1}' http://127.0.0.1:18232/
curl -s -u <your-user>:$(cat ~/.sost/rpc.pass) -H 'content-type: application/json' \
--data '{"method":"getpeerinfo","params":[],"id":1}' http://127.0.0.1:18232/
Your chain data is kept — no resync, no reindex.
RESTART YOUR MINER ON THE NEW sost-miner — between #29,900 and #30,000
# stop the old miner (Ctrl+C, or kill its PID — never a broad pkill on a shared box)
sha256sum build/sost-miner # 53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75
./build/sost-miner \
--wallet ~/sost-keys/my-wallet.json \
--mining-key-label "my-mining-key" \
--genesis genesis_block.json \
--rpc 127.0.0.1:18232 \
--rpc-user <your-user> \
--rpc-pass-file ~/.sost/rpc.pass \
--blocks 999999 --max-nonce 500000 \
--profile mainnet --realtime --threads <N>
--realtime is mandatory (without it every block is rejected: “timestamp too far in future”). Healthy miner output: bitsQ sync ... node canonical=..., [MINING] h=<height+1>, and on a find [BLOCK N] ... submitted to node OK.
NODE_BIND — OPEN SINCE 11 OCT 2026 (first bind #30,194)
The go-ahead is given. Use the FINAL CLI (same command, it now signs with both keys): ./build/sost-cli --wallet ~/sost-keys/my-wallet.json --mining-key-label "my-mining-key" createnodebind 1 --node-key-file ~/.sost/node.key. Then check that the registered owner is your mining address and that your heartbeats follow. NODE_BIND only affects Jackpot eligibility; it cannot touch wallets or create, spend or burn SOST.
Earlier news items below describe the superseded builds and are kept as history only.
2026-10-06 · Research note
How many transactions can SOST really process?
Short answer: ~5–10 TPS of protocol capacity today — and ~7 TPS does not mean 7 transactions per block. It means thousands of transactions per ~1 MB block ÷ ~600 s.
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 from verified consensus params (1,000,000 B block, 600 s spacing, ~170 B minimal transfer). One UTXO transaction can also batch many payments.
TPS across blockchains is not directly comparable — UTXO vs account models, contract execution, vote transactions, and theoretical vs benchmarked vs observed metrics all differ. Not a leaderboard.
Top Proof-of-Work chains (SOST’s camp)
Network
Consensus / model
Block / slot
Approx TPS
How measured
SOST
PoW · ConvergenceX (CPU) · UTXO
~1 MB / ~600 s
~5–10
protocol-capacity estimate — not benchmarked
Bitcoin
PoW · SHA-256d · UTXO
~1–4 MB wt / ~600 s
~7 (up to ~27 batched)
practical, weight-dependent
Litecoin
PoW · Scrypt · UTXO
~1 MB / ~150 s
~56 (capacity)
capacity (faster blocks)
Dogecoin
PoW · Scrypt (merged) · UTXO
~1 MB / ~60 s
~33 (capacity)
capacity
Bitcoin Cash
PoW · SHA-256d · UTXO
~32 MB / ~600 s
~100–200+ (capacity)
capacity (big blocks)
Monero
PoW · RandomX (CPU)
dynamic / ~120 s
~a few (flexible)
dynamic block + privacy
Ethereum Classic
PoW · Etchash · EVM
gas-limited / ~13 s
~15 (gas-limited)
gas-limited
Zcash
PoW · Equihash · shielded
~2 MB / ~75 s
~27 (capacity)
capacity (shielded heavier)
Dash
PoW · X11 · UTXO
~2 MB / ~150 s
~28–56 (InstantSend)
capacity / InstantSend
Kaspa
PoW · kHeavyHash · BlockDAG
~1 block/s
~hundreds–1,000s
high block rate (GHOSTDAG)
Ravencoin
PoW · KAWPOW · UTXO
~1 min
~tens (capacity)
capacity
For contrast — high-throughput non-PoW
Network
Model
Approx TPS
How measured
Ethereum (L1)
PoS · account/EVM
~15 (L1)
gas-limited; scales on L2
TRON
DPoS (27 super reps)
~2,000 (claimed)
claimed; real throughput questioned lower
Solana
PoH + PoS · parallel
~65,000 theo. / ~1–3k real
theoretical vs observed non-vote
The high-TPS chains use a more centralized architecture. SOST sits in the Bitcoin camp — trading raw throughput for security, decentralization and CPU-fair mining.
Scaling is research, not consensus. No announced change to block size or block time, no activation height. Bigger blocks / shorter block times trade accessibility and decentralization for throughput — see the full breakdown on the Transactions page.
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.
// ENGINEERING vs MATURITY · SOST V30000 FINAL CANDIDATE · 2026-10-05
Where SOST really stands — an honest comparison with Bitcoin and Ethereum
We separate the quality of the architecture we are building from the real maturity of a network that still has few operators and little time under real attack. The star ratings below are an orientative comparative judgement, not a scientific metric.
SOST V30000
BITCOIN
ETHEREUM
Area
SOST
Bitcoin
Ethereum
Technology / architecture
⭐⭐⭐⭐½
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
Software / protocol security
⭐⭐⭐½☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐½
Real decentralization
⭐⭐½☆☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐☆
P2P resilience / autonomy
⭐⭐⭐⭐☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
Adversarial testing
⭐⭐⭐⭐☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
Maturity / years under real attack
⭐☆☆☆☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
Operator / infrastructure diversity
⭐⭐☆☆☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐½
Release verifiability *
⭐⭐⭐⭐☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐⭐
Overall today
⭐⭐⭐½☆
⭐⭐⭐⭐⭐
⭐⭐⭐⭐½
* SOST has reproducible builds, verifiable SHA256 hashes and package self-verification; a signed release + independent distribution are still to be finalized. Stars are a comparative orientation, not a measurement.
These SOST notes are not theoretical. The current candidate has passed 122/122 consensus tests, SACS V2, SEC2, OLD↔NEW compatibility, partition/heal, SOSTCORE-DISAPPEARS 5/5, fuzzing, ASan/UBSan/LeakSan, P2P adversarial/eclipse/poisoning, reproducible build and package verification. The testing even uncovered a real remote-DoS (SIGPIPE) before release — now fixed; the follow-up disconnect-storm keeps node, RPC and file descriptors stable.
🏰 Bitcoin
A relatively simple castle that has been under attack for many years. Countless guards, independent gates and copies all over the world. If a company, a website or a server disappears, Bitcoin doesn't even notice. That is why it sits at the top on security and decentralization.
🏰 Ethereum
A far more sophisticated castle — more rooms, machines and possibilities than Bitcoin. That gives it enormous technology, but also more things to watch. Thousands of nodes, developers, clients and operators, and years of real-world operation.
🏰 SOST
A technologically ambitious castle, but much younger. The consensus is permissionless, yet until recently too many operational things could still depend on our own infrastructure. We are now removing those dependencies one by one — and testing that they are really gone.
DECENTRALIZATION — ARCHITECTURAL DIRECTION (target, not current mainnet state)
Nodes now remember peers, reconnect, exchange addresses (ADDR/GETADDR) and use independent seeds.txt. We ran a lab test that turned SOSTCORE off entirely: the chain kept going, a new node joined via seeds.txt, a restarted node recovered peers, and consensus needed no sostcore.com — SOSTCORE-DISAPPEARS 5/5 PASS. That is a major technical decentralization step.
BEFORE — SIGPIPE DoS
peer connects
↓
closes violently
↓
node tries to write
↓
SIGPIPE
↓
NODE DIES
Because "the software allows decentralization" is not the same as "the network is actually decentralized". We've done much of the first. The second needs people and infrastructure we don't control: if nearly all nodes, seeds, domains, the VPS, the mirror and almost all mining are ours, the network does not yet have Bitcoin-grade decentralization.
Why ⭐⭐⭐½ on security and not ⭐⭐⭐⭐⭐?
We're doing a lot right — SEC2, SACS V2, fuzzing, sanitizers, eclipse/poisoning/partition tests, reproducible builds, package verification, rollback — and these found the real SIGPIPE bug before release. But Bitcoin and Ethereum have endured years of real attacks with huge money at stake. You cannot manufacture 10 years of attacks in 10 days. The missing pieces — independent audit + real time under attack — cannot be fully accelerated.
A realistic target for SOST (not "as secure as Bitcoin")
SHORT TERM (V30000 + independent infra) MID TERM (operators+seeds+miners+ASN+mirrors+audit)
TECHNOLOGY ⭐⭐⭐⭐½ TECHNOLOGY ⭐⭐⭐⭐½
SECURITY ⭐⭐⭐⭐ SECURITY ⭐⭐⭐⭐½
DECENTRALIZATION ⭐⭐⭐ DECENTRALIZATION ⭐⭐⭐⭐
The 5th star of security and decentralization is not programmed — it is earned with time + independent operators + capital at risk + real attacks + external audits + surviving failures.
What has to happen next (no consensus change)
Independent node/seed on a different provider and ASN, ideally another country (not our VPS, not our domain).
A second and third genuinely independent seed.
External operators — someone who isn't us downloads SOST, verifies it, runs a node and stays connected without asking us for anything.
More independent miners. Peer decentralization without hashrate decentralization is incomplete.
Independent release mirror + signed release.
External code audit — consensus, SACS, P2P, and later S14/DEX.
More geographic and ASN/provider diversity.
Let time pass — months and years with nodes running, reorgs, server failures, upgrades and real attacks.
SOST is well advanced in engineering; now it has to turn that engineering into a network that can live without us.
Disclaimer. The star ratings are an orientative comparative judgement, not a scientific measurement. SOST does not claim to be "as secure as Bitcoin" or "fully decentralized". The V30000 FINAL CANDIDATE (commit 7b9ac273) is under test and not yet deployed; 78fefb67 remains the known-good baseline (which also carries the now-fixed SIGPIPE issue). Bitcoin and Ethereum names/logos are used for comparison only. No consensus, binary, activation height, SEC2 or SACS was changed by this page — documentation only.
SOST pushes toward maximum practical decentralization and mature-network security engineering
V30000 security is already frozen and verified. A V30000 FINAL CANDIDATE (V30000 baseline + D1/D2 peer autonomy) is now being stress-tested to reduce infrastructure dependency and strengthen autonomous peer discovery. It is not deployed.
Published: 2026-10-05 · chain height is read live (protocol-status.json + node), never baked in. Current: reading live…
In plain terms: SOST is trying to depend as little as possible on sostcore.com, any single server, any single bootstrap service and any single operator, while hardening the software against malicious inputs, RPC failures, peer poisoning, eclipse attempts, memory/resource abuse, network partitions and operator mistakes. The stated objective is maximum practical protocol autonomy — not a claim of “100% decentralization”.
PEER AUTONOMY (D1/D2) FINAL CANDIDATE · LAB VERIFIED · NOT YET PROMOTED TO MAINNET
Peer store — a node remembers verified peers and can reconnect to them after a restart.
ADDR / GETADDR — compatible nodes exchange peer addresses so the network can discover more peers autonomously.
seeds.txt — operators can configure independent bootstrap seeds without recompiling.
Automatic redial — a node that loses all peers actively retries known / configured / seed peers.
Backward compatibility — new nodes interoperate with existing V30000 nodes.
WHAT WE HAVE DEMONSTRATED IN LAB LAB VERIFIED
OLD↔NEW compatibility: PASS
Peer-store torture tests: PASS
ADDR parser fuzz: 200,000 iterations under ASan/UBSan
Adversarial / eclipse / poisoning tests: PASS
500,000 junk addresses tested with bounded memory impact
Lab tests demonstrate that the candidate can bootstrap and recover without sostcore.com when independent peer sources are available. This is a laboratory result, not a statement about current mainnet.
ARCHITECTURAL GOAL — not a statement of current mainnet state
The goal is that no single SOST-operated website, VPS, RPC endpoint or bootstrap service is required for the chain to continue operating. This is a TARGET / architectural goal, not today’s mainnet state.
SECURITY ALREADY IN V30000 LIVE / FROZEN
SEC2 RPC hardening
SACS V2 activating at #30,000
Native asset layer (admin-gated, public access disabled)
Existing consensus test battery
Gateway defense-in-depth
Hardened admin authentication / 2FA
Verified release hashes (node/miner/cli)
D1/D2 peer autonomy is not part of this LIVE set yet — it is the V30000 FINAL CANDIDATE under test.
LEARNING FROM MATURE NETWORKS
SOST cannot manufacture Bitcoin’s or Ethereum’s years of real-world operation, independent operators, adversarial exposure or external review. What SOST can adopt are mature engineering disciplines:
reproducible release build · verifiable package · known rollback path
CANDIDATE — subject to final gate. Not promoted until owner GO.
AFTER #30,000 — CODE IS ONLY PART OF DECENTRALIZATION EXTERNAL MATURITY
Beyond the software, decentralization then needs to grow in: independent third-party nodes, independent miners, geographic diversity, ASN/provider diversity, external seed operators, independent release mirrors, external security audit, independent code review, longer adversarial exposure and greater hashrate distribution.
These cannot be created by code alone. They require independent operators, time and external participation.
“SOST’s objective is not to claim decentralization. It is to remove dependencies one by one, test that they are really gone, and make the protocol increasingly capable of surviving without its original infrastructure or operator.”
Engineering decentralization now. Operational decentralization next. Network maturity over time.
Disclaimers. D1/D2 peer autonomy is a final candidate under test, not deployed to mainnet. Lab results show bootstrap/recovery without sostcore.com when independent peer sources are available; this is a laboratory result, not a claim about how the current mainnet bootstraps today. These engineering practices reduce risk but do not make SOST equivalent in security maturity to Bitcoin or Ethereum. SOST runs permissionless Proof-of-Work consensus; operational decentralization is an ongoing objective and SOST is not “fully decentralized”. No consensus, binaries, node, miner, hashes, activation height, SACS or SEC2 were changed by this update — news/documentation only.
SOST completes pre-#30,000 security, DEX, asset-registry and decentralization readiness work
Published: 2026-10-04 · current chain state is read live from protocol-status.json, not hard-coded here.
Recent work hardened the public surface and advanced the devnet DEX, the asset registry/attestation model and the decentralization toolkit. None of it changed consensus or the V30000 binaries — node/miner/cli remain byte-identical to the published release and still enforce V30000 at block #30,000.
Non-custodial cross-chain: signed offers / RFQ, HTLC settlement; SOST wallet controls the SOST leg, MetaMask the EVM leg; the server never receives keys/seed.
Devnet-implemented: SOST↔ETH, SOST↔USDC, wallet bridge, human-readable signing, anti-replay domain binding, 90-second firm quote, cancel-before-funding, settle-or-timeout/refund, visible lifecycle, token/contract allowlist + contract pinning, centralized timelock policy (SOST long leg 288 blk/~48h, EVM short ~24h, BTC short 144 blk/~24h, ~24h min safety gap).
PUBLIC TRADING: DISABLED · MAINNET EVM CONTRACT: NOT DEPLOYED · REAL FUNDS: NOT USED · BROWSER E2E: pending owner verification · EXTERNAL SECURITY AUDIT: NOT COMPLETED.
USDT / PAXG / XAUT: DISABLED. USDC: only the exact contract allowlisted per chainId. No real prices/liquidity/market.
C · TOKENIZATION / ASSET REGISTRY ADMIN-GATED @#30,000
Regulatory Record: jurisdiction, asset class, checklist version, document hashes, acknowledgement, history/versioning — folded into the Passport/manifestHash.
Professional Attestation model: client pays the expert directly (bring your own expert); expert issues a signed attestation; SOST verifies signature/credential/document-hash/expiry/lifecycle (ACTIVE/SUPERSEDED/REVOKED/EXPIRED). Types: LEGAL / OWNERSHIP / VALUATION; requirements vary by Tokenize / Auction / Project Funding / Draw. SOST verifies who issued it, not whether the opinion is correct.
Regulatory requirements by jurisdiction: 21 framework cards (EU/EEA, UK, Switzerland, Russia, US, Canada, Mexico, Brazil, Argentina, Chile, Colombia, China, Hong Kong, Singapore, Japan, South Korea, Australia, UAE, Saudi Arabia, South Africa, Nigeria) with official regulator links — informational orientation, not legal advice.
Native-asset protocol layer ships in V30000, activates #30,000, admin-gated (S14), public access disabled; no public marketplace.LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
D · SECURITY & DECENTRALIZATION
Security/ops: secret permissions hardened, exposed RPC credential rotated (old one rejected on auth-gated methods), HTTPS/TLS valid, DEX mixed-content fixed, private dashboards moved from Basic-Auth popup to custom server-side sessions (HttpOnly+Secure+SameSite cookies, deny-by-default, rate-limiting, logout), Network Health panel, protocol-status.json as single source of truth. No consensus/binary changes.
Decentralization (planned / in progress): general persistent peer store, ADDR/GETADDR peer gossip, independent/multiple DNS seeds, broader bootstrap independence, 24h primary-infrastructure independence test, future reduction/removal of S14 subject to readiness criteria.
Permissionless Proof-of-Work consensus architecture; operational decentralization is an ongoing engineering objective. A connected peer/IP is not evidence of an independent operator. Not “fully decentralized”.
Release-signing tooling (minisign/GPG) is prepared; offline key custody remains an owner operational step.
Web accuracy: 41-section factual audit completed, stale current-state claims corrected, duplicated global search fixed (one canonical search per page), explorer mute/replay overlap corrected.
E · FUTURE REWARD EVOLUTION RESEARCH · PROPOSAL · NOT CONSENSUS
Current consensus is unchanged: 50% miner / 50% DTD. SOST is simulating a possible mature-network evolution that gives more issuance directly to Proof-of-Work, a smaller continuous DTD, and a separate accumulated jackpot reserve — funded entirely from existing emission (no new supply).
This is a trade-off, not a free improvement. Simulation (S1 high-concentration): moving 50/50 → 75/20/5 raises the dominant miner’s share (36%→46% for 56% hash), lowers the small-miner uplift (2.58×→1.79×) and raises income inequality (Gini 0.26→0.39). 70/25/5 preserves more redistribution; 80/10/10 pushes furthest toward PoW. No model is declared “better” — it depends on future maturity and miner concentration.
Under study (ranges, nothing fixed): miner 70–80% / DTD 15–25% / jackpot 5–10%; jackpot interval ~2,500–5,000 blocks (block time verified 600 s). A key simulation finding: a uniform-per-identity jackpot is Sybil-gameable, so a large jackpot would need PoW-weighted, capped eligibility (V2-style), not a bare address/identity draw. No activation height. No final interval. No consensus change. Any implementation would require a hard fork. 75/20/5 is a candidate only.
⬢ 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.
SOST Protocol Decentralization Audit — from decentralized consensus to operational autonomy
SOST has completed an internal decentralization audit focused not only on consensus, but on the wider operational infrastructure required for the network to function independently.
Objective: move SOST toward the highest practical degree of decentralization and operational autonomy, so the protocol can continue functioning with minimal human intervention and without dependence on any single operator, server or organization.
SOST already operates as an open Proof-of-Work network in which blocks are produced and validated according to protocol rules rather than by a central authority. The audit nevertheless distinguishes between two different concepts.
1 · Consensus decentralization
The blockchain does not depend on a central database or administrator to decide which blocks are valid. Independent miners and nodes can validate blocks, verify Proof-of-Work, keep their own copy of the chain, reject invalid blocks, propagate transactions, and join or leave freely. No central server can rewrite balances, mint SOST outside the rules, or replace the canonical validation rules.
2 · Operational decentralization
A chain can have decentralized consensus while still depending operationally on a few infrastructure services. The audit therefore also examined bootstrap, peer discovery, DNS seeds, persistent peer databases, reconnect/redial, public RPC, explorers, software distribution, release verification, mining participation, independent operators, and recovery procedures. This is where SOST is still progressively reducing dependencies.
SOST is decentralized at the consensus layer today; the operational layer is being progressively decentralized.
What has already improved
Configured-peer redial is implemented for explicitly configured --connect peers (internally verified). General persistent peer storage and peer-address gossip (ADDR/GETADDR) are now implemented and internally verified in the SOST codebase, but are not yet in the currently-deployed mainnet binary — they are staged for an upcoming release.
External miners and nodes already operate independently from the core development infrastructure.
NODE_BIND and NODE_HEARTBEAT encourage real node participation, while Proof-of-Work remains the source of mining weight.
The protocol does not pretend that one cryptographic node identity necessarily equals one independent physical machine or one independent operator — that distinction is intentional and stated honestly.
What still depends on external infrastructure
Some services necessarily operate outside consensus: website hosting, DNS, public explorers, RPC gateways, software repositories, download mirrors, bootstrap nodes and monitoring. They improve accessibility, but must not become points of protocol control.
External infrastructure may help users find, observe or interact with SOST, but it should not determine consensus or be essential for the blockchain itself to survive. If an explorer goes down, blocks keep being produced. If the website disappears, nodes keep validating. If one VPS goes offline, independent peers keep relaying. If one bootstrap service fails, explicitly configured peers are re-dialled automatically; broader autonomous peer persistence is on the roadmap.
✗ Explorer goes down
✓ Blocks keep being produced
The explorer only observes the chain — it holds no consensus role.
✗ Website disappears
✓ Nodes keep validating
The site hosts no consensus logic.
✗ One VPS goes offline
✓ Independent peers keep relaying
No single machine is required to extend the chain.
✗ A bootstrap service fails
✓ Configured peers re-dial automatically
Broader autonomous peer persistence is on the roadmap.
Current decentralization priorities
More independent public nodes and more independent miners.
Multi-source peer discovery; no dependence on a single VPS or bootstrap node.
Open-source release infrastructure + multiple software distribution paths.
More external review of releases and protocol changes.
A prolonged test deliberately removing the primary infrastructure node (e.g. ~24h) to confirm independent nodes keep mining, validating and propagating — and documented recovery procedures.
Automation as a decentralization tool
The goal is not merely to distribute servers, but to reduce discretionary human intervention. Where possible, protocol behaviour is deterministic, height-triggered, self-validating, automatically recoverable, independently reproducible and observable from public chain state. For example, V30000 activates automatically at block #30,000 — no operator "switches on" consensus.
How SOST operates — deterministic, height-triggered, no operator switchroutine operation→rules→nodes→validation→automatic executionNot this — discretionary human controladministrator→manual decision→network action
Decentralization is a process, not a binary label
SOST does not claim decentralization is all-or-nothing. A network can be decentralized at consensus level while still improving the diversity of its infrastructure, operators and software distribution. SOST treats decentralization as a measurable engineering objective, not a marketing claim; future audits will keep examining miner concentration, node diversity, bootstrap dependencies, infrastructure concentration, software reproducibility, third-party participation and protocol autonomy.
External infrastructure may assist the protocol, but it must not control the protocol. No single server, operator, website, miner or organization should be required for SOST to continue validating and extending its blockchain.
Every fork, every incident, every fix — on the public record.
SOST does not quietly patch and move on. Each upgrade names its activation block; each incident below names the
root cause, the fix, and — where it applies — the community tester who caught it. Nothing is buried,
because a chain that asks you to verify everything must first be willing to be verified itself.
Code first. Proof first. The genesis hash, every fork height, every
post-mortem and every credited reporter are cross-checkable on the public
BitcoinTalk thread,
the GitHub history,
and the live explorer.
// ASSET REGISTRY · offering models · LIVE WEB (Tokenize) + LAB-VERIFIED demos
Published: 2026-09-29 · Last updated: 2026-09-29
SOST introduces a multi-model asset & project offering framework
One Asset (or Project) Passport, four ways to bring it to people: Tokenize, Auction, Draw, Project Funding.
Tokenize — CURRENT / LIVE WEB. Divide a right into token units (the existing Asset Registry v2).
Auction — FUTURE / LIVE DEMO / LAB VERIFIED. Highest valid signed bid wins; refundable bid escrow; reserve + anti-sniping.
Draw — FUTURE / REGULATED / LIVE DEMO. Tickets cover a minimum, then a third-party-verifiable commit-then-reveal draw (Spanish rifa rules apply).
Project Funding — FUTURE / REGULATORY-READY / LIVE DEMO. Fund something not built yet; all-or-nothing; milestone-gated releases; Project Passport → Asset Passport.
Real-funds execution is DISABLED for Auction / Draw / Project Funding — full engines + live demos + tests only, pending legal framework and settlement rail. Engines: Auction 29/29, Draw+Funding 25/25 tests. No consensus/V16/#30,000/STRATO change. Open the offering models
// ASSET REGISTRY · Asset Passport v2 · REGISTRY V2 — LIVE WEB / ANCHOR-READY · web/lab, no consensus change
Published: 2026-09-29 · Last updated: 2026-09-29
Asset Passport v2 introduces Claims + Provenance
SOST Universal Assets moves from a tokenization sheet to a real registry: every material statement about an asset is now a typed claim that records what it is, who says it, its source/evidence, its verification status, when, and a confidence — sealed into a reproducible manifestHash anyone can re-check.
What shipped. The Asset Registry now builds Asset Passport v2 records from typed claims — Identity, Ownership Declaration, Valuation, structured Rights, Documents and a Settlement reference — each carrying its own provenance and verification. A roll-up summarises the record (economic rights declared, obligor identified, agreement attached, independent verification) without ever hiding a single claim's state, and always states LEGAL CLASSIFICATION: NOT DETERMINED BY SOST.
Structured Rights. A token must say what it represents: Certificate · Usage right · Revenue participation · Sale-proceeds participation · Ownership/equity-like · Custom — with obligor, agreement reference and agreement hash recorded as facts.
Integrated valuation. Asset Intelligence output now flows in as a provenance-carrying VALUATION claim (methodology, assumptions, confidence, timestamp) — one conceptual model, not two.
Tokenization Studio → Passport. What you enter in the Studio now generates a real v2 passport: claims, roll-up, manifestHash and an anchor-ready doc_ref payload.
Liquidity honesty. Valuation, reference price, executable liquidity, market depth and executability are shown as five distinct things; SOST price rows are labelled arithmetic scenarios, never quotes; with no verifiable book, executable liquidity reads NOT VERIFIED.
Full v1 compatibility. Existing v1 passports are never rewritten, keep their original hash and still verify exactly; v2 reads them through a normalized claims view. Neither format is obsolete.
Reproducible hashing + tamper detection. Canonicalization is pinned by an official test-vector contract in the repo, so a third party can reproduce any manifestHash byte-for-byte; changing one byte changes the hash. 77/77 Asset Passport v2 tests pass.
Guided flow — ASSET → RIGHT → TOKEN → PASSPORT. A four-step wizard drives the Claims engine underneath (claims, provenance, valuation, canonical hash) so a non-technical owner produces a verifiable Asset Passport without touching JSON. It covers physical assets, debt/receivables, equity-like rights, royalties and custom rights, generates an automated legal-readiness note (not a legal determination), and ships loadable DEMO examples (mining, real estate, debt, royalty). A comparison against Tokeny, Securitize, Mattereum and Centrifuge is on the same page.
Registry vs protocol layer vs marketplace.Asset Registry = CURRENT (web: claims, provenance, valuation, rights, passport, hashing, anchoring, verification). Native-asset protocol layer = IN V30000, admin-gated — the on-chain asset primitives (genesis/issue/transfer/burn) + tokenization modalities + SOST-layer DEX ship in the V30000 release and activate at #30,000 (automatic by height) but are admin-gated at consensus (S14 RESTRICTED DEVELOPER MODE) with public access disabled. Public regulated marketplace = NOT LIVE (no public trading, no custody, no regulated settlement). Implemented protocol primitives are not a public marketplace.
Status is exact. The Registry is live on the web and passports are anchor-ready; the on-chain anchor round-trip has been verified on a development chain. It is not claimed as a mainnet anchor until demonstrated on mainnet. No consensus, node, supply or V16 (#30,000) behaviour is touched.
// ENGINEERING · LAB VERIFIED · not on testnet or mainnet
Published: 2026-09-29 · Last updated: 2026-09-29
Atomic swaps and on-chain Asset Passport reach laboratory verification
Three engineering workstreams crossed from "code" to "runs end-to-end against real infrastructure" — in a local laboratory only. None is enabled on testnet or mainnet, and none touches SOST consensus or funds.
EVM atomic swap — LAB VERIFIED. The HTLC contract passes 57 unit tests (including non-standard-return, fee-on-transfer, reentrancy, wrong-preimage and timeout cases) and a full end-to-end run on a live local Anvil node (native + ERC-20 claim, wrong-preimage revert, refund after timeout).
BTC atomic swap — LAB VERIFIED. Real Bitcoin Core regtest: exact P2WSH funding, preimage reveal and claim, plus a reorg test where the claim returns to the mempool. Bitcoin signing stays OFF by default.
Asset Passport on-chain — LAB VERIFIED. A full capsule doc_ref round-trip on a development chain: manifest hash → signed capsule tx → node acceptance → mined block → read-back → hash match → tamper test. Mainnet anchoring remains a future, authorised step.
V16 cutover safety battery — LAB VERIFIED. The V16 activation lifecycle exercised on an isolated fast devnet. Mainnet V16 still activates at #30,000 — unchanged.
Why the label matters. "Runs on regtest / Anvil / devnet" is not "live on mainnet". Each item above is real, reproducible laboratory evidence — and is labelled exactly that. Atomic Swap / DEX · V16 schedule
V30000: the #30,000 network upgrade is released — swap all three binaries
SUPERSEDED — this release is replaced by the V30000 FINAL SECURITY BUILD (see the top of this page). Do not install the binaries described here.
All three binaries changed — sost-node, sost-miner and sost-cli; none are byte-identical to v16.2.x. #30,000 activates the full V30000 bundle (DTD Accumulated Reward V2 plus the admin-gated native-asset / tokenization / DEX layer, public access disabled); the first DTD Accumulated Reward V2 is still #30,186.
The fix. A node built from v16.2.3 could not complete a full synchronisation from block 0: it stopped on 66 historical blocks (heights 4,160–5,410) mined in April 2026 under consensus parameters that were later changed. V30000 pins each of the 66 by height and full block hash — changing no rule for any new block — and also fixes P2P block serving and a sync-time rate-limit that could ban the peer serving you the chain. A full genesis→tip sync was verified end to end, encrypted and plaintext, matching the reference node with zero rejects; 119/119 tests pass.
All three binaries changed.sost-node, sost-miner and sost-cli are not byte-identical to v16.2.x — re-download, verify and swap all three.
SUPERSEDED — do not install: original V30000 SHA-256 node 78fefb67… · miner eec96efb… · cli c8ae00b9…. Use the V30000 FINAL SECURITY BUILD (top of this page).
What #30,000 activates: DTD Jackpot V2 and the native-asset / tokenization / DEX layer — the asset layer is admin-gated at consensus and public access is disabled (technical availability is not regulatory authorization). Ordinary SOST transfers are unaffected.
Current official binaries — verify before running anything:
NOT YET ACTIVE · checking the chain… V30000 is the current release. All three binaries changed (node, miner and CLI; none byte-identical to v16.2.x) — re-download, verify and swap all three before #30,000. Activation itself is automatic, by block height: nothing to run at that block.
What activates. Two things, one activation. DTD-normal eligibility is re-pointed at current miners — recency drops to 288 blocks at every height, the 6-block producer cooldown yields when applying it would leave the draw with nobody, and the 10%/288 anti-dominance gate is armed only at 11 or more distinct miners. And the DTD Jackpot becomes an independent draw (V2): node-gated by NODE_BIND plus heartbeats, weighted linearly by SbPoW blocks in the previous 2,016, with no cooldown and no anti-dominance.
First DTD Accumulated Reward V2 draw: block #30,186 — it requires a valid NODE_BIND and ≥3 SbPoW blocks in the previous 2,016, but zero heartbeats (0/0): no epoch has completed yet, so nobody is excluded for lacking history. The requirement ramps 1/1 → 2/2 → 3/3 and settles at the permanent 3-of-4 from #31,338. That ramp is one rule counting epochs, not a second fork.
Payout economics unchanged: base 100 SOST, rollover to a 500 SOST cap, spent from the existing historical reserve. No new emission.
DTD-normal needs no NODE_BIND, no heartbeats and no PoPC bond — it stays permissionless at every height.
A validating node still on pre-V16 software after #30,000 may diverge. The window is a coordination decision, not a consensus rule.
// RELEASE · v16.2.3 · official binaries published · consensus unchanged
Published: 2026-09-23 · Last updated: 2026-09-23
v16.2.3: no credential this protocol asks you to handle needs to live in argv
Four releases in the v16.2.x line, all shipping the same node and miner binaries — only the CLI changed. Consensus is untouched: V16 still activates at #30,000 and the first Accumulated Reward V2 is still #30,186.
The problem. Until now the RPC password, the node heartbeat key and the wallet passphrase all had to be typed on a command line or echoed on screen. /proc/<pid>/cmdline is world-readable, so ps handed them to any other local account on the machine.
node:--rpc-pass-file and --node-key-file, so a systemd unit names a path instead of expanding a password into ExecStart.
miner:--rpc-pass-fd, --rpc-pass-file, --wallet-passphrase-file. --rpc-pass still works and now warns that ps can see it. An HTTP 401 on submit says what it means — the credentials are wrong and the block was never validated — instead of looking like a rejected block.
cli:createnodebind / nodeheartbeat take --node-key-file or --node-key-fd; wallet-export and wallet-import prompt with the terminal echo off.
A secret file must be mode 600, owned by you, one line and nothing else. Group- or world-readable is refused, not read with a warning, and no error ever echoes what it rejected.
Encrypted (v2) wallets work end to end and do not change your mining identity or payout address. v1 wallets keep working, with no conversion and no deadline.
Why .1, .2 and .3 followed. An audit asked which code paths really used the strict JSON parser, and the ones handling funds did not: a large getaddressutxos could be truncated (chunked replies, case-sensitive header search), send decided acceptance by substring search on a 4 KB read, and cancel-tx could silently drop transaction inputs. The last one, in v16.2.3, matters for the Jackpot: createnodebind always bound the key labelled default, so any miner whose signing key carries another label could not produce a valid NODE_BIND at all. It now takes --mining-key-label.
Official binaries are downloadable for the first time in this cycle — no compiler needed:
b253e4a9c352ea4b8557eec78d57e1c7619ab267af228c3e8f24bf8d7b69b897 sost-node (same in v16.2.0/.1/.2/.3) 2ef9d0a77f243224ac088460818d6b360c689a7a3fa9555738e2b3b3e0112fe2 sost-miner (same in v16.2.0/.1/.2/.3) 489f43741437a08b2d617c21020061c042f42d4609bbe6547d28f08ca5e07d07 sost-cli (v16.2.3)
Release and SHA256SUMS · verify with sha256sum -c SHA256SUMS before running anything. If you build it yourself the build directory must be named build: the source path is normalised out of the binary, the directory name is not.
// DOCUMENTATION · gold vault & PoPC moved to historical record · 63 pages audited
Published: 2026-09-23 · Last updated: 2026-09-23
The site now says what the node enforces: 50% miner / 50% DTD
Since V15 at block #25,000 the Gold Funding Vault and the PoPC Pool receive no new emission. Every page that still described the old 50/25/25 split as current has been corrected or dated.
What was wrong. The homepage hero still told a new visitor that every block allocates 25% to a Gold Vault and 25% to PoPC, "hardcoded at genesis". The FAQ said the same, the protocol spec validated blocks against "the 50/25/25 split" without mentioning that the rule changed at #25,000, and the Gold Reserve page reported a green ACCUMULATING status for a vault that has received nothing since V15.
Worse, and now fixed: the whitepaper stated in two places that the DTD reward would require an active PoPC bond from block 30,000. It does not, at any height. On mainnet the PoPC eligibility gate ships deactivated and the DTD is permissionless — mining one valid block is the only requirement.
Nothing was deleted. Blocks 0–24,999 really were paid 50/25/25 and any validator still reproduces them, so the historical rule is kept, dated and visibly historical.
Nothing was burned or redirected. The vault and pool addresses still hold what they received and remain auditable in the explorer; the DTD Jackpot returns that reserve to active miners as a supply-neutral spend.
SOST is not backed by gold — the metals reserve is a Foundation-held reserve with published policy, not a peg and not a redemption right. The phrase "gold backed" was also removed from the page metadata, which is what a search result shows.
Operator instructions were rewritten too: no page on this site now teaches typing an RPC password into a command line, and every mining example selects the SbPoW signing key with --wallet + --mining-key-label.
All 63 served pages were fetched with caching disabled, compared byte for byte against the repository and scanned sentence by sentence. Current references: protocol spec · upgrade guide · metals reserve (historical).
// EXPLORER · jackpot archive · DTD panel corrections
Published: 2026-09-23 · Last updated: 2026-09-23
Every jackpot ever paid, in one place — JACKPOT ARCHIVE
9 jackpot draws have taken place since #25,290 (as of 2026-09-23: nine paid, 900 SOST distributed) — each one reconstructed from the canonical chain with its block, winner, amount, eligible set and transaction. The exact on-chain amount of every draw is in the archive itself, not fixed in this page.
The archive opens from five places — the JACKPOT ARCHIVE card, the JACKPOTS PAID card, the View all jackpots button, the winner overlay after a live or replayed jackpot, and the jackpot dashboard — all calling one component over one data source.
A cooldown card was removed from the jackpot panel. The recent-miner cooldown is a normal-DTD rule and the Accumulated Reward V2 draw has none — showing it among the jackpot metrics taught the opposite of the rule. It now lives in the eligibility section, labelled "Normal DTD only — not the Jackpot", with the same list of identities currently excluded.
Two eligibility numbers, never one. The 20,000-block count is the rule in force today and does not carry over. Beside it there is now a card headed "FROM #30,000 — DIFFERENT RULE": ≥3 blocks per 2,016 plus NODE_BIND, and the first draw's 0/0 heartbeats.
Cadence corrected. The panel still called the DTD cadence "permanent 1-of-3". Since V15 the DTD draws on every block (3-of-3) — which is why blocks whose height is not a multiple of 3 pay a DTD share.
The V16 preview inside the panel also quoted the old 5,000-block PoW window; the rule is 2,016.
The explorer header now renders at the same size as the main site.
The first DTD Jackpot paid 100 SOST at block 25,290
The network's first-ever DTD Jackpot was drawn at block 25,290 and paid 100 SOST to a single canonical DTD winner — verified on-chain.
What happened. At block 25,290 the consensus selected a DTD Jackpot winner and paid 100 SOST as a dedicated TX_TYPE_JACKPOT transaction (on top of that block's normal DTD payout of ~3.9255 SOST to the same address).
Producer ≠ winner: the block was mined by sost1ad01a…, but the jackpot went to a different address — the miner does not control who wins.
How the DTD Jackpot works
Every 288 blocks (~48h) a DTD Jackpot draws one canonical DTD winner.
At a jackpot height the eligibility uses an expanded 20,000-block activity window (vs 5,000 on normal blocks) plus the same canonical gates: recent-producer cooldown, anti-dominance and SbPoW.
Base reward 100 SOST. If a jackpot has no eligible winner it rolls over to the next one, up to a hard cap of 500 SOST.
The reserve (~68,174 SOST, frozen at the V15 emission transition) funds the jackpots and drains gradually over several years.
Next scheduled jackpot: block 25,578. You can check whether your address is currently eligible in the Explorer — open DTD JACKPOT → CHECK YOUR JACKPOT ELIGIBILITY and paste your sost1… address (status before the jackpot height is preliminary and can change).
Everything is fully traceable on the SOST Explorer — the block, the winner, the jackpot transaction and the eligible set are all on-chain.
// V15 CONSENSUS · full decentralization · activated block 25,000
Published: 2026-09-05 · Last updated: 2026-09-07
V15 is live — emission transition + DTD Jackpot at block 25,000
At block 25,000 the network activated V15: the emission transition to a fully community-distributed model, and the new DTD Jackpot.
What changed at block 25,000. V15 completes the move to a fully decentralized distribution:
Coinbase split is now 50% miner / 50% DTD (Deterministic Token Distribution). The previous 50 / 25 / 25 miner / Gold Vault / PoPC split is legacy.
New Gold Vault & PoPC emission → 0%. No new SOST is minted into those reserves; their existing balances are frozen and repurposed to fund the DTD Jackpot.
DTD Jackpot introduced — first paid at block 25,290 (see the entry above).
DTD recency gate: normal blocks use a 5,000-block activity window; jackpot heights use 20,000.
For miners & node operators. Run the final V15 release and mine with --realtime (mandatory) and a clock synced via NTP. A node on a pre-V15 or incompatible build can diverge from mainnet.
No second consensus activation is scheduled at block 30,000. V15 is the current mainnet consensus (consensus commit 82ba0521). Verify your node passes block 25,000 and follows the network tip on the Explorer.
// INCIDENT & POST-MORTEM · chain stall at block 20,526 · resolved · no funds affected · no consensus risk
Published: 2026-08-05 · Last updated: 2026-08-05
Chain stall at block 20,526 — resolved: the node was healthy; a node restart disconnected every miner at once
The chain paused for ~3h 37m at block 20,526. No funds were affected and consensus was never at risk. Root cause found and being hardened.
What happened. An automated VPS watchdog restarted the node at 03:10 UTC — a clean, and in this case unnecessary, restart. The node was healthy the whole time (its RPC answered in milliseconds and kept serving valid block templates). But when the node restarts, every miner loses its connection to it at the same instant. The active community miners did not reconnect on their own, and the node itself does not mine by design — so the chain was left with zero miners delivering blocks, and it paused.
Recovery. The moment a miner was reconnected, the chain resumed immediately — block 20,527 was mined and the chain is advancing normally past block 20,529. Any “block rejected” lines seen in the first minute were the normal, transient difficulty re-sync after a long pause (the anti-stall / Slingshot easing resetting), not a fault.
The key point: the node was never broken, no funds moved, and there was no chain-split or consensus risk. This was purely a miner-connectivity event caused by an avoidable node restart — not a bug in mining, emission, PoPC, Gold Vault or DTD.
What miners should do now
If you were mining and it stopped — simply restart your miner. The chain is active again; there is nothing to fix on your side.
Keep your miner persistent (a systemd service, a guard, or nohup) so it auto-reconnects within seconds of any brief node restart instead of staying idle.
Always mine with --realtime (mandatory) so block timestamps stay valid.
No recompile is required — this was not a consensus change. Your current binary is correct.
Root-cause fix (in progress)
Two hardening changes are being prepared so this class of stall cannot recur: (1) the node watchdog will only restart the node if it is genuinely hung — no more restarts on a false “stall” signal, which were the real trigger; and (2) the reference miners will ship packaged to reconnect automatically after any node restart. With both in place, an occasional node restart no longer empties the chain of miners.
🚨 MANDATORY: every miner and full node must recompile and restart in the window after block 16,900, before block 17,000. V14.7 re-activates Atomic Swap relay/mining as a coordinated flag-day. Below 17,000 the new binary is a no-op — mining and consensus are unaffected.
What happened: the first (ungated) deploy of the swap relay fix let expired HTLC LOCK transactions enter block templates, which the consensus rule R17 then rejected — degrading mining for everyone except the largest miner until a rollback. No funds were affected and the chain was never at risk.
V14.7 fixes it properly: the relay/policy exemption is now gated to block 17,000 (decoupled from the V14.5 consensus gate at 16,000), and a companion rule keeps any expired HTLC LOCK out of the block template. Below 17,000 the binary behaves exactly like the current one.
Activates block 17,000 — every upgraded node flips together
No-op below 17,000 — identical mining & consensus until the flag-day
A node that does not upgrade will not relay or mine swap transactions
Step 1 — build (flags mandatory)
cd sost-core
git checkout main && git pull origin main
cmake -S . -B build -DSOST_ENABLE_PHASE2_SBPOW=ON -DSOST_TESTNET_FORKS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target sost-node sost-cli sost-miner sost-signtx -j$(nproc)
⚠-DSOST_TESTNET_FORKS=OFF is required — building with =ON sets the activation height to 40 and throws you off mainnet. -DSOST_ENABLE_PHASE2_SBPOW=ON is required.
Step 2 — restart node, then miner, inside the 16,900→17,000 window (node first, then miner).
⚠ Do NOT use the Atomic Swap yet. It remains founder-only testing — not externally audited, not validated for public use. Wait for the official “safe to use” announcement (SOST website, BitcoinTalk, t.me/SOSTProtocolOfficial).
// MANDATORY UPGRADE · V14.5 · activates block 16,000 · consensus risk: chain-split if not upgraded
Published: 2026-06-29 · Last updated: 2026-06-29
V14.5 — all miners & nodes must upgrade before block 16,000
🚨 MANDATORY: every miner and full node must recompile and restart before block 16,000. V14.5 fixes the Atomic Swap HTLC so a locked swap can actually settle. Old binaries are rejected and split off from block 16,000.
What happened: V14 (block 15,000) switched on the Atomic Swap HTLC rules, but two leftover validation guards rejected the CLAIM and REFUND transactions — so a locked swap could never settle. No funds were affected: the swap was never used publicly and there were zero open locks.
V14.5 fixes it: from block 16,000, HTLC LOCK / CLAIM / REFUND all validate correctly.
Below block 16,000 the new binary is byte-identical to the current one, so it is safe to deploy now. The same build also carries V15 (PoPC) at block 25,000 — one upgrade covers both forks.
Step 1 — build (flags mandatory)
cd sost-core
git checkout main && git pull origin main
cmake -S . -B build -DSOST_ENABLE_PHASE2_SBPOW=ON -DSOST_TESTNET_FORKS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target sost-node sost-cli sost-miner sost-signtx -j$(nproc)
⚠ -DSOST_TESTNET_FORKS=OFF is required (building with =ON throws you off mainnet). -DSOST_ENABLE_PHASE2_SBPOW=ON is required.
Step 2 — restart your node
sudo systemctl restart sost-node # systemd
# or: stop the old sost-node, then start ./build/sost-node <your usual args>
Step 3 — restart your miner
# stop the old sost-miner, then relaunch:
./build/sost-miner <your usual args>
⚠ Do NOT use the Atomic Swap yet. It remains founder-only testing — not externally audited, not validated for public use. Wait for the official "safe to use" announcement (SOST website, BitcoinTalk, Telegram). SOST ↔ BTC is not active (V15).
A clear, realistic update on two topics: network infrastructure after the recent V14 reports, and the future liquidity / listing strategy for SOST.
1 · Regional seed nodes
Reports from miners outside Europe — especially Asia-Pacific — showed a real network-health issue: relying mainly on a Germany-based seed is not enough for a global Proof-of-Work network. High latency can increase orphan risk, local forks with less cumulative work, sync instability, and propagation disadvantage for distant miners.
To improve this, SOST is moving to a multi-seed model:
seed-eu.sostcore.com — Europe / current Germany infrastructure
seed-apac.sostcore.com — Asia-Pacific region
seed-us.sostcore.com — North America
seed.sostcore.com — kept as a backward-compatible alias
A P2P-only multi-seed update has already been prepared. It does not touch consensus, mining rules, PoPC, Gold Vault, Atomic Swap logic, or emission — it only improves peer discovery and regional resilience. As soon as possible, two additional VPS seed nodes (APAC + US) will be activated to improve propagation and make mining fairer for distant regions.
Community bootnodes are welcome. A miner who can run a stable public node with port 19333 open, RPC closed or localhost-only, and no wallet / private keys, helps decentralization and propagation.
2 · Realistic listing strategy
SOST will not chase low-quality listings just to appear on a centralized exchange. With respect to smaller exchanges, listing on a Tier 4, Tier 3 or weak Tier 2 venue can create more risk than value: low liquidity, poor market quality, high delisting risk, unclear compliance, and reputational damage if the venue later becomes problematic.
The current strategy is to finish and founder-test Atomic Swap / OTC functionality; allow controlled non-custodial SOST liquidity through Atomic Swap once safe; keep public warnings active until founder testing is complete; record any treasury-related SOST sale transparently in the Protocol Registry; and allocate proceeds with a verifiable split between long-term reserve building and future Tier 1 / Tier 2 listing readiness.
Important: Atomic Swap is not a centralized exchange. It is non-custodial software. SOST does not custody user funds, does not broker trades, and does not guarantee counterparties, prices, liquidity, or outcomes.
3 · Use of proceeds
If SOST is sold through founder-controlled, non-custodial channels after Atomic Swap has been tested, the intention is that all proceeds are tracked transparently:
a portion to the perpetual Gold / Metals Reserve, to strengthen long-term intrinsic treasury backing;
a portion reserved exclusively for compliance, audit, legal work, market infrastructure, and potential future Tier 1 / Tier 2 listing preparation.
Any such movement should be recorded verifiably through the Protocol Registry or equivalent public reporting. The Gold / Metals Reserve is a treasury reserve — not a redemption guarantee, not a price floor, and not a promise of profit.
4 · Why compliance matters
A serious listing is not just a payment — it requires regulatory and operational readiness. At minimum, SOST must work toward:
Legal classification: independent analysis on whether SOST is a crypto-asset, financial instrument / security, utility asset, or another category in relevant jurisdictions;
MiCA readiness in the EU: where applicable, crypto-asset white paper / disclosures, admission-to-trading requirements, issuer disclosures, sustainability disclosures, and cooperation with regulated CASPs;
AML / KYC and Travel Rule compatibility: AML controls, sanctions screening, and transfer-of-funds requirements;
Technical audit: review of consensus, wallet, Atomic Swap, bridge / escrow contracts where applicable, and operational security;
KYB / foundation structure: legal entity, responsible contacts, documentation, and governance suitable for exchange due diligence;
Liquidity plan: market-making, treasury controls, and a listing budget that does not compromise SOST.
This is why SOST will not rush into a weak listing. A Tier 1 or strong Tier 2 exchange requires real preparation — legal work, audits, infrastructure, market quality and compliance — and SOST will build what is necessary for that path instead of taking the fastest low-quality option.
5 · Summary
Short term: activate regional seeds (EU / APAC / US); continue V14.5 upgrade communication; finish founder-only Atomic Swap testing; keep public Atomic Swap usage disabled until explicitly announced safe.
Medium term: use Atomic Swap / OTC as the first controlled liquidity path; record treasury-related movements transparently; build compliance, audit, legal and listing readiness; target only serious Tier 1 / Tier 2 opportunities if they fit SOST.
SOST is still experimental. There are no guarantees of success, value, exchange listing, liquidity, or adoption. The objective is to build carefully, transparently, and with long-term credibility rather than chasing short-term optics. Thank you to the miners and community members reporting real operational issues — those reports directly improve the network.
// PUBLIC LAUNCH · 2026-06-16 00:00 UTC · ~92 days after genesis
Published: 2026-06-16 · Last updated: 2026-06-16
Official Public Launch
After ~92 days of protocol hardening performed directly on mainnet (genesis 2026-03-15 18:00 UTC), SOST exits its pre-market test phase.
The chain has run continuously since genesis — through the V13 hard fork (block 12,000) and the V14 H3/H4 validation hardening — with independent miners and nodes active (peak 53 miners). No premine, no ICO, no VC allocation; the 50 / 25 / 25 coinbase split (miner / Gold Vault / PoPC) is hardcoded at genesis.
At 00:00 UTC the pre-market banner and launch countdown retire automatically; only the Genesis counter remains. Full automation (PoPC Bond Staking, OTC/P2P atomic swap, Gold-Vault governance) is grouped into V15 at block 25,000, after testnet, replay and coordinated activation.
// STANDARDS · SLIP-0044 · merged by SatoshiLabs
Published: 2026-06-15 · Last updated: 2026-06-15
Registered in SLIP-0044
SOST now has an official coin type in the BIP-44 / SLIP-0044 registry, merged by SatoshiLabs (creators of Trezor).
Merged in satoshilabs/slips#2004. SOST is a native L1 PoW coin — not an ERC-20 — so there is no contract address; any "SOST contract address" is fake.
Transparency: the reference wallet currently uses BIP-39 seed phrases with direct key derivation (fully secure). Full BIP-44 hierarchical derivation (the reserved path above) will be added in a future wallet version if the community requests it, with migration tooling and advance notice. This is a wallet/UX enhancement, not a consensus change — existing addresses and keys remain valid.
The public node's RPC became unresponsive (504 Gateway Time-out, "waiting for node"). The chain never halted — no fork, no lost funds, no consensus-rule change.
Root cause: a pre-existing P2P concurrency bug. p2p_send_block held the node's global chain mutex (g_chain_mu) across a blocking TCP send; a peer in initial block download with a full receive window froze the send while holding the lock, starving every RPC reader (getblockcount, getinfo, getblocktemplate) that serializes on the same mutex — producing the 504s and connection pile-up.
Fix: serialize the block into a buffer under the lock, then release the lock before the network send (226d8e09) — wire output byte-identical. Plus window the cASERT difficulty metadata build to the last 512 blocks instead of recomputing over the full ~13k-block chain on every call (5e3a3cfa) — bit-for-bit identical output. RPC latency dropped from 8–20 s timeouts to <10 ms.
Recommended (not mandatory) stability update for self-hosted nodes/miners; the public RPC bridge is already patched. Old binaries remain in consensus.
// CODING MILESTONE · OTC-1 → OTC-5 · gate OFF on mainnet
Published: 2026-06-10 · Last updated: 2026-06-10
SOST OTC / P2P Atomic Swap
A trustless, non-custodial cross-chain swap engine — SOST ↔ BTC · ETH · BNB · USDT · USDC · PAXG · XAUT. The mechanism is a Hashed Time-Locked Contract (HTLC) on both chains — the same primitive that powers Lightning.
Swap SOST for another cryptoasset with a stranger, without trusting them and without SOST ever holding either side's funds. Either both legs settle, or both legs refund — there is no in-between. No intermediary, no escrow operator, no admin key, no upgrade path, no pause switch, no emergency drain.
⚙ Decentralised No custody, no broker, no matching engine. The swap is bilateral & cryptographic.
✓ Atomic Both legs complete or both refund. No partial settlement is reachable.
🔒 Non-custodial The HTLC is the escrow. No owner can ever move the funds.
🔍 Verifiable Every step is a public on-chain tx. Anyone can replay & verify it.
Pairs flagged ⚠ are issuer tokens — Tether / Circle / Paxos / TG Commodities can freeze any address. Atomic-swap atomicity holds on the SOST side regardless; the issuer-freeze warning is for the counterparty leg only and is fully disclosed pre-swap in the wallet UI. BTC / ETH / BNB carry no issuer-freeze authority.
How it works — plain language
Alice has SOST, wants BTC. Bob has BTC, wants SOST. They agree price on the OTC/P2P board; everything after is purely cryptographic, with no intermediary touching either coin:
Alice locks her SOST in a SOST-side HTLC, redeemable by Bob with a secret only Alice knows. Refundable to Alice after timeout T1.
Bob locks his BTC in a Bitcoin-side HTLC, redeemable by Alice with the same secret. Refundable to Bob after timeout T2 (T2 < T1 by a wallet-enforced safety margin).
Alice claims the BTC by revealing the secret on the Bitcoin chain.
Bob reads the secret from the Bitcoin chain and uses it to claim the SOST.
Either both legs succeed, or both refund when the timeouts fire. No half-states. No counterparty risk. No third party can move the funds.
Two technical paths
₿ BTC path — native Bitcoin HTLC, BIP-199-style P2WSH redeem script (SegWit v0). Signing delegated to the audited libwally-core (Blockstream — used in Liquid & Green). BIP-143 sighash, BIP-173 Bech32, low-S signatures all from upstream-audited code. No Bitcoin script written from scratch.
⬢ EVM path (ETH / BNB / ERC-20) — a single 273-line AtomicSwapHTLC.sol. No owner, no upgrade, no pause, no drain. 52 Foundry tests: balance conservation, reentrancy (receiver + token), weird-ERC-20, EIP-6780 forced-ETH, claim/refund ordering, fuzz preimage, fuzz timeout boundary.
Live gate state — verifiable in the repo · mainnet UNCHANGED
ATOMIC_SWAP_HTLC_ACTIVATION_HEIGHT = INT64_MAX # SOST consensus gate, sentinel OFF
SOST_BTC_HTLC_SIGNING = OFF # CMake flag, no real BTC signing compiled in
V15_HEIGHT = 25,000 # intended activation height (NOT yet active)
All atomic-swap wallet / RPC / CLI commands refuse --sign --broadcast while the gate stays at INT64_MAX. Activation only after Phase-4/5 sign-off + external audit.
One-line summary. Two people, two chains, one shared secret, two timeouts — or both walk away with their own coins. Full reference at sost-otc.html.
// PLANNED · BLOCK 25,000 · full automation release
Published: 2026-06-08 · Last updated: 2026-06-08
V15 — full automation: PoPC Bond Staking, Atomic Swap & Gold Vault governance
Scope split (2026-06-08): V14 ships on time at block 15,000 (validation hardening, no action needed). The larger automation track is regrouped here, into V15, so it ships fully integrated — never half-activated.
Rather than rush the heaviest systems into V14, they are grouped into a dedicated release that activates together at block #25,000. Each gate ships deferred (no-op) on mainnet and is flipped only after full integration, testnet, replay and coordinated activation — never flipped blind on a live chain.
Targeted for block 25,000
PoPC (Proof-of-Personal-Custody) Model A & Model B — full automation — consensus-side auto-audit, auto-slash and auto-settlement; the active set moves out of popc_registry.json into deterministic chain-state. Model B event-listener automation included.
OTC / P2P Atomic Swap (HTLC) — non-custodial swaps with no bridges. PAXG / XAUT / USDT / USDC live on Ethereum, so the user keeps their own ETH account and performs a few small steps — with the rest of the flow prepared and near-fully automated. Activates only after BTC + EVM end-to-end testnet and review.
Gold Vault governance upgrade (G1–G5) — consensus-enforced spend rules: 90 % miner approval over a 67-block window (ceil = 61) + 10 % quality boost or single-signer veto (developer / genesis); silence = accept; whitelisted destination; per-spend cap. Stronger security, decentralization and protection of SOST's reserve-value mechanism.
Testnet, replay and coordinated activation before any mainnet flip.
For node / miner operators: nothing to do for V15 yet — keep running your current V14 binary. A node update enabling the V15 features will be published well before block #25,000, with clear instructions. This is not an emergency; the chain continues normally. Goal: automation first, no half-activated protocol systems. Cross-posted on the BitcoinTalk thread and surfaced on the live explorer.
V14 — update your node and miner before block 15,000
A new binary is ready for the V14 consensus hardening. It is height-gated, so updating today is safe — and necessary to stay on the network after activation.
The V14 hard fork activates at block #15,000 (chain currently around #12,060). It tightens block validation (the H3/H4 hardening): mempool/relay policy no longer decides block validity, a transaction may spend an output created by an earlier transaction in the same block (validated against a temporary UTXO view), and duplicate transaction IDs inside a block are rejected. Before #15,000 the previous rules are preserved unchanged, so a node built today behaves exactly as before until activation.
What every node and miner operator must do: rebuild from main and restart bothsost-node and sost-miner — well before block #15,000. Don't wait for the fork: compile and restart now.
cd /opt/sost
git fetch origin && git checkout main && git pull origin main
cd build && cmake .. && make -j"$(nproc)"
sudo systemctl restart sost-node
sudo systemctl restart sost-miner
Why it matters: after block #15,000, nodes still on the old binary may reject V14-valid blocks — risking a chain split or mining on an orphaned fork. Because the new rules do nothing before #15,000, updating now carries no risk and keeps you on the canonical chain. Cross-posted on the BitcoinTalk thread and surfaced on the live explorer.
// PLANNED · BLOCK 15,000 · target ~2026-06-27
Published: 2026-05-28 · Last updated: 2026-06-08
V14 — block-validation hardening (H3/H4)
Scope narrowed (2026-06-08): V14 now ships only the H3/H4 hardening. The governance & automation track moved to V15 (block 25,000) — see the V15 entry above. Retractable without drama if the pre-fork testnet checks fail.
Activates at block 15,000
H3/H4 block-validation hardening — mempool/relay policy no longer decides block validity; a transaction may spend an output created by an earlier transaction in the same block (validated against a temporary UTXO view); duplicate transaction IDs inside a block are rejected. (The dynamic fee floor 1→10 already activated at block 10,000.)
Threshold constant sync 95 % → 90 % is already in the binary; its spend-side enforcement arrives with the Gold Vault governance in V15.
Moved to V15 (block 25,000)
Gold Vault Phase I governance (90 % miner approval over a 67-block window, veto, caps).
PoPC Bond Staking chain-state migration + auto-audit / auto-slash / auto-settlement (single native-SOST bond; optional Gold Boost, never collateral) and the DTD-PoPC eligibility gate flip.
OTC / P2P Atomic Swap HTLC full automation.
These were regrouped so V14 ships on time and untouched, and the automation ships fully integrated and coordinated. See the V15 entry above.
// RELEASE CANDIDATE (RC1) · BLOCK 12,000
Published: 2026-05-20 · Last updated: 2026-06-05
V13 — cASERT H35, drift tightening & Beacon
At block 12,000
Full cASERT equalizer range E7–H35 active (ceiling H20 → H35).
DTD reward recent-winner cooldown 5 → 6 blocks.
Future-timestamp drift cap 60 s → 30 s — a clock more than 30 s ahead produces blocks validators reject. NTP strongly recommended.
Beacon Phase II-A (operator-signed advisory notices) + II-B (3-of-5 threshold, default-off until 5 custodians) + III (P2P gossip). Advisory-only — never affects mining rewards or block validity. → Beacon guide
SbPoW hardening — the signed PoW preimage grows from 7 to 11 fields (adds timestamp, bits_q, merkle_root, a chain-specific genesis_hash salt); domain tag → SOST/POW-SIG/v13.
Anti-dominance gate — any miner address holding ≥ 10 % of the previous 288 blocks is excluded from DTD reward eligibility until its rolling share drops below 10 %. Only miners with at least one SbPoW-signed block (most recent block at height ≥ 7,100) are eligible. Dominant miners keep their full 50 % miner reward; reversible per-block, no slash, no admin authority.
V13 RC1 published with signed SHA256SUMS (release key fingerprint 41B1A46E…2AE41A04); binary upload remains a manual operator step.
// RECENT MILESTONES · May–Jun 2026
Published: 2026-06-01 · Last updated: 2026-06-05
Recent milestones
Beacon II-A operator key anchored on-chain — canonical fingerprint bbb560e3…def8186b committed at block #11,034 (txid c6ade3c6…810a1), the first OFFICIAL entry in the Protocol Registry. → Registry
Beacon II-A real operator key installed in the node (offline-generated secp256k1; private key never on a networked host).
V11 Phase 2 — block 7,100 (LIVE):Signed PoW (SbPoW) — every mined block carries a Schnorr signature over the PoW preimage — plus the fair-share DTD reward with jackpot rollover (redistributes SOST-side share on triggered blocks).
V11 Phase 1 — block 7,000: extended linear difficulty cascade + state-dependent dataset access. (Useful-Compute infrastructure is dry-run / testing only — rewards remain POSTPONED.)
// PUBLIC POST-MORTEMS · TRACEABILITY
Published: 2026-05-01 · Last updated: 2026-06-05
Incident reports & post-mortems
Real failures during live pre-market testing, documented in full. Holder funds were never lost; pre-incident chain history was never altered.
V11 Phase 2 activation — chain paused at 7,099, then resumed (2026-05-04)
Phase 2 (SbPoW + DTD reward) activated at block 7,100. The chain paused at height 7,099 for ~90 minutes: miners were producing v2 headers that validators correctly rejected with v2 header missing miner_pubkey. This was a miner-side serialization bug, not a consensus failure — the validator was doing exactly its job.
Resolved by a correctly rebuilt miner from main; first valid Phase 2 block #7,100, verified through #7,104.
DTD reward live immediately: first payouts at #7100 / #7102 / #7103 of 3.92550431 SOST each (11.77651293 SOST total), 36 eligible addresses, pending jackpot 0.
Cooldown clarified: the recent-miner cooldown excludes addresses that mined recently, not addresses that won the lottery. Winning the lottery never triggers cooldown.
Lesson, on the record: the v1→v2 header path was not exercised end-to-end against a running validator under production load. Every future hard fork now requires an end-to-end production rehearsal before a finite mainnet activation height is set.
Trace → V13: immediately after activation a single upgraded miner produced every post-7,100 block. That observed centralisation is exactly what the V13 anti-dominance gate (block 12,100) is designed to counter.
Public stress-test: the bootstrap & P2P sync saga (2026-04-06 → 04-10)
New nodes could not sync from genesis. Over four days, external testers reproduced and the operator fixed a chain of transport-layer bugs — none of them consensus bugs. Each is credited to the reporter who found it:
Transcript V2 historical proofs — historical blocks were served without the ConvergenceX proof data, so a fresh node failed verification at block #1. Fixed with an assumevalid checkpoint (block 3,000, then dynamically advanced). (found by visibleplayer)
P2P rate-limiter — sync-mode peers at height 0 were mistaken for relay traffic and banned mid-sync. Fixed with a sync-mode exemption. (found by 3Q)
The “2501 stall” — the seed sent plaintext-framed blocks into encrypted connections; combined with TCP flow-control deadlocks, blocking I/O and missing EAGAIN handling, every block after the first trusted batch was silently dropped. Surfaced by a 4-server clean-room reproduction. (found by Rizki Maryanto)
Encrypted/plaintext interop — an encrypted client discarded the peer's VERSION while waiting for EKEY, so handshakes never completed. Fixed.
H10 stability cliff — the profile scale jumped 2→3 at H10, making H10+ unreachable on modest hardware. (from vostokzyf / oswaldzc reports)
Fresh-clone build break — a stale test_checkpoints.cpp referenced removed constants. (found by colerus)
Competitive-mining loop — after losing a block to another miner, the miner retried the same height forever (invisible while solo-mining). Fixed with auto-advance to the current tip.
Resolved 2026-04-10: direct P2P sync, HTTPS bootstrap import and end-to-end encrypted P2P all validated from zero to tip. Explicitly: no consensus rule, block-validation rule or emission rule was changed; no hard fork; no regenesis. Transport / networking only.
Bootstrap snapshot served HTML instead of chain data (2026-05-25)
bootstrap-chain.json was accidentally serving the website's HTML page (~110 KB, starting <!DOCTYPE html>) instead of the real ~124 MB snapshot, so a node bootstrapping from it started from an empty chain ([FORK] Block h=4 … does not extend tip (our height=0)).
Restored the real snapshot (129,031,101 bytes, chain_height=10231) and verified it is JSON, not HTML.
Added an hourly refresh cron with JSON validation before publish, writing via tmp + atomic mv so a half-written file is never served. (found by vostokzyf)
Security culture, on the record: across every one of these reports the operator diagnosed from logs only and repeatedly told testers to never send private keys, seed phrases, passwords or wallet files. No SOST support flow ever asks for them.
// V2–V10 · cASERT DIFFICULTY SERIES
Published: 2026-04-10 · Last updated: 2026-05-01
The difficulty & liveness hard-fork series
A sequence of forks that unified and hardened the cASERT bitsQ controller and stabilised block time around the 600 s target.
Fork
Block
Change
V10
6,700
Granular relief calibration (1 s/60 s steps from 600 s)
Final calibration
5,750
H13 ceiling, E7 relief@605 s (HISTORICAL, until 6,549), full 43-profile range (E7–H35 defined)
H12 + relief
5,635
17 active profiles; relief valve H1@630 s
Profile floor
5,560
Miners cannot declare a profile below the deterministic floor
Consecutive forks (V3 → V6) hardened the dual-vector difficulty controller live on mainnet. Every root cause is documented — the controller only stabilised because real miners surfaced behaviours no single-node simulation reproduced.
cASERT runs two difficulty vectors at once: the numeric target (bitsQ) and a 43-profile structural “equalizer” (E7…H35). V3.1 added a ±3-per-block slew limit so the profile could never jump far in one block. In practice the limit silently disabled itself: BlockMeta::profile_index defaulted to 0, so a block legitimately mined at B0 (index 0) was indistinguishable from one whose profile was never stored. Every B0 block was read as “missing”, the slew fell through to a fallback, and the next block could jump straight to H12. The result was a ~2-hour loop — B0 → H12 → long stall → anti-stall → B0 — that produced one or two blocks per cycle and looked like a stuck chain.
Fixed with an explicit INT32_MIN sentinel + per-block persistence of profile_index through load, P2P relay and reorg.
Only visible with multiple live miners — single-node simulations never hit a B0 block at the wrong moment.
The H10 stability cliff — nobody could mine, at any hashrate (V6, block 5,000)
Miners reported 0.0% stability at H10 even with 64 threads and ~370 att/s. Cause: the stability-basin parameter scale jumped from 2 (H9) to 3 (H10) — a cliff, not a gradient; at scale 3 essentially no nonce passes the basin check. It affected every miner equally, regardless of hardware, and drove the sawtooth (push to H10 → nobody mines → stall → anti-stall drop → fast blocks → repeat). (diagnosed from vostokzyf and oswaldzc reports)
Scale 3 permanently retired; the hard profiles unified at scale 2 with a uniform 5-point margin gradient (current table: scale 1 for E7–H4, scale 2 for H5–H35). Confirmed mineable within hours (blocks 4,976–4,984).
Latency vs the E7 relief valve — an honest fairness tension
When the chain ran persistently ahead, the equalizer held a near-unsolvable profile (H11) until the 605 s relief valve dropped it straight to E7 (trivial). Whoever received that broadcast first — typically the lowest-latency peers — took the block almost instantly. A high-hashrate miner in Asia connecting to European peers reported 24 h with zero blocks. This was openly acknowledged as a real effect, not dismissed: miner profile-polling was cut 6 s → 1 s and a local relief-valve prediction added so all miners enter E7 at the same instant, shifting the contest back toward hashrate. (raised by vostokzyf; the broader “stop at the first productive profile” idea from oswaldzc remains under study)
bitsQ convergence — from anchor-exponential to avg288 + dynamic cap
The numeric controller was rebuilt mid-week: the genesis-anchored exponential (which accumulated lag and spiked ~27%) was replaced by an avg288 controller comparing the last 288 intervals to 600 s. A fixed 12.5%-per-block cap proved too violent for a 288-window signal; a brief median override then over-corrected (saturating at 3%/block). The endpoint: median removed from consensus, a ±15 s dead band, and a dynamic cap scaling 0% / 0.5% / 1% / 2% / 3% by deviation. The PID equalizer was later simplified to direct lag-mapping (profile = clamp(lag, 0, ceiling)) with asymmetric descent: rise immediately, fall ≤1 level per block.
The 43-profile architecture (E7–H35) reached its final form at block 5,750 (H13 ceiling, E7 relief @605 s). Higher profiles (H14–H35) were then reserved; they were activated at V12 (H14–H20, block 7,350) and V13 (H21–H35, block 12,000), where the H35 ceiling is current. The 605 s relief valve is HISTORICAL (blocks 5,750–6,549), superseded by the V12 triangular cascade.
// ANNOUNCEMENTS & FIXES
Published: 2026-04-05 · Last updated: 2026-06-05
Genesis, launch & operational fixes
Genesis block — 2026-03-15 18:00:00 UTC.
Public ANN + accelerated launch — 2026-04-05 (the originally planned launch was brought forward; public launch 2026-06-16).
Mainnet live — explorer operational at sostcore.com.
SLIP-0044 / BIP-44 registration — PR submitted to satoshilabs/slips (2026-04-15).
// ON THE RECORD · TRACEABILITY
Published: 2026-04-05 · Last updated: 2026-06-05
Honesty & traceability record
Community testers — credited, and paid on-chain
The pre-market sync, P2P and difficulty bugs were found by independent testers on BitcoinTalk. Each fix is credited to its reporter — visibleplayer (Transcript V2 sync), 3Q (P2P rate-limiter), oswaldzc (build + H10 cliff), Rizki Maryanto (4-server 2501 stall), vostokzyf (bootstrap snapshot, H10 / latency), colerus (fresh-clone build break). The operator sent real SOST to reporters both to acknowledge the work and to exercise live on-chain transfers — among the first non-coinbase transfers on the SOST mainnet, all visible on the explorer.
Self-disclosed audit findings (not found by an outsider)
Reading the source line by line, the operator disclosed two gaps before they could bite: the Gold Vault governance rules (GV1–GV4) were unit-tested (17/17) but the validator wiring to the live transaction pipeline was never completed — at the original height it would have triggered nothing; and the getproposals signaling RPC returned placeholder data instead of reading real block versions. Both were disclosed openly and scheduled to ship wired-in, rather than patched in panic. The 25% + 25% accumulation to Gold Vault / PoPC Pool has been consensus-enforced since genesis throughout; only the spending governance was deferred.
>
Sovereign value stack — alpha proven on Sepolia (verifiable)
The gold-escrow + signed-settlement stack moved from design to a deployed alpha: SOSTEscrow (no admin key, no upgrade proxy, no pause, no emergency withdrawal) plus mock XAUT/PAXG on Ethereum Sepolia, a first on-chain gold deposit, and an end-to-end signed deal → settlement flow, all publicly verifiable on Sepolia Etherscan. Automated test coverage grew from 259 to 743 passing tests across C++, Python, TypeScript and Solidity. This is operator-assisted testnet alpha with mock tokens — not yet a public trustless market.
// EVERY PAUSE ON THE RECORD · TRACEABILITY
Published: 2026-04-05 · Last updated: 2026-06-05
Operational stalls & live incidents
Each chain pause is timestamped and explained. None was a consensus failure or a loss of funds; the chain refused bad blocks rather than accept what it could not verify.
The SbPoW build-flag stall — 2 h 36 min at block 10,109 (2026-05-24)
The seed node was recompiled from mainwithout the -DSOST_ENABLE_PHASE2_SBPOW=ON CMake flag (whose default was OFF). The resulting binary loaded the chain, spoke P2P and passed every other rule — but could not verify the V11 Phase 2 BIP-340 Schnorr signatures that the network had used for ~3,000 blocks, so it rejected every candidate (SbPoW: signature verification failed at height 10110). It was a verifier compiled with the wrong code path, not a fork.
Last good #10,109 at 20:42:55 UTC, resumed #10,110 at 23:19:45 UTC (9,410 s). No reorg, UTXO set preserved (28,005 entries), funds safe, 10 distinct miners during recovery.
Defense-in-depth: CMake default flipped OFF → ON; a start-up FATAL guard now refuses to run a mainnet binary without SbPoW compiled in; checklist + a strings sost-node | grep -c 'POW-SIG/v11' verification step added.
Accountability, verbatim: “operator error compounded by a documentation gap” — the fix lives at build time so a misconfigured “mainnet” binary now fails loudly instead of silently.
Seed thread-exhaustion stall — ~139 min at block 6,017
RPC connection-handler threads were not recycled when HTTP clients (browsers, explorers, miner getinfo polls) dropped mid-response. The node accumulated ~1,600 idle threads and RPC responsiveness degraded until miners could not reliably reach it. Not an attack, not a consensus issue — a connection-handling bug, the kind Bitcoin also hit in its early years.
Fixes: write timeout 30 s → 5 s (threads recycle 6× faster); two getinfo round-trips collapsed into one; an automatic watchdog that restarts the node if its thread count exceeds 500.
Long-tail block during the V11 update window — 129 min at block 6,989
While the V11 Phase 1+2 code was pushed, many operators rebuilt and restarted at once (each first start rebuilds the 60-second ConvergenceX dataset), so effective network hashrate dropped. Combined with normal Poisson variance at the cASERT relief floor, block 6,989 stretched to 129 min 35 s. A documented rollback to a backup binary was prepared with a 150-minute threshold — the block landed first, so the rollback was cancelled, not executed. Verified: no chain split, no premature Phase 2 activation.
Miner race condition — and a bug bounty paid on-chain
On a 192-core host running 64 threads, the miner segfaulted repeatedly. Root cause: a TOCTOU race in the block-monitor start path spawned two monitor threads; a detached monitor then read the chain vector while the main loop reallocated it on a new block — undefined behaviour surfacing as a libc segfault. Fixed in miner v0.8 (atomic compare_exchange_strong so only one monitor launches; the thread is joined, not detached, before the chain mutates; a lifecycle mutex).
Bug bounty paid on-chain to the reporter — txid bf8c1709…a364019, on-chain note “Bug bounty — sost-miner v0.8 race condition fix 6680319”. Publicly verifiable on the explorer.
// HARD TRUTHS, STATED · TRACEABILITY
Published: 2026-04-05 · Last updated: 2026-06-05
Mining fairness & honest reporting
“CPU-only” → “CPU-friendly, memory-hard” — a corrected claim
An end-to-end consensus audit confirmed ConvergenceX is intact, but also that SOST does not enforce CPU-only mining — the algorithm structure (parallel k-loop, 32×32 matvec, branch-free perturbations) is amenable to optimised/GPU implementations, which is legitimate competition under the current rules. Rather than keep an overstated claim, the framing was corrected to “CPU-friendly, memory-hard PoW” across the site and header, and real GPU-resistance was deferred to a properly designed future fork. A separate display bug was fixed: the explorer's EST. HASHRATE was dimensionally wrong (bitsQ/blocktime); it now shows a ConvergenceX attempt-rate estimate and the effective ConvergenceX attempts/sec side by side. Attempts per second alone do not describe SOST's computational cost: read it together with bitsQ, the active Equalizer profile and the number/distribution of miners. It is not comparable to Bitcoin SHA-256 hashrate.
Concentration, reported — not hidden
When one address grew dominant, the distribution was published openly: over 288 blocks (25 unique miners), top-1 ≈ 41.8 %, top-3 ≈ 61 %, top-10 ≈ 80 %, with the structural risks named (no unilateral reorg below 51 %, selfish-mining profitability from ~33 %, a top-3 coalition crossing 51 %). The active-miner peak (~39) fell to ~7 after the SbPoW + V12 upgrades — an honestly-stated cost of closing the consensus pieces before the commercial side. No official pool is offered (SbPoW makes classic pools unfeasible, and a central pool would be a 51 % target); the DTD reward and PoPC are the cooperative answer so a small miner earns recurring upside after a single block, and a holder can earn via custody without out-hashing anyone.
A 30-day fork moratorium & auto-warnings
After the rapid V3–V12 calibration series, the operator committed (post-V12, block 7,350) to zero consensus changes for at least 30 days unless chain integrity is threatened, and that every future hard fork is announced ≥ 30 days in advance from the public thread, with banners in the node and explorer plus a min_commit field so a miner on an outdated binary is warned automatically — no more black-box updates.
Listing applications & registrations — submitted, not confirmed
For traceability, the public market-data review requests are on the record and pending: CoinMarketCap (ticket #1366213), CoinGecko (#129449), CoinPaprika (#2415351), CoinCodex. The SLIP-0044 BIP-44 coin-type registration was filed as a PR to satoshilabs/slips. None of these is a listing, a market or a price — SOST has no contract address (it is a native L1) and any “SOST contract” is fake.
DTD reward audit & V11 staged rollout
After a display concern, the DTD reward was cross-checked three ways — consensus re-derivation from the deterministic seed, the node UTXO set, and the explorer address balance — and all three matched; only the wording was off (lottery UTXOs are now labelled LOTTERY not generic OUTPUT, and lifetime wins are separated from current unspent balance). For the record, V11 shipped in two stages: Phase 1 (block 7,000) — extended cASERT cascade + state-dependent dataset access (the index derives from the previous round's SHA-256 state, closing predictable-prefetch optimisations); Phase 2 (block 7,100) — SbPoW + DTD reward + jackpot rollover, with a triangular emergency-relief cascade.
// ECOSYSTEM & TOOLS
Published: 2026-05-01 · Last updated: 2026-06-05
Wallet, DEX, escrow & research stack
SOST DEX Alpha — browser wallet with native encryption (ED25519, X25519, ChaCha20-Poly1305) and encrypted deal flow.
SOST OTC / P2P disclaimer.
SOST Community OTC / P2P Board is a user-to-user discussion area for voluntary SOST offers. SOST
does not intermediate trades, custody funds, provide escrow, guarantee counterparties, or guarantee
liquidity. Admins never DM first. Use small test transactions and verify all addresses independently.
No direct founder sale is currently active. SOST is not a broker, exchange, trading desk, escrow service, market maker, or official
liquidity program.
SOST
Bitcoin
Litecoin
Dogecoin
Bitcoin Cash
Monero
Ethereum Classic
Zcash
Dash
Kaspa
Ravencoin
Ethereum (L1)
TRON
Solana