SOST Network Status Notice — Temporary Block Production Stall
Dear SOST miners, holders and community,
We want to provide a transparent status update about the SOST network.
At the moment, SOST block production appears to be temporarily stalled.
The latest observed block is:
Height: 17,864
Last block time: 2026-07-17 17:24 UTC
Next expected block: 17,865
The node itself is still online and responding. Current checks show:
- Node service: active
- RPC: responding
- Peers: connected
- Mempool: empty
- No evidence so far of a chain rollback
- No evidence so far of funds being lost
- No evidence so far of a consensus rejection loop
The current diagnosis points to a mining-side issue:
The active miner/watchdog appears to have stopped, so no new block is currently being produced.
This means the chain is not “broken” in the sense of corrupted state, but block production is currently not advancing until mining resumes.
What this means for users- Existing balances remain on-chain.
- The explorer may show the chain as delayed or behind schedule.
- New transactions may remain unconfirmed until block production resumes.
- Please avoid sending urgent transactions until blocks are moving again.
What we are doingWe are reviewing the node, mining process and watchdog setup.
The current priority is:
- Confirm the node state
- Restart or restore mining safely
- Verify that block #17,865 is accepted normally
- Monitor the next blocks after recovery
- Publish a follow-up once block production is restored
Important noteThis issue is being treated as an operational mining interruption, not as a confirmed consensus failure.
SOST remains a small, experimental Proof-of-Work network. Miners and users should understand that early-stage networks can experience operational interruptions, especially when active mining participation is low.
We will update the community as soon as new blocks are produced again.
Thank you for your patience and for supporting the network.
— Neob
SOST Protocol
SOST Network Status — Block Production Restored
Post-Mortem: temporary stall at block #17,864 → recovered from #17,873
Dear SOST miners, node operators and community,
Block production on SOST was temporarily interrupted and has now been restored. The chain is producing and accepting blocks normally again. At no point was there any loss of funds, chain rollback, fork, or consensus failure. This is a full and transparent post-mortem.
TL;DR
Block production stalled at #17,864 (2026-07-17 17:24 UTC).
The node stayed healthy the whole time — the interruption was entirely miner-side.
Two operational faults on the mining machine: (1) a dropped SSH tunnel to the node, and (2) a system-clock drift that made the node reject blocks as "timestamp too far in future".Both were fixed. The chain resumed at #17,873 and is chaining normally (#17,874, #17,875, #17,876, #17,877, #17,878, ...).
What happened — timeline
Stall — #17,864, 2026-07-17 17:24 UTC. The network's the node stopped producing. With very few active miners atthis stage, block production halted.
Diagnosis. The server node was verified healthy thro, peers connected, mempool empty, still accepting blocks, norollback, no consensus-rejection loop. The fault was miner-side.
Recovery phase 1 — RPC channel. The miner reaches th(local 127.0.0.1:18232 to node). That tunnel had dropped, sothe miner could not fetch chain/lottery state and aborted every candidate ("rpc connection failed"). Restoring the tunnel let the miner reach the node
again, and the chain advanced.
Recovery phase 2 — clock drift. The chain then stalled again. The node log showed blocks rejected with: Code:Copy CodeREJECTED: timestamp too far in
future (drift cap=30)The mining machine's system clockseconds ahead[/b] (a known clock-drift behaviour on WSL2 aftersleep/suspend). Blocks were stamped in the future and refused by the node's timestamp rule. Re-synchronising the clock (NTP) resolved it.
Restored. From #17,873 onward the node accepts conse74 to #17,878 and counting).
For miners — "node REJECTED block" in your logs is NORMAL
A multi-threaded miner (e.g. 22 threads) searches in parallel t. With low difficulty, several threads find a valid solutionalmost at once — but only ONE block can enter the chain per height.
The first solution to reach the node wins → "submitted to node OK".
The others, for a height that is now already solved, arriveck"[/b].
So seeing many REJECTED alongside one OK per height is normult. The lower the difficulty and the more threads you run, the more REJECTED you will see — it is the price of mining fast.
Healthy vs. problem:
Healthy: "submitted to node OK" appears from time toES. The REJECTED lines in between are harmless noise.
Problem (what caused this stall): EVERY block REJECTED, NO OK, and the height does NOT move. In this incident that was the clock drift, now
fixed.
The REJECTED ratio falls on its own as cASERT raises difficultck target; it never reaches zero, and it should not.
What to watch: do not judge by the local REJECTED lines — the authoritative signal is the node height rising. Verify on the official
explorer (sostcore.com): if BLOCK HEIGHT advances and your bloS, you are mining correctly. Or via RPC:getblockcount should keep increasing.
What did NOT happen
No loss of funds. All balances remained on-chain and untouched.
No rollback, no fork. The tip stayed intact at #17,8nued forward from there.
No consensus bug. The node binary was never changed and never accepted an invalid block — it correctly enforced its timestamp rule.
No node-side fault. This was an operational miner-sick), not a protocol failure.
What NODE operators should do
Run the current node release (v0.4.0). No forced recompile or consensus action is required.
If your node fell behind, let it re-sync from peers; confirreaches the network tip.Nothing else is needed — chain state is intact.
What MINERS should do — to keep mining / resync[
Verify real RPC connectivity to the node before mining[/he miner cannot reach the node it aborts every candidate.
Synchronise your system clock (NTP). A clock more than 30 s ahead causes blocks to be rejected as "timestamp too far in future". On WSL2,
re-sync after sleep/suspend (sudo hwclock -s, NTP, or restart
Use the correct Phase-2 flags (--wallet + --mining-key-label); an address-only launch aborts on a Phase-2 chain.
Confirm success by the node's height rising, not by
Closing
Thank you for your patience. SOST is an early-stage, experimend operational interruptions like this — especially with lowactive-miner participation — are part of that stage. The chain, funds and consensus were never at risk; recovery was a matter of restoring miner-side connectivity and clock sync. We will post a follow-up if anyth
— Neob
How to Mine SOST — Miner Setup Guide
CPU-first Proof-of-Work · fair launch · no pre-mine
SOST is a CPU-only PoW chain and we welcome independent miners. Below is a complete guide to get you mining from scratch. If you hit any issue, post in this thread and we'll help.
1. Requirements- A 64-bit Linux environment (native Linux or WSL2 on Windows).
- A multi-core CPU — more threads = more attempts/sec. Even a mini-PC works.
- ~8 GB RAM free (the miner builds a ~4 GB dataset).
- Build tools: git, cmake, a C++ compiler (build-essential).
2. Get the code and buildClone the repo and build with the MANDATORY flags.
SOST_TESTNET_FORKS must be OFF — building with it ON forks you off mainnet.
git clone <YOUR_REPO_URL>
cd <REPO_DIR>
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)
Verify before continuing:
grep SOST_TESTNET_FORKS build/CMakeCache.txt # must read OFF
The healthiest setup is to run your own node and mine against it — this keeps the network decentralized. Start the node and let it sync with the network:
./build/sost-node <NODE_START_FLAGS — seed nodes, data dir, RPC port>
Wait until it's fully synced. Check its height against the explorer (sostcore.com):
./build/sost-cli getblockcount
When your node's height matches the explorer, you're synced and ready to mine.
(Seed nodes / P2P port: <FILL IN — verified network params>.)4. Create a walletPhase 2 signs every block, so you need a wallet with a mining key. Create one and note the label:
./build/sost-cli newwallet <WALLET_PATH>
<COMMAND TO CREATE/LABEL THE MINING KEY — verify exact syntax>
Your mining rewards go to the address derived from this key.
5. Start miningLaunch the miner with your wallet and label (NOT --address — an address-only launch fails on a Phase-2 chain). Set --threads to your CPU's max:
./build/sost-miner \
--wallet <WALLET_PATH> \
--mining-key-label <YOUR_LABEL> \
--genesis genesis_block.json \
--rpc 127.0.0.1:<YOUR_NODE_RPC_PORT> \
--blocks 999999 \
--profile mainnet \
--threads <YOUR_MAX>
- Clock sync (NTP). The node rejects any block whose timestamp is more than 30 seconds ahead of its clock ("timestamp too far in future"). Keep NTP running. On WSL2, resync after any suspend/resume.
- Node reachability. If the miner can't reach your node's RPC, it loops on "fetch_lottery_state failed" and never produces. Confirm the node answers before mining.
7. How to know it's workingYour local log will show many "node REJECTED block" lines —
this is normal. With multiple threads, several find a valid block for the same height; only the first lands, the rest are late duplicates. Don't judge by the log.
The real signal: your address appears under
LATEST BLOCKS on the explorer (sostcore.com) and the height keeps climbing.
A note on rewardsSOST is designed to be fair to independent miners: the DTD lottery distributes rewards among active miner addresses <VERIFY: describe the anti-dominance mechanism ONLY with the exact parameters confirmed against the code>. This is a fair-launch, long-term protocol — no pre-mine, no pump.
SOST — Miners: how to restart after the stall
Block production was briefly interrupted and is now
restored. The chain is producing normally again. If your miner stopped during the stall, here's how to get it running again — takes a minute.
1. Sync your clock (this is what caused most rejections).A clock more than 30s ahead makes the node reject every block as "timestamp too far in future". Resync before anything else:
sudo ntpdate -u pool.ntp.org # or: sudo hwclock -s
On WSL2, always resync after a suspend/resume.
2. Check your node is caught up to the tip../build/sost-cli getblockcount
Compare against the explorer (sostcore.com). If your node is behind, let it finish syncing before mining.
3. Confirm the miner can reach the node.If you see "fetch_lottery_state failed: rpc connection failed" in your log, your miner can't reach the node — check your RPC/tunnel is up before restarting.
4. Restart your miner with your usual launch (wallet + mining-key-label). No rebuild needed unless you're on an old binary — the current fork is V14.7 (block 17,000); if your last build predates it, pull
main and recompile first.
Note on "node REJECTED block": seeing many of these in your log is
normal with multiple threads — several threads solve the same height, only one lands, the rest are late duplicates. Don't judge by the log. The real check is your address appearing under LATEST BLOCKS on the explorer and the height rising.
Questions — post here, happy to help.
