[ANN] SOST — Native PoW Chain | ConvergenceX | CPU-Only | 8 GB | Gold Reserve

[oswaldzc]

Hello, Neob1844

are there any plans to optimize the miner program to display hashrate?

PS: mining is really difficult right now — is anyone willing to set up a mining pool?

[Neob1844]

 

  cASERT V3.1 — Minor Fix at Block 4,200
 

 
  SOST is a completely new proof-of-work protocol built from scratch — ConvergenceX, cASERT, the P2P layer, the economic model — none of it
  existed before 2026. A system of this complexity requires continuous refinement as it operates under real-world conditions for the first time.

  The core protocol is secure and stable. However, live operation with multiple miners at varying hashrates has revealed two edge cases in the
  cASERT equalizer that require correction:

  Fix 1 — Slew rate enforcement (consensus, block 4,200):
  The V3 equalizer recomputed the previous block's profile using raw PID output without applying the slew rate constraint. This allowed the
  profile to jump more than the intended ±3 levels in certain conditions. V3.1 uses the actual stored profile from the previous block, ensuring
  the ±3 limit is always respected.

  Fix 2 — Anti-stall threshold (policy, immediate):
  The anti-stall activation threshold scaled with block lag (lag × 600s), which at 67 blocks ahead resulted in an 11-hour delay before
  anti-stall could help. This is now fixed to always activate after 2 hours maximum, regardless of lag.

  Action required:
 

Code:

  cd /path/to/sost-core
  git pull origin main
  cd build && cmake .. -DCMAKE_BUILD_TYPE=Release && make -j$(nproc)
  # Restart node and miner
  

  If you already updated for V3 at block 4,100, this is the same process — just pull and rebuild.

  Timeline: V3.1 activates at block 4,200 (~98 blocks from block 4,102). The anti-stall fix is active immediately after update.

  Existing blocks are not affected. Blocks 4,100-4,199 remain valid under V3 rules. V3.1 applies only from block 4,200 onward.

 
 

NeoB — SOST Protocol
  sostcore.com · GitHub ·
  Explorer

[Neob1844]

  Hi vostokzyf,

  If DNS resolution fails, connect by IP directly:

 

Code:

  ./sost-node --rpc-user vostok --rpc-pass vostok \
    --genesis genesis_block.json --chain chain.json \
    --connect 212.132.108.244:19333 \
    --profile mainnet --p2p-enc off
  

  Also please update — there is a V3.1 minor fix at block 4,200. Same process: git pull origin main, rebuild, restart.

[Neob1844]

Hi oswaldzc,

Hashrate display is now in the latest code. After you pull and rebuild, your miner will show something like:

[HASHRATE] 18.3 att/s | threads=4 | total=1200 | stable=87% | elapsed=65s

Mining pool, good idea for the future, but with 6 miners right now it's a bit early. Once we grow to 20-30+ miners it'll make a lot more sense. Happy to share integration specs if you want to build one.

About the difficulty, yeah, it's tough right now. The chain got ahead of schedule so the equalizer kicked in hard. It'll ease up as things normalize. Make sure you're on the latest code: git pull, rebuild, restart.

[Neob1844]

    ⚠ URGENT — cASERT V3.1 activation accelerated to block 4,110

  All nodes and miners: please update immediately.

  What happened:
  A bug in V3 causes the equalizer profile to oscillate between H3 and H12 in a single block — violating the ±3 slew rate limit. This makes
  mining very difficult with long periods at 0% stability.

  What changed:

  

