News & Updates

• 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/production-node change. Open the offering models

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.

Open the Asset Registry · Tokenization Studio → Passport · View documentation

• 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. Lab code on a development branch, not yet merged; Bitcoin signing stays OFF on mainnet.
• 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 (RETIRED) · V16 schedule

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:

V30000 FINAL SECURITY BUILD — release and SHA256SUMS (the original v30000 release is superseded) · step-by-step operator guide. Build directory must be named build if you compile.

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.

Step-by-step commands for systemd, a manual terminal and WSL: operator upgrade guide.

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:

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.

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).

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.

Open it: SOST Explorer → DTD JACKPOT card.

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).

• Winner: sost141bfebb4b830c2f4136fd324318a5e708c2215a4
• Amount: +100 SOST · TX: 5286762e… · Eligible set: 192 addresses (20,000-block window)
• 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.

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.

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.

Full traceability, as always: the stall, the block heights and the recovery are visible on the live explorer and cross-checkable on BitcoinTalk and t.me/SOSTProtocolOfficial.

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).

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).

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;
• Market integrity: anti-manipulation standards, transparent tokenomics, treasury reporting, clear risk disclosures;
• 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.

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.

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.

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.

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.

Seven supported asset pairs

SOST↔BTC · SOST↔ETH · SOST↔BNB · SOST↔USDT ⚠ · SOST↔USDC ⚠ · SOST↔PAXG ⚠ · SOST↔XAUT ⚠

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:

1. Alice locks her SOST in a SOST-side HTLC, redeemable by Bob with a secret only Alice knows. Refundable to Alice after timeout T1.
2. 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).
3. Alice claims the BTC by revealing the secret on the Bitcoin chain.
4. 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.

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.

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 both sost-node and sost-miner — well before block #15,000. Don't wait for the fork: compile and restart now.

Required consensus commit (main): ef74e885997a1770c5e60977fa0813bc8a831bd3 — “consensus: gate H3/H4 block validation hardening at V14”.

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.

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.

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.

At block 12,100 — automatic, no action needed

• DTD reward cadence 2-of-3 (bootstrap) → 1-of-3 (permanent).
• 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.

• 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).
• Gold Vault governance threshold synced 95 % → 90 % (doc↔code consistency; enforced at V14).
• V13 preflight RPC getv13readiness — operators confirm a node sees the full 288-coinbase window before the fork.
• Protocol Registry UI — publish capsules from the wallet; live Official / Community tables auto-scanned from the chain.
• Explorer — per-tx NETWORK FEE row with the block-miner beneficiary; BLOCK PRODUCERS · 48H card; cumulative UPDATED MINERS.
• Whitepaper v4.5 regenerated with the V13/V14 scope banner.

• V12 — block 7,350: cASERT ceiling H13 → H20; same-block 4-tier Slingshot anti-stall; Capsule Protocol v1 (binary metadata).
• 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. (Historical: the experimental Useful Compute trial planned alongside this phase never activated rewards and has since been retired.)

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.

• Pre-7,100 chain intact, holder funds safe, chain paused (not corrupted).
• 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.

The profile_index sentinel bug — B0 ↔ H12 oscillation (V4, block 4,170)

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.

• 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.
• Sync / bootstrap fixes (early Apr 2026) — assumevalid checkpoint at block 3,000; ConvergenceX Transcript V2 verification resolved.
• P2P rate-limiter fix (2026-04-06) — the seed node correctly recognises sync requests.
• SLIP-0044 / BIP-44 registration — PR submitted to satoshilabs/slips (2026-04-15).

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.

The SbPoW build-flag stall — 2 h 36 min at block 10,109 (2026-05-24)

The seed node was recompiled from main without 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.

“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.

• SOST DEX Alpha — browser wallet with native encryption (ED25519, X25519, ChaCha20-Poly1305) and encrypted deal flow.
• SOSTEscrow V2 (Sepolia testnet) — currentBeneficiary + settlementOperator, 47 Solidity tests.
• No change to the coinbase split (50 % miner / 25 % Gold Vault / 25 % PoPC Pool), the emission schedule, or the 4,669,201 SOST hard cap.