SOST Protocol — Useful Compute, Scientific Work and Why Rewards Are Not Being Rushed
SOST is a native Proof-of-Work chain built around ConvergenceX, a custom memory-hard mining system, protocol-level reserve allocation, PoPC design, a public explorer, a wallet, a DEX alpha surface, an AI research engine and a Useful Compute layer that is already implemented as public dry-run infrastructure.
This post is not a listing announcement, not a price statement and not an investment invitation.
SOST is still experimental, unaudited software. There is no active market yet, no exchange listing yet, no guaranteed value and no promise that the protocol will succeed.
What already exists today
SOST is not a whitepaper-only idea.
The current stack already includes:
Native Proof-of-Work blockchain live since genesis.ConvergenceX memory-hard mining.No premine.No ICO.No dev tax.Public GitHub repository.Public explorer.Browser wallet.Encrypted P2P transport.Dynamic difficulty system.Protocol-level allocation: miner / Gold Funding Vault / PoPC Pool.SOST DEX alpha.Useful Compute public dry-run API.Useful Compute worker.Useful Compute task queues.Worker submission system.Ranking endpoint.Verification and dispute tracking.Public audit export.Automatic queue replenishment.Automatic database backups.Automatic scientific reports.Automatic public snapshots.Private SOST AI Engine v0.25.0 with 1,402 tests green.Materials Engine with a large computational materials corpus.GeaSpirit mineral intelligence stack.
The Useful Compute layer is already live as infrastructure.
However, rewards are intentionally postponed.
Why Useful Compute rewards are postponed
The crypto industry is currently overloaded with AI narratives.
There is a lot of marketing around artificial intelligence, GPU compute, useful work and decentralized computation. Some of it may become real and important. But the hard part is not saying that a task is useful.
The hard part is proving that the work is:
genuinely useful;deterministic;auditable;hard enough to justify rewards;safe to verify;not fake busywork;not symbolic computation dressed as scientific value;not a reward system that pays for noise.
SOST does not want to reward weak, artificial or meaningless CPU work just to claim that Useful Compute is active.
The goal is not to burn CPU cycles.
The goal is to produce scientific and protocol-level output that can be checked, audited and justified.
That is why the current Useful Compute worker is testing-only. It can connect, receive tasks, submit results, update rankings and appear in the public audit layer, but current activity is not reward-eligible.
There will be no payout manifest for the dry-run phase.
What Useful Compute is intended to become
Future reward-bearing workloads may include carefully defined task families from the SOST scientific stack.
For Materials Engine, future tasks may include:
large-scale deterministic materials screening;candidate prioritization for later DFT;formula ranking;substitution and dopant exploration;PGM-free catalyst screening;photovoltaic candidate filtering;membrane and battery material pre-screening.
For GeaSpirit, future tasks may include:
deterministic mineral-target scoring;zone and commodity ranking;false-positive filtering;geospatial feature analysis;heavier raster-based processing when the worker environment is ready.
Each future Heavy task family must be documented before activation.
Each future reward window must have clear eligibility rules, verification rules and audit logic.
Useful Compute is not cancelled. It is being held back until the task layer is strong enough to deserve rewards.
SOST AI Engine
SOST also includes a private autonomous research system called the SOST AI Engine.
It is not a public chatbot and not a public API. It is a private, localhost-only research lab that helps organize Materials Engine, GeaSpirit and Useful Compute planning.
The AI Engine can generate hypotheses, classify candidate Heavy tasks, plan experiments, maintain research memory and prepare operator decisions.
But it cannot:
publish to the website by itself;touch consensus;activate rewards;run DFT;approve its own decisions;use the network by default.
The golden rule is simple:
The AI may ask for permission. The AI cannot grant permission to itself.
Roadmap
SOST is being developed in stages.
Current and planned milestones include:
Genesis — completed.
Mainnet live — completed.
Public explorer — completed.
Wallet — completed.
Encrypted P2P transport — implemented.
DEX alpha — live alpha.
Useful Compute infrastructure — live dry-run / testing only.
Useful Compute rewards — postponed until real task definitions are ready.
PoPC — planned activation after technical and network readiness conditions.
Gold Vault governance — planned as a later protocol phase.
Physical gold extension — future phase, condition-dependent.
ZK R&D — future research initiative.
ZK physical custody proofs — aspirational, dependent on production-grade cryptographic maturity.
Post-quantum direction — long-term research direction, not marketed as an active deployed feature.
Heritage Reserve — indefinite long-term protocol objective.
The ZK and post-quantum items are deliberately presented as research and roadmap items, not as deployed claims.
Physical custody verification without revealing identity, location or quantity is still an open research problem. SOST will not deploy partial cryptographic solutions just to satisfy a timeline.
What SOST is trying to avoid
SOST is trying to avoid three common problems:
marketing before infrastructure;rewards before verification;claims before proof.
Useful Compute rewards will only make sense if the work is real, measurable and auditable.
Until then, the infrastructure remains open for public dry-run testing, but reward activation stays postponed.
Summary
SOST already has a live Proof-of-Work chain, custom mining architecture, public explorer, wallet, DEX alpha, Useful Compute dry-run infrastructure, Materials Engine, GeaSpirit and a private AI research engine.
The protocol is not rushing Useful Compute rewards because useful work must be proven, not advertised.
The roadmap includes PoPC, Gold Vault governance, scientific Heavy tasks, ZK research, future privacy-preserving custody proofs and long-term post-quantum research direction.
SOST is experimental.
SOST is unaudited.
SOST may fail.
But the objective is clear:
Code first. Proof first. Rewards only when the work deserves them.
SOST V13 — Release Candidate Signed, Activation at Block 12,000 + V14 Scope Announced
Last updated: 2026-05-30. Current block: ~10,949. V13 activation: block 12,000 (~7 days). V14
activation: block 15,000 (~28 days, ~2026-06-27).
This post consolidates V13 + V14 in one place so every operator and node has the same view.
V13 — CONFIRMED, WIRED, MERGED TO MAIN
Six consensus items ship at block 12,000:
cASERT equalizer E7–H35 — full profile range active (rises from H20 to H35). Closes the V6 calibration cycle.
DTD lottery cooldown 5 → 6 blocks — tighter exclusion under the permanent 1-of-3 cadence.
Future-timestamp drift cap 60 s → 30 s — NTP synchronisation strongly recommended; a host more than 30 s
ahead produces blocks every validator rejects.
Beacon Phase II-A, II-B (3-of-5 threshold sigs) and Phase III P2P gossip — all three advisory only (MAY inform,
MAY NOT restart, MAY NOT block, MAY NOT change consensus, MAY NOT execute commands). Hard limits on P2P: 4 KB max notice,
32-notice LRU dedup, 8 notices/peer/min rate limit.
⚠ SOST V13 RELEASE CANDIDATE (v13-rc1) — ACTIVATION AT BLOCK 12,000
UPGRADE WINDOW: blocks 11,900 – 11,999. Update and restart your node before block 12,000.
What activates at block 12,000
cASERT equalizer ceiling rises H20 → H35 (full E7–H35 range).DTD lottery recent-winner cooldown 5 → 6 blocks.Future-timestamp drift cap 60 s → 30 s. A host whose clock is more than 30 s ahead of real time will produce blocks that validators
REJECT. Run NTP.Beacon Phase II-A (operator-signed advisory notices) + Phase III (P2P gossip). Advisory only — never affects consensus, mining, or block
validity. Phase II-B (threshold) ships implemented but default-off (sentinel) until five independent custodians exist.
What auto-activates at block 12,100 — NO action needed
DTD lottery cadence 2-of-3 → 1-of-3 permanent.Anti-dominance gate: any miner address holding ≥ 30 % of the previous 288 blocks is excluded from DTD lottery eligibility until its rolling share
drops below 30 %. Dominant miners keep their full 50 % miner reward on every block they mine — they only miss the redistributed protocol-side share on
DTD-triggered blocks. Reversible per-block, no slash, no admin authority.
1) NODE OPERATORS — upgrade sost-node
During the upgrade window (blocks 11,900–11,999):
Code:Copy Code cd <your sost-core directory>
git pull origin main
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DSOST_ENABLE_PHASE2_SBPOW=ON ..
make -j$(nproc) sost-node
# restart however you run it, e.g.:
sudo systemctl restart sost-node
Verify the binary is V13-capable:
Code:Copy Code strings build/sost-node | grep -c 'POW-SIG/v13' # must be > 0
Pre-fork readiness check (NEW in V13 — read-only RPC, touches no consensus):
Confirms your node can observe the last 288 coinbases (needed for the 12,100 anti-dominance gate):
Code:Copy Code curl -s -X POST
http://127.0.0.1: (
http://127.0.0.1/)<your_rpc_port> \
-H "Content-Type: application/json" \
-d '{"method":"getv13readiness","params":[],"id":1}'
"ready": true → your node sees the full window. You're set for the fork."ready": false → re-sync your node before block 12,000.
2) MINERS (e.g. WSL miner bridged via RPC tunnel to your node)
Code:Copy Code cd <your sost-core directory>
git pull origin main
cd build
make -j$(nproc) sost-miner
# restart the miner pointing at your UPGRADED node's RPC, using your own
# --address / --rpc / --rpc-user / --rpc-pass / --threads
NTP is mandatory for miners. With the 30 s drift cap, an unsynchronised clock will get your blocks rejected.
Beacon II-A operator key — published
Canonical fingerprint:
Code:Copy Codebbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b = sha256 of the lowercase uncompressed pubkey hex (BEACON_PUBKEY_HEX in src/beacon.cpp). Cross-published in the README, whitepaper and
this thread so a substituted key is detectable. Beacon is advisory-only — it can MAY inform, MAY NOT restart, block, or change consensus.
No coordination needed: the upgrade is backward-compatible at validation level — old and new nodes agree up to block 12,000, where the new rules
take effect by height. Upgrade any time within the window.
Source: github.com/Neob1844/sost-core (
https://github.com/Neob1844/sost-core) (branch main)
⚠ SOST V13 RELEASE CANDIDATE (v13-rc1) — ACTIVATES AT BLOCK 12,000
Upgrade window: blocks 11,900 – 11,999 · Source: github.com/Neob1844/sost-core (branch main)
Update and restart your node BEFORE block 12,000. The change is backward-compatible at validation level — old and new nodes agree up to 12,000,
where the new rules take effect by height — so you can upgrade any time inside the window, node by node, no coordination required.
What activates at block 12,000
cASERT equalizer ceiling H20 → H35 (full E7–H35 range).DTD lottery recent-winner cooldown 5 → 6 blocks.[/li]
[li]Future-timestamp drift cap 60 s → 30 s. Run NTP. A host whose clock is more than 30 s ahead of real time will produce
blocks that validators REJECT.[/li]
[li]Beacon Phase II-A (operator-signed advisory notices) + Phase III (P2P gossip). Advisory only — never affects consensus, mining,
or block validity. Phase II-B (3-of-5 threshold) ships implemented but default-off until five independent custodians exist.[/li]
[/list]
What auto-activates at block 12,100 — NO action needed
DTD lottery cadence 2-of-3 → 1-of-3 permanent.Anti-dominance gate: any miner address holding ≥ 30 % of the previous 288 blocks is excluded from DTD lottery eligibility until its rolling
share drops below 30 %. Dominant miners keep their full 50 % miner reward on every block they mine — they only miss the redistributed protocol-side share
on DTD-triggered blocks. Reversible per-block, no slash, no admin authority.
1) NODE OPERATORS — upgrade sost-node
Code:Copy Code cd <your sost-core directory>
git pull origin main
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DSOST_ENABLE_PHASE2_SBPOW=ON ..
make -j$(nproc) sost-node
# restart however you run it, e.g.:
sudo systemctl restart sost-node
Confirm the binary is V13-capable:
Code:Copy Code strings build/sost-node | grep -c 'POW-SIG/v13' # must be > 0
Pre-fork readiness check (NEW in V13 — read-only RPC, touches no consensus):
Confirms your node can observe the last 288 coinbases (needed for the 12,100 anti-dominance gate):
Code:Copy Code curl -s -X POST
http://127.0.0.1: (
http://127.0.0.1/)<your_rpc_port> \
-H "Content-Type: application/json" \
-d '{"method":"getv13readiness","params":[],"id":1}'
"ready": true → your node sees the full window. You're set for the fork."ready": false → re-sync your node before block 12,000.
2) MINERS (e.g. WSL miner bridged via RPC tunnel to a node)
Code:Copy Code cd <your sost-core directory>
git pull origin main
cd build
make -j$(nproc) sost-miner
# restart the miner pointing at your UPGRADED node's RPC, using your own
# --address / --rpc / --rpc-user / --rpc-pass / --threads
NTP is mandatory for miners. With the 30 s drift cap, an unsynchronised clock will get your blocks rejected.
Beacon II-A operator key — now anchored on-chain
The V13 operator advisory key is published, and its fingerprint is now the first OFFICIAL entry in the SOST Protocol Registry, committed to the
chain itself:
Fingerprint: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186bAnchored at block: 11,034 — txid c6ade3c635d0e5f8814e3512db7974d70908d6bf5000ddc7aafa708452f810a1Signer: SOST Protocol developer address (OFFICIAL whitelist)Manifesto: sostcore.com/api/sost-protocol-beacon-iia-v13-fingerp
rint-v1.json (
https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json)
How you know a Beacon notice is really from the operator
The operator holds a secret key (offline, encrypted USB — never online). The matching public key is baked into the node software you already run
(BEACON_PUBKEY_HEX in src/beacon.cpp). Every notice is signed with the secret key; your node automatically verifies the signature
against the public key and silently drops anything that doesn't verify. A valid notice is still advisory-only — it MAY inform, but it can NEVER
restart your node, block anything, or change consensus.
Verify it yourself (anyone can):
Code:Copy Code # 1) the published key fingerprint matches the source code:
grep -A3 'BEACON_PUBKEY_HEX =' src/beacon.cpp | grep -oE '"[0-9a-f]+"' | tr -d '"\n' | sha256sum
# expected: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b
# 2) the on-chain anchor matches the manifesto:
curl -s
https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json | sha256sum
# expected: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
# (its first 16 hex are the anchor carried in the on-chain capsule)
If either value does not match, do not trust that copy.
Links
Source: github.com/Neob1844/sost-core (
https://github.com/Neob1844/sost-core) (branch main)Protocol Registry: sostcore.com/protocol-registry.html (
https://sostcore.com/protocol-registry.html)Explorer: sostcore.com/sost-explorer.html (
https://sostcore.com/sost-explorer.html)
SOST Protocol Registry — First Official Entry: V13 Beacon II-A Operator Key Anchored On-ChainThe canonical SOST Beacon Phase II-A operator-key fingerprint is now anchored on the SOST chain itself, as the first OFFICIAL entry in the Protocol Registry. The fingerprint was already cross-published (source code, README, whitepaper, this forum); this commits it to the ledger, so the operator advisory key has a permanent, independently-verifiable on-chain timestamp.
On-chain record- Block: 11,034 — 2026-05-31 06:17:21 UTC
- Txid: c6ade3c635d0e5f8814e3512db7974d70908d6bf5000ddc7aafa708452f810a1
- Signer: sost1a8eae8f80fedd8d86187db628a0d81e0367f76de (SOST Protocol developer address, on the OFFICIAL whitelist)
- Capsule (Open Note): sost-protocol beacon-iia-v13 ceb19dd6b5fd676f
- Manifesto: sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json
- Manifesto SHA-256: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
- Beacon II-A key fingerprint: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b
How the anchor worksThe on-chain capsule carries the first 16 hex of the manifesto's SHA-256 (
ceb19dd6b5fd676f). The manifesto JSON in turn publishes the full Beacon II-A key fingerprint. The fingerprint is the SHA-256 of the lowercase uncompressed public-key hex (
BEACON_PUBKEY_HEX in
src/beacon.cpp). Two independent links, both verifiable by anyone.
Independent verification — anyone can run this1) The on-chain anchor matches the published manifesto:curl -s https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json | sha256sum
# expected: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
# the first 16 hex (ceb19dd6b5fd676f) are exactly the anchor in the on-chain capsule.
2) The published key fingerprint matches the source code on GitHub:curl -s https://raw.githubusercontent.com/Neob1844/sost-core/main/src/beacon.cpp \
| grep -A3 'BEACON_PUBKEY_HEX =' | grep -oE '"[0-9a-f]+"' | tr -d '"\n' | openssl dgst -sha256
# expected: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b
(sha256sum and openssl dgst -sha256 are equivalent; use whichever your system has.)If either value does not match, do not trust that copy.
Scope — what Beacon is and is NOTBeacon is an authenticated advisory channel for the protocol operator. The operator key can sign notices that nodes display, but it can NEVER:
- restart a node
- reject or alter a block
- slash a miner or freeze funds
- change any consensus rule
Phase II-A (single-signature advisory notices) is active from V13 (block 12,000), together with Phase III (peer-to-peer gossip). Phase II-B (3-of-5 threshold signatures) is implemented and tested but ships default-off (
BEACON_IIB_THRESHOLD_ACTIVATION_HEIGHT = INT64_MAX) until five independent custodians exist.
Why this mattersCross-publishing the Beacon fingerprint across multiple independent channels (source code, README, whitepaper, BitcoinTalk, and now the chain itself) makes silent key substitution detectable. An attacker who replaces the key in any one channel produces a mismatch with the others; a verifier comparing two channels detects the fraud. The on-chain anchor is the immutable, permanent channel of last resort.
Links— SOST Protocol