Fix	Problem	Solution	Type
V3.1 slew rate	Profile jumped H3→H12 in 1 block (9 levels). Raw PID recomputation ignored actual previous   profile.	Uses stored profile_index from previous block. ±3 now enforced correctly.	Consensus (block 4,110)
Anti-stall threshold	Activation scaled with lag (67 ahead = 11h wait). Mining impossible for hours.	Fixed to always 2   hours max, regardless of lag.	Policy (immediate)
Miner profile refresh	Miner started at H12/0% stability and never checked if anti-stall decayed the   profile.	Auto-detects profile change every 2 min and restarts with easier profile.	Miner (immediate)
Hashrate display	No way to see mining speed.	Real-time [HASHRATE] X.X att/s output in miner logs.	Miner   (immediate)

  Activation accelerated from block 4,200 to block 4,110 due to severity of oscillation.
  Blocks 4,100-4,109 remain valid under V3 rules. Existing chain is not affected.

  You can update now. The consensus fix activates automatically at block 4,110, but the miner improvements (anti-stall detection,
  hashrate display) are active immediately after rebuild.

  To update:
  

Code:

  cd ~/sost-core
  git pull origin main
  cd build
  cmake .. -DCMAKE_BUILD_TYPE=Release
  make -j$(nproc)
  

 Restart node and miner. Same process as V3.

  Context: SOST is a completely new PoW protocol — ConvergenceX, cASERT, 17-profile equalizer, PID controller — built from scratch. The
  core design is sound. These are edge cases found under real multi-miner conditions, exactly what the pre-launch testing phase is for.

    

[Rizki Maryanto]

Hi NeoB,

Updated to V3.1 and it's running smooth. The hashrate display is a great addition!

I’m currently peaking at 9.0 att/s on my setup. I’ve been mining for over 2 days now, but honestly, I haven't caught a single block yet. It's getting pretty discouraging for small miners like me, while the "whales" seem to be sweeping everything since the difficulty is so high.

Are there any concrete plans for a mining pool in the near future? Solo mining is basically a lottery right now where only the big players win. A pool would really help smaller contributors get a fair share and keep the network decentralized.

Thanks for the update!

[Neob1844]

  Hi Rizki,

  Glad V3.1 is running smooth! At 9 att/s you're likely running with few threads. Here's how to check your system and optimize:

  Step 1: Check your hardware
  

Code:

  # How many CPU cores/threads available:
  nproc

  # CPU model and details:
  lscpu | grep -E "Model name|CPU\(s\)|Thread"

  # Total RAM and available:
  free -h

  # Example output:
  #   nproc → 8
  #   Model name: AMD Ryzen 7 5800H
  #   CPU(s): 16  (8 cores × 2 threads each)
  #   Mem: 31Gi total, 22Gi available
  

  Step 2: Calculate your optimal --threads

  The miner needs:
  - 8 GB for the shared scratchpad (fixed, shared by all threads)
  - ~1 GB for the OS and node
  - ~0.5 GB per mining thread

  Formula: threads = min(cores - 1, (total_RAM - 9) / 0.5)

  Examples:
  

Code:

  8 cores,  16 GB RAM → --threads 4   (limited by RAM)
  8 cores,  32 GB RAM → --threads 7   (limited by cores)
  12 cores, 32 GB RAM → --threads 11  (limited by cores)
  16 cores, 64 GB RAM → --threads 15  (limited by cores)
  4 cores,  16 GB RAM → --threads 3   (limited by cores)
  

  Step 3: Restart your miner
  

Code:

  pkill -9 -f sost-miner
  cd ~/sost-core/build
  git pull origin main
  make -j$(nproc) sost-miner
  ./sost-miner --address YOUR_ADDRESS \
    --rpc 127.0.0.1:18232 --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
    --blocks 999999 --profile mainnet --threads N
  

 Replace N with your number from Step 2.

  Step 4: Verify
  After ~2 minutes you should see:
  

Code:

  [HASHRATE] 35.2 att/s | threads=6 | total=4200 | stable=87% | elapsed=120s
  

 Your hashrate should scale roughly linearly: 4 threads ≈ 4× single-thread speed.

  
  About mining pool: It's on the roadmap but premature with 6 miners. Building a pool requires stratum protocol, share management, and
  payout infrastructure. When we reach 20-30+ miners it will make sense. For now, optimizing your threads is the fastest path to finding blocks.

  The two dominant miners likely run 8-10+ threads on fast CPUs. With --threads 6-8 you close that gap significantly.

  Important: Don't set --threads too high. If you exceed your available RAM, your OS will kill the miner process ("Killed" message).
  Start with a conservative number from Step 2 and increase by 1 if stable. If you see "Killed" or "REJECTED", reduce by 1-2 threads.

