[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 — Hard fork ACTIVE as of block 4,170 🚨

  V4 HAS ACTIVATED AT BLOCK 4,170. ALL NODES AND MINERS STILL RUNNING V3.1 CODE MUST UPDATE IMMEDIATELY — YOUR BLOCKS
  ARE ALREADY BEING REJECTED BY THE NETWORK.

 
  Why this is urgent

  In the last hours you may have noticed the B0 ↔ H12 oscillation loop: blocks alternating between 37-second bursts and 2-hour
   waits. The chain was effectively stalled at blocks 4,150–4,166 while we diagnosed it. We traced the root cause to a latent bug in
  the V3.1 slew-rate implementation. V4 fixed it and activated cleanly at block 4,170.

  V4 is now live and the chain is advancing normally under the new rules — no more oscillation. Nodes and miners still running old
  code have already been ejected from consensus and are stuck at blocks 4,166–4,167. If that is you, update now to rejoin the network.

 
  The bug

  V3.1 introduced a ±3 per-block slew rate on the equalizer profile. In theory, a jump like B0 → H12 in a single block was impossible.
   In practice, the slew rate was silently disabling itself every time a block was mined at B0.

  Root cause: BlockMeta::profile_index defaulted to 0. The slew-rate code could not distinguish a block legitimately
   mined at B0 (profile_index = 0) from a block whose profile_index was never persisted (also 0). Every legit B0 block was misread as
  "missing", the slew rate fell through to a fallback that disabled itself for that transition, and the next block was free to jump
  directly to H12.

  This is exactly the pattern you saw in the explorer:

 

Code:

B0 block mined → next block: slew disabled → jumps to H12
  H12 → 2h wait → anti-stall drops back to B0 → repeat

  Every cycle took roughly two hours and produced one or two blocks. That is why the chain appeared stuck.

 
  The fix (V4)

 

• Explicit sentinel. BlockMeta::profile_index now defaults to INT32_MIN. A legit B0 (stored as
    0) is no longer confusable with "missing".
• Persistence. profile_index is now stored per block in chain.json and carried through every code path
    that builds the chain view for cASERT, including load, P2P relay, and reorg.
• Fallback removed. The V3.1 prev_H = H escape hatch is deleted entirely. The ±3 slew rate is now unconditional at
     heights ≥ 4,170.
• Ahead Guard retained. The originally-announced V4 feature — bitsQ downward clamp to ~1.56%/block while the chain is ≥16
    ahead — is included unchanged.
• Backwards compatibility (transition only). V4 nodes accepted legacy blocks (without profile_index) at heights
    4,100–4,169 with a B0 default so the network could catch up before activation. As of block 4,170 the field is mandatory and is
    being enforced now.

 
  Update procedure — DO THIS NOW

 

Code:

cd ~/sost-core
  git pull origin main
  cmake --build build -j$(nproc)

  # Restart the service — picks up the new binary
  sudo systemctl restart sost-node
  # (if you launch sost-node manually, stop and relaunch it)

  # Restart your miner
  pkill -x sost-miner
  # relaunch your miner

  Verify you are on the V4 code:

 

Code:

git log --oneline -1
  # Must show: a06c988 or later

  # Confirm the running binary matches the rebuilt one
  md5sum build/sost-node
  md5sum /proc/$(pgrep -x sost-node)/exe
  # Both hashes must be identical

  If your chain.json is in a bad state after the oscillation:

 

Code:

curl -o chain.json https://sostcore.com/bootstrap-chain.json
  # then restart sost-node

 
  Activation parameters

 

Parameter	Value
CASERT_V4_FORK_HEIGHT	4,170 (ACTIVE)
Transition window	blocks 4,100–4,169 (profile_index optional, defaults to B0)
CASERT_AHEAD_ENTER	16 blocks ahead
CASERT_AHEAD_EXIT	8 blocks ahead (hysteresis)
Ahead Guard bitsQ cap	~1.56% max downward per block
Slew rate (post-V4)	±3 profile levels per block, unconditional

  Unchanged: equalizer profile table (E4–H12), PID gains, anti-stall logic, emission schedule, block structure.

 
  A note to miners and testers

  SOST is a brand-new proof-of-work protocol. ConvergenceX, cASERT, the 17-profile equalizer, and the multi-signal control system are
  being validated for the first time under real multi-miner conditions. The slew-rate bug described above only became visible after
  multiple miners were active simultaneously — no simulation caught it, because simulations ran single-node chains where every block
  happened to be at a non-B0 profile.

  Each iteration makes the system more robust. Thank you for your patience while we updated — your logs and mining activity made this
  diagnosable.

  Reminder: the chain has split at block 4,170. Nodes and miners that have not yet updated are unable to submit or
  validate new blocks past that height. Update now to rejoin.

 
  NeoB — SOST Protocol

  

[Neob1844]

cASERT V5 — Determinism + Liveness Update (Planned)

To all miners and node operators:

A new consensus update is being prepared: cASERT V5.

This upcoming fork is intended to address two separate but related issues that have now been confirmed under live multi-miner conditions:

• V5.0: a determinism fix in the current Ahead Guard implementation
• V5.1: a targeted correction for stuck-chain / overshoot behavior under high hardening profiles

Important: no immediate action is required right now.  
The network remains live and operational. This post is intended to explain clearly what has been observed, what is being prepared, and why.


Current network status

The network is running and blocks continue to be produced.

Recent cASERT updates have improved responsiveness and reduced part of the previous lag behavior. However, live operation has now revealed a real edge-case pattern that needs to be corrected more cleanly.

The observed pattern is:

• The chain accelerates under baseline conditions
• The equalizer hardens rapidly (H6 → H9 → H12)
• A block then becomes excessively delayed under H12
• The chain falls behind schedule
• But the equalizer may remain too high for too long, delaying recovery

In simple terms:

the system brakes correctly when ahead, but can remain braking too long once the chain is already behind.

This is not theoretical. It has now been observed on the live chain.


Part 1 — V5.0 determinism fix

During review of the current V4 Ahead Guard implementation, a potential consensus-determinism risk was identified.

In simple terms:

• The current Ahead Guard uses internal persistent state
• Persistent local state is undesirable in consensus-critical code
• Consensus decisions should be derived only from deterministic chain data

This has not been observed causing live divergence so far, but it is a must-fix.

V5.0 does only one thing:

• Removes the persistent state from Ahead Guard
• Replaces it with a fully stateless condition derived directly from schedule lag

This is a correctness fix.


Part 2 — V5.1 liveness / oscillation fix

A second issue has now been confirmed under live conditions:

V5.0 alone does NOT fully solve the stuck-chain scenario.

It fixes determinism, but it does not by itself resolve cases where:

• the chain moves from ahead to behind
• the equalizer is still at very high profiles
• block production becomes excessively delayed

To address this, V5 also includes a liveness-oriented correction:

• Safety rule post-slew: if the chain is already behind, hardening is immediately capped back toward baseline
• EBR (Emergency Behind Release): additional easing for severe behind conditions

This means future cases like the recent H12 stuck-block event should be resolved much faster instead of waiting for anti-stall alone.

In short:

• V5.0 fixes correctness
• V5.1 fixes recovery behavior

What this means for miners

This is the most important message:

ConvergenceX remains a strong and original Proof-of-Work system.

The need for refinement does not mean the system is weak or broken.

It means the system is being tested under the only conditions that matter:

real live network operation with independent miners.

Protocols of this complexity do not become excellent instantly.

They become excellent through:

testing  
observation  
error detection  
correction  
refinement

That is not a weakness.  
That is how a system moves toward something as close as possible to a 10/10 design.


Monitoring and measurement

A dedicated monitoring tool has now been prepared to measure the exact behaviors relevant to V5.

The monitor tracks, among other things:

• overshoot events
• time spent in H12
• blocks above 20 minutes
• blocks above 40 minutes
• lag extremes
• Ahead Guard activation conditions

This means protocol decisions are no longer being made from intuition alone.

We are now measuring the chain directly and quantitatively.

That is the standard going forward.


Why this requires a hard fork

Because both the Ahead Guard fix and the profile recovery behavior affect consensus-level difficulty logic.

All nodes must compute the same result from the same block history.

That is why this update requires a coordinated hard fork.


Planned deployment approach

The current plan is:

• V5 as a unified update
• One coordinated fork height
• Sufficient advance notice for miners and node operators

A tentative target such as block 4350 is under consideration, subject to final confirmation after observation and testing.

Until then:

• No immediate action required
• Keep mining and keep reporting logs if unusual behavior appears

Once activation is announced, the standard procedure will be:

• git pull
• rebuild
• restart node and miner

Final note

To everyone mining, testing, reporting logs, and staying through this phase:

thank you.

This is a real pre-launch hardening process.

It is public, transparent, and technical by design.

Each correction makes the system stronger.  
Each improvement brings SOST closer to the level of robustness we want.

That is the standard.

NeoB — SOST Protocol
sostcore.com ·
GitHub ·
Explorer