[oswaldzc]

My runtime environment is WSL2, Ubuntu 24.04.
The miner process information is as follows:


PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
498 oswald    20   0   36.7g  36.0g   6912 S 821.0  76.5  22:42.60 sost-miner

[MINING] Starting 8 threads for parallel nonce search
[HASHRATE] 33.9 att/s | threads=8 | total=1553 | stable=0% | elapsed=46s
[HASHRATE] 36.6 att/s | threads=8 | total=3086 | stable=0% | elapsed=84s
...
[HASHRATE] 42.0 att/s | threads=8 | total=467262 | stable=0% | elapsed=11124s

I have two questions:
Why is the memory usage 36 GB instead of 8 GB + 8 × 0.5 GB = 12 GB?
Why does "stable" remain at 0%—is this normal?

[Neob1844]

   ⚠ SECURITY FIX — All nodes and miners: update immediately

  A validation bug was found and fixed. Blocks without profile_index were being accepted at E1 difficulty (very easy) instead of the
  correct H12. Additionally, the lag floor is now enforced as a minimum profile — miners cannot declare a profile below lag/8.

  What was fixed:
 

• Blocks without profile_index are now rejected at V3+ heights
• Lag floor enforced as minimum: at lag=37, minimum profile is H4 (37/8)
• Profile_index fallback for chain-imported blocks corrected

  You MUST update both node and miner:
 

Code:

  cd ~/sost-core
  git pull origin main
  cd build
  cmake .. -DCMAKE_BUILD_TYPE=Release
  make -j$(nproc)
  

  Then restart both:
 

Code:

  pkill sost-node
  pkill sost-miner

  # Download fresh chain
  curl -o chain.json https://sostcore.com/bootstrap-chain.json

  # Start node
  ./sost-node --genesis genesis_block.json --chain chain.json \
    --connect 212.132.108.244:19333 \
    --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
    --profile mainnet --p2p-enc off

  # Start miner (after node syncs)
  ./sost-miner --address YOUR_ADDRESS \
    --rpc 127.0.0.1:18232 --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
    --blocks 999999 --profile mainnet --threads N
  

  Old code will have blocks rejected by updated nodes. If your node is stuck or not syncing, delete your chain.json and re-download the
  bootstrap.

  This is the pre-launch testing phase working as intended — real miners found a real edge case, and it's now fixed. Thank you for your
  patience.

   

NeoB — SOST Protocol
  sostcore.com · GitHub ·
  Explorer

[Rizki Maryanto]

I see that the Neob concept has a solid and well-thought-out foundation, which makes it quite interesting for further development. At the moment, I’m still at an early stage by allocating a small portion of my resources (RAM) to mine SOST as an initial participation.
However, I would like to gain a clearer understanding of the project’s roadmap, particularly regarding the plan for SOST to be listed on CEX platforms. This is an important consideration for me in determining my next steps, including the potential to enter as an early buyer once the token becomes available on the market.
On the other hand, if SOST has not yet been listed, I would also like to know whether there is an option to purchase directly from the developer or the team, of course through a secure and transparent mechanism.
I’m quite interested in following the progress of this project and look forward to potentially being more involved in the future.

[Neob1844]

 Hi oswaldzc,

  Two good questions:

  1. Memory (36 GB): The 36 GB includes the full scratchpad (8 GB) + the dataset (4 GB) + OS/node overhead. With 8 threads, each thread
  also allocates working memory for the 32×32 matrix operations and stability checks. WSL2 may also report shared memory differently. The key
  metric is: if it runs without "Killed", your RAM is fine.

  2. Stable=0%: This is because the current profile is H12 (margin=105, scale=3). At H12, the stability basin test is extremely strict —
  almost no solutions pass. This is the cASERT equalizer doing its job: the chain is 35+ blocks ahead, so mining is intentionally very hard to
  slow block production.

  Important: Please update your code — a security fix was just deployed. See post #69 above for instructions. After updating, the profile
   will respond correctly and stability will improve as the chain lag decreases.

[Neob1844]

  Hi Rizki,

  Thank you for the kind words and your interest.

  OTC Status: The OTC sale is currently closed. There was an initial offer of 3,000 SOST at $0.20 each, priced below the PoPC
  reference value (~$0.22 at the time). However, as more tokens are mined, the reference value adjusts. To be clear: this is a simulated
  reference price based on the tokenized gold I have personally committed to the PoPC program — it is not a market price. SOST is not listed
   on any exchange yet, so there is no real market price.

  Whatever is obtained from any future sale will go entirely to purchasing more tokenized gold (XAUT or PAXG) to strengthen the protocol
  reserve.

  Exchange listing: Exchange outreach is planned from June 2026, subject to network stability and sufficient hashrate.

  But here's what you CAN do — and it's better than buying:

  When PoPC activates after block 5,000, you can earn SOST for free just by holding tokenized gold in your own Ethereum wallet. No need to buy
  SOST at all. There are two models:

  Model A — Autocustody (recommended for crypto holders):
  You hold XAUT or PAXG in your own Ethereum wallet. You lock a SOST bond as commitment. Random audits verify your gold balance via Ethereum
  RPC. At the end of your commitment period, you get your bond back + a reward in SOST.

  Example: You hold 0.5 oz XAUT (~$2,350) in your wallet. You lock a SOST bond (25% of gold value). You commit for 6 months. If you maintain
  custody, you receive your bond back + up to 9% reward. Your gold never leaves your wallet.

  Model B — Escrow (simpler, no audits):
  You deposit XAUT or PAXG into an immutable escrow contract on Ethereum. You receive SOST immediately — no bond, no audits, no slash risk. At
  expiry, you withdraw 100% of your gold.

  Example: You deposit 0.5 oz XAUT into escrow for 6 months. You receive up to 3.5% of gold value in SOST immediately. After 6 months, you
  withdraw your full 0.5 oz XAUT. You keep the SOST.

 Reward rates (Tier 1 — first 25 participants get maximum rates):

  Model A (% of bond, fee 3%):
  1mo: 1% | 3mo: 4% | 6mo: 9% | 9mo: 14% | 12mo: 20%

  Model B (% of gold value, fee 8%):
  1mo: 0.4% | 3mo: 1.5% | 6mo: 3.5% | 9mo: 5.5% | 12mo: 8%

  PoPC Reward Example — Live prices (April 13, 2026)
  XAUT: $4,702.75/oz | SOST reference: $0.17 (PoPC reference, not market price)

  Model A — Autocustody (your gold never moves, fee 3%)
  Bond required: 6,916 SOST ($1,175)

  

Duration	Net Reward	USD value	Return on gold
1 month	67 SOST	$11	0.24%
3 months	268 SOST	$46	0.97%
6 months	604 SOST	$103	2.18%
9 months	939 SOST	$160	3.40%
12 months	1,342 SOST	$228	4.85%

  Result: bond returned (6,916) + reward (1,342) = 8,257 SOST. Your gold stays in your wallet untouched.

  Model B — Escrow (no SOST needed, fee 8%)
  No bond. SOST paid immediately at deposit.

  

Duration	Net Reward	USD value	Return on gold
1 month	102 SOST	$17	0.37%
3 months	382 SOST	$65	1.38%
6 months	891 SOST	$151	3.22%
9 months	1,400 SOST	$238	5.06%
12 months	2,036 SOST	$346	7.36%

  Result: 2,036 SOST received on day 1 + your gold returned 100% at expiry.

  Which is better?
  

• Model A: You need SOST for the bond, 4.85% return on gold, your gold never moves, risk of slash if you sell gold during
    commitment
• Model B: No SOST needed, 7.36% return on gold paid immediately, but your gold is locked in escrow until expiry

  All values use PoPC reference price ($0.17/SOST) — illustrative only, not a market price. Rates shown are Tier 1 maximums (first
  25 participants).

  Rates decrease automatically as more participants join (6 dynamic tiers). Hard cap: 1,000 SOST max per contract. Full details:
  sostcore.com/sost-popc.html and sostprotocol.com/sost-popc.html  

  

[Neob1844]

●

 cASERT V4 — Planned Improvement (coming soon)
  

  
  Current status: The chain is running and the average block time is stabilizing around the 10-minute target. However, block
  production shows sharp oscillations — periods of very slow blocks (30-60 min at high profiles) followed by bursts of fast blocks
  (1-2 min) when the profile drops. This pattern reduces as the chain lag decreases, but it reveals a structural coordination issue
  between the two difficulty controllers.

  The problem:
  cASERT has two independent difficulty controllers:

  

• bitsQ — the numerical difficulty (slow, strategic, adjusts every block based on timing)
• Equalizer — the computational difficulty via 17 profiles E4-H12 (fast, tactical, PID-controlled)

  When the chain is ahead of schedule, the equalizer correctly raises the profile to H8-H12 to slow block production. But the slow
  blocks that result cause bitsQ to drop — interpreting the slow block as a signal to reduce difficulty. When the anti-stall
  eventually lowers the profile, bitsQ is already too low, and blocks come out extremely fast — undoing much of the correction.

  In short: the equalizer brakes, but bitsQ releases the brake too early.

  The solution — V4 Ahead Guard:
  V4 will introduce a coordination layer between bitsQ and the equalizer. When the chain is materially ahead of schedule (≥16 blocks),
   bitsQ will be prevented from lowering difficulty aggressively. This ensures both controllers work together instead of against each
  other.

  Key design:
  

• Enter AHEAD_CORRECTION mode when ahead ≥ 16 blocks
• Exit when ahead ≤ 8 blocks (hysteresis prevents oscillation)
• While active: bitsQ downward adjustment is clamped to a minimal value
• The equalizer, anti-stall, PID signals, and profile table remain unchanged

  Timeline: V4 will be implemented after the chain stabilizes under V3.1 (1-2 days of observation). We want to do one clean,
   well-tested fork rather than rushing multiple small changes.

  We will announce the exact activation block with sufficient advance notice. As always: git pull, rebuild, restart.

  Why not now? The chain is currently absorbing V3.1 changes. Adding another consensus change while miners are still updating
  would create unnecessary confusion. V3.1 is already reducing the lag (from 67 to 30 blocks ahead). We want clean data before making
  the next move.

  

[Neob1844]

cASERT V4 — Ahead Guard Coordination Fix (Scheduled)

Overview

The network is currently operating correctly and the average block time is converging toward the 10-minute target. However, during recent observation, block production has shown a clear pattern of oscillation:

• Periods of very slow blocks (high equalizer profiles H10–H12)
• Followed by bursts of very fast blocks (1–2 minutes)

This behavior becomes more visible when the chain is significantly ahead of schedule.

Root cause

cASERT currently uses two coordinated but independent difficulty controllers:

• bitsQ — numerical difficulty (slow, timing-based)
• Equalizer — computational difficulty via 17 profiles (E4–H12, PID-controlled)

When the chain is ahead:

• The equalizer correctly raises the profile (H8–H12) to slow down block production
• Blocks take longer, as expected
• However, bitsQ interprets the slow block as a signal to reduce difficulty

When the equalizer later drops (anti-stall or normalization), bitsQ is already too low, resulting in very fast blocks that undo part of the correction.

In short: the equalizer applies the brake, but bitsQ releases it too early.


The solution — cASERT V4

V4 introduces a coordination mechanism between bitsQ and the equalizer: the Ahead Guard.

Key idea:
While the chain remains materially ahead of schedule, bitsQ will no longer be allowed to relax difficulty aggressively.

New behavior

• Enter AHEAD_CORRECTION mode when the chain is ≥16 blocks ahead
• Exit when the chain returns to ≤8 blocks ahead (hysteresis prevents oscillation)
• While active: bitsQ downward adjustment is strongly limited
• bitsQ can still increase difficulty normally
• Equalizer, PID controller, profiles, and anti-stall remain unchanged

Effect

Instead of this pattern:

Code:

slow block → bitsQ drops → profile drops → very fast blocks → ahead again

We get:

Code:

slow block → bitsQ holds → profile drops → normal blocks → convergence to schedule

Analogy:  
Previously, the system was pressing the brake and the accelerator at the same time.  
With V4, when braking is active, the accelerator is no longer released prematurely.


Implementation details

• Activation block: 4200
• Ahead threshold (enter): ≥16 blocks
• Exit threshold: ≤8 blocks
• bitsQ downward adjustment cap during ahead correction: ~1.56% per block (previously up to 12.5%)
• Upward adjustments: unchanged

No changes are made to:

• Equalizer profile table (E4–H12)
• PID controller signals
• Anti-stall logic
• Emission or consensus structure

Why this requires a hard fork

This change modifies the consensus-level difficulty calculation (bitsQ).  
All nodes must compute the same difficulty to validate blocks.

Therefore:

• All node operators and miners must update before activation
• Nodes that do not update will stop syncing at the fork point

Deployment approach

The change has been implemented and committed, but activation is intentionally delayed.

This allows:

• Observation of V3.1 behavior under real conditions
• Collection of clean data before activation
• Avoiding rapid successive forks

The goal is to perform one clean, well-tested correction, rather than multiple incremental changes.


Current status

The chain is already showing improvement under V3.1, with the lead decreasing.

V4 is designed as a targeted fix for the remaining coordination issue and is expected to significantly reduce oscillations and improve convergence toward expected block height.


A note to miners and testers

SOST is a completely new proof-of-work protocol. ConvergenceX, cASERT, the 17-profile equalizer, and the multi-signal control system are being validated under real multi-miner conditions.

Some behaviors only emerge under live operation — not in simulation.

Each iteration improves the system's robustness. We are building transparently, in public, and we appreciate the patience and collaboration of everyone participating in testing.

This is what a serious pre-launch phase looks like.

NeoB — SOST Protocol
sostcore.com ·
GitHub ·
Explorer

[vostokzyf]

Has the block been stuck for a long time? There's no sign of it moving right now.

[Neob1844]

Hi vostokzyf,

No worries — the chain is not stuck. What you are seeing is the anti-stall mechanism working as designed.

When the chain gets ahead of schedule (currently about 19 blocks ahead), the cASERT equalizer raises the profile to H12 to slow block production. At H12, blocks become intentionally much harder to find. After around 2 hours without a block, the anti-stall system activates and gradually lowers the profile — H12 → H11 → H10 → ... → B0. Each step is reduced every 10–20 minutes. Once the profile returns to a more mineable level (roughly H3–H4), blocks begin flowing again.

This is expected behavior while the chain corrects its lead over the expected schedule. The gap is already narrowing (it was 67 blocks ahead before, now it is around 19).

A further improvement is scheduled at block 4,200: cASERT V4 — Ahead Guard. This upgrade is designed to smooth out these oscillations by preventing the numerical difficulty (bitsQ) from dropping too quickly during long slow periods. After V4, block production should become more consistent.

Please make sure you are on the latest code: `git pull`, rebuild, and restart both the node and the miner.

[Neob1844]

  cASERT V4 — Activation moved forward to block 4,170 (urgent fix)

Please, wait for instructions.