Official Telegram announcement channel for SOST Protocol.

SOST is a native Layer 1 Proof-of-Work coin with its own mainnet, explorer and open-source repository. It is not an ERC-20 or smart-contract token.

Website: https://sostcore.com
Explorer: https://sostcore.com/sost-explorer.html
GitHub: https://github.com/Neob1844/sost-core
X: https://x.com/SOSTCore

— NeoB
SOST Protocol

SOST Protocol — Market Data Listing Requests Submitted

SOST Protocol has submitted market-data listing / project review requests for SOST to the following platforms:

• CoinMarketCap — Ticket ID: 1366213
• CoinGecko — Ticket ID: 129449
• CoinPaprika — Ticket ID: 2415351
• CoinCodex — Request submitted by email / pending review

These requests are currently pending review. No listing, ranking, market page or exchange market has been confirmed yet.

SOST is a native Layer 1 Proof-of-Work coin with its own mainnet, explorer, address format, source repository and consensus rules. It is not an ERC-20 or smart-contract token, and there is no contract address.

Official links:
Website: https://sostcore.com
Explorer: https://sostcore.com/sost-explorer.html
GitHub: https://github.com/Neob1844/sost-core
Whitepaper: https://sostcore.com/sost-whitepaper.html
Protocol spec: https://sostcore.com/sost-protocol-spec.html
X: https://twitter.com/SOSTCore
Telegram: https://t.me/SOSTProtocolOfficial

This post is provided as public verification that the above market-data listing / project review requests were submitted by the official SOST Protocol team.

— NeoB

SOST Protocol — Network Status Notice (Block 10,110)

I'm posting a transparent update for node operators and miners.

What I am seeing

Block height 10,109 is currently the last block my reference node has
accepted. Blocks submitted at height 10,110 are failing SbPoW signature
validation (BIP-340 Schnorr verification failed for the recomputed
message). The proof-of-work itself verifies correctly — the CX Transcript
V2 check passes — so this is specifically a signature / message-
construction validation issue, not a PoW failure.

What I currently believe happened

A node binary update on the reference node introduced inconsistencies in
the local state used by miners to construct the SbPoW signing message.
The V13 code paths added in that build are correctly height-gated
(V13_HEIGHT = 12,000) and are NOT active at the current height — V13
is unrelated to this incident. One or more block 10,110 candidates were
produced with stale local state and the network is not converging on a
single valid block at that height.

This is my current working hypothesis, not a confirmed final diagnosis.
I am still verifying it.

What is NOT affected

- The chain up to block 10,109 is fully intact — UTXO set, balances and
history are unaffected.
- No funds are at risk. No user action is required.
- Daily chain backups are in place and verified.
- This is not a V13 hard-fork event. V13 activates at block 12,000 and
is unrelated.

What I am doing

I am running a controlled analysis to (1) confirm the exact point of
divergence, (2) identify which block 10,110 — if any — was produced
under correct rules, and (3) determine the cleanest path to bring all
nodes back onto a single canonical chain. I am deliberately not applying
rushed fixes to consensus or chain state, as that carries more risk than
the current paused state.

For miners

If your block-10110 submissions are being rejected, please stop your
miner, replace your local chain.json with a fresh copy synced from the
network (the file is read-only chain state and contains no funds), and
restart. I have early evidence this resolves the message-construction
mismatch.

For node operators

Please hold for now. Do not manually edit chain data or force reorgs. I
will publish clear, verified instructions once the analysis is complete.
If you are running a miner or node and can share your current node
version and observed tip height, that information would help — please
reply here or contact me.

The chain is paused, not lost. I will keep this thread updated as the
analysis progresses.

— NeoB

═══════════════════════════════════════════════════════════════════════════
SOST PROTOCOL — POST-INCIDENT REPORT
Chain Stall at Block 10109 → 10110 (2026-05-24 / 2026-05-25)
═══════════════════════════════════════════════════════════════════════════

Posting a transparent after of a 2 h 36 min 55 s chain stall I
caused during a routine seed-node recompile this weekend. Chain is now
fully recovered and producing blocks normally. No data loss, no fork,
no reorg, no funds at risk. This post documents the incident, the
exact root cause, the fix, what action (if any) you need to take, and
the work being done to prevent a recurrence.


───────────────────────────────────────────────────────────────────────────
1. INCIDENT SUMMARY
───────────────────────────────────────────────────────────────────────────

Last good block: #10109 2026-05-24 20:42:55 UTC
First resumed block: #10110 2026-05-24 23:19:45 UTC
Stall duration: 9,410 s (2 h 36 min 55 s)
Pre-incident interval: 461 s (#10108 → #10109, normal at H13)
Total bandwidth lost: ~15 blocks against the 10 min/block target
Funds at risk: NONE
UTXO set integrity: PRESERVED (28,005 entries before and after)
Genesis hash: 6517916b98ab9f807272bf94f89297011dd5512ecea477bd9d692fbafe699f37 (unchanged)
Reorg events: 0
Forks that survived: 0

Active miners during recovery: 10 distinct addresses over the next 200 blocks (network was never single-operator)

Current state (at time of post): tip ~10128, profile H13, 6 P2P peers, block intervals normalising back to target


───────────────────────────────────────────────────────────────────────────
2. WHAT HAPPENED (TIMELINE, ALL TIMES UTC)
───────────────────────────────────────────────────────────────────────────

20:35:14 #10108 mined by sost1269ecd713… (461 s interval, healthy)
20:42:55 #10109 mined by sost1993a8eb82… (last good block)

20:43:23 I stopped sost-node.service on the seed and installed a
freshly compiled sost-node binary built from
main @ 071ebb4c. The binary was visually identical
(--version reported "SOST Node v0.4.0"), and the chain.json
on disk was untouched. Service restarted normally.

20:43:24 sost-node loaded chain.json, reached height=10109, opened
RPC :18232 and P2P :19333, established 6 peers. From the
outside, the node looked healthy.

20:57:?? First miner-submitted candidate for #10110 arrived. Block
was rejected with:

[BLOCK] CX Transcript V2 verified
[BLOCK] REJECTED: SbPoW: BIP-340 Schnorr signature
verification failed for the recomputed message at
height 10110

CX Transcript V2 (the PoW witness) was correctly verified.
The SbPoW Schnorr signature on the candidate did not match
when the node recomputed the preimage. Every subsequent
candidate from every miner failed in the same way.

21:00 — 23:15
The seed misbehaviour-scored and disconnected suspect peers
as it kept rejecting their candidates. Other operators saw
the same behaviour against their nodes (their peers
reported height=10109 too). The network as a whole was
stuck at 10109. P2P kept working — block propagation was
never the failure mode. SbPoW signature verification was.

23:19:45 After diagnostic recompiles and identifying the missing
CMake flag (section 4), I recompiled the seed node with
the correct flag, installed the binary, and restarted the
service. The very next block submitted by the network
validated. Chain resumed at #10110.

23:19 — 00:35
Slingshot had pushed difficulty to the V12 floor during
the stall. Blocks 10110..10123 arrived ~60 s apart as
backlog was cleared. By #10128 difficulty had re-stabilised
at H13 and intervals were back to ~5 min.


───────────────────────────────────────────────────────────────────────────
3. ROOT CAUSE
───────────────────────────────────────────────────────────────────────────

A single missing CMake flag at the recompile step disabled the
Schnorr-signature verification code path in the resulting binary.

The flag in question:

-DSOST_ENABLE_PHASE2_SBPOW=ON

In SOST's CMakeLists.txt this option controls whether the V11
Phase 2 SbPoW signing and verification code (BIP-340 Schnorr over the
preimage SHA-256 of prev_hash | height | commit | nonce | extra_nonce
| miner_pubkey, tagged "SOST/POW-SIG/v11") is compiled into the
binary. Its default is OFF. The recompile command I used was:

cmake -S . -B build-v13-main -DCMAKE_BUILD_TYPE=Release
cmake --build build-v13-main -j$(nproc)

That command produces a binary which:

* loads chain.json correctly (validation of stored blocks does not
re-run on load),
* speaks the P2P protocol normally,
* accepts every other validation rule (PoW transcript, coinbase
structure, difficulty target, timestamp drift, merkle root),
* but cannot verify the Schnorr signature on incoming candidates
because the verification function expects the preimage layout
constructed by the SbPoW-enabled code path, and that code path
is not in the binary.

Every active miner on the network kept building blocks normally. The
miners' binaries (compiled prior to this incident, with the flag ON)
produced valid Phase 2 SbPoW signatures. My seed binary could not
verify them. Because the seed is a primary relay for several
operators, its rejections propagated and the network as a whole
appeared stuck. It was not a fork: it was a verifier compiled with
the wrong code path.

This is verifiable on any binary today:

strings /path/to/sost-node | grep -c 'POW-SIG/v11'
# > 0 → Phase 2 SbPoW code path IS compiled in (healthy)
# = 0 → flag was OFF at compile time (will reproduce this incident
# the moment a Phase 2 block arrives for verification)


───────────────────────────────────────────────────────────────────────────
4. FIX APPLIED
───────────────────────────────────────────────────────────────────────────

The fix was a single recompile of the seed with the flag set and a
service restart:

cd /opt/sost
systemctl stop sost-node
rm -rf build-v13-main # cache had the OFF value
cmake -S . -B build-v13-main \
-DCMAKE_BUILD_TYPE=Release \
-DSOST_ENABLE_PHASE2_SBPOW=ON
cmake --build build-v13-main -j$(nproc)
install -m 0755 build-v13-main/sost-node /opt/sost/build/sost-node
systemctl start sost-node

Post-fix verification I ran (all passed):

md5sum /opt/sost/build/sost-node
→ ce3181d79cecf01f6a13385511fa6399

strings /opt/sost/build/sost-node | grep -c 'POW-SIG/v11'
→ 2

curl ... getinfo
→ "blocks": rising past 10109 again, normal validation

systemctl is-active sost-node
→ active

Nothing in the on-disk state (chain.json, UTXO set, wallet files) was
modified during the incident or the fix. The TAINTED chain.json from
the broken-binary window was preserved as
chain.json.TAINTED-by-broken-binary-20260524_224347 in case forensic
review is needed; the live chain.json is byte-identical to what was
on disk before the recompile.


───────────────────────────────────────────────────────────────────────────
5. WHAT YOU NEED TO DO
───────────────────────────────────────────────────────────────────────────

Three categories. Read the one that applies to you.

CASE A — You are running a node and/or miner that you have NOT
recompiled since 2026-05-22.

Action: NONE.

Your existing binary has Phase 2 SbPoW compiled in (otherwise it
would never have produced or accepted blocks 7100..10109). You
can continue mining and validating with no change. Verify with:

strings /path/to/sost-node | grep -c 'POW-SIG/v11'
strings /path/to/sost-miner | grep -c 'POW-SIG/v11'

Both must print a number > 0. If yours do, you are fine.


CASE B — You recompile from main between now and V13 activation
(block 12,000), for any reason.

Action: REQUIRED. Add the flag to your cmake configure step:

cd /path/to/sost-core
cmake -S . -B build \
-DCMAKE_BUILD_TYPE=Release \
-DSOST_ENABLE_PHASE2_SBPOW=ON
cmake --build build -j$(nproc) sost-node sost-miner sost-cli

Then verify the resulting binaries:

strings build/sost-node | grep -c 'POW-SIG/v11' # > 0
strings build/sost-miner | grep -c 'POW-SIG/v11' # > 0

If either prints 0, you compiled without the flag and your
binary will reproduce my incident the first time it tries to
validate or sign a Phase 2 block. Do not deploy until both
print > 0.

The 'docs/V13_MINER_OPERATOR_CHECKLIST.md' will be updated in
the next push to include this flag explicitly in section A
("Binary"); the current revision in main does NOT mention it and
will be patched.


CASE C — You are getting ready for V13 activation at block 12,000.

Action: STANDARD V13 PROCEDURE applies. Inside the upgrade
window blocks 11,900 → 11,999:

1. Stop your miner.
2. Pull main and recompile per CASE B (with the flag).
3. Confirm NTP is running and your clock drift is < 30 s
(V13 tightens the future-timestamp cap from 60 s to 30 s).
4. Verify your binary also has the V13 hardened preimage code
compiled in:
strings build/sost-node | grep -c 'POW-SIG/v13' # > 0
5. Restart node, then miner.

Do this no later than block 11,990. After block 12,000 any
candidate signed with the V11 preimage layout is rejected by
every V13-aware validator: V13 ships a hardened preimage
(additionally binding timestamp, bits_q, merkle_root, and the
chain's genesis hash). This is height-gated only — the header
version stays at 2 — but the preimage swap is hard at the
block boundary.

Full details: docs/V13_SBPOW_HARDENING.md
Full checklist: docs/V13_MINER_OPERATOR_CHECKLIST.md
V13 spec: docs/V13_SPEC.md


───────────────────────────────────────────────────────────────────────────
6. WHY THIS HAPPENED AND WHETHER IT CAN HAPPEN AGAIN
───────────────────────────────────────────────────────────────────────────

The proximate cause was a missing flag at compile time. The deeper
causes were two:

(a) The CMake default for SOST_ENABLE_PHASE2_SBPOW is OFF. That is
safe for unit testing (faster builds, fewer crypto dependencies
if you only want to compile pure tests) but wrong for a mainnet
deployment binary. A mainnet binary without this flag is a node
that cannot participate in consensus. The default should be ON
for any Release build, or at minimum, the build should refuse to
produce a binary labelled "mainnet" without the flag set.

(b) The V13 miner/operator checklist in docs/ does NOT mention this
flag in the build section. Every operator following the published
procedure verbatim would reproduce my incident the moment they
recompile, regardless of when they do it.

Two patches are being prepared and will land in main shortly:

P0 CMakeLists.txt: change the default to ON, OR make the Release
build refuse to produce a mainnet binary if the flag is OFF
(loud build-time error, not a silent runtime failure).

P1 docs/V13_MINER_OPERATOR_CHECKLIST.md: add the flag to section
A and add a 'strings | grep' verification step alongside the
SHA256SUMS check, so every operator can confirm their binary
is consensus-capable before deploying.

Until both patches are merged, the incident is reproducible by any
operator who recompiles from main without explicitly setting the
flag. After P0+P1, it will not be reproducible from a clean repo
checkout following the documented procedure.

There is no consensus-level defence inside the running protocol that
could have prevented this — the seed binary did exactly what it was
compiled to do, which was reject blocks it could not verify. The
defence has to live at build time, in CMake and in the operator
docs. Both are being addressed.


───────────────────────────────────────────────────────────────────────────
7. CHAIN HEALTH RIGHT NOW
───────────────────────────────────────────────────────────────────────────

Snapshot at time of writing:

tip height ~10128
chainwork delta OK (no orphan branch survived)
UTXO count 28005
casert profile H13 (network producing under target)
mempool empty
P2P peers 6 external + own loopback
active miners 10 distinct addresses over last 200 blocks
(no miner > 50 % share)
blocks since recovery 18+, all accepted, intervals normalising
V13 activation block 12000 → ~1872 blocks remaining
(~13 days at 10 min target)

No further intervention is planned by the seed operator until either
(a) the V13 preparation window opens around block 11,900, or (b) the
P0/P1 patches above land in main, at which point I will recompile and
restart the seed as a normal operational change.


───────────────────────────────────────────────────────────────────────────
8. ACCOUNTABILITY
───────────────────────────────────────────────────────────────────────────

This was an operator error compounded by a documentation gap. I
caused the stall by recompiling without the flag. I am responsible
for the seed node and for the operator documentation that did not
flag the requirement. Both are being fixed in code and in writing.

I would rather have a chain that pauses for two and a half hours
than a chain that accepts blocks it cannot fully verify, so the
behaviour of the binary during the stall — refuse to validate
rather than skip the check — was actually correct, even though the
binary itself was misconfigured. The fix is to make it impossible
to produce a misconfigured "mainnet" binary in the first place.

Thanks to every miner who kept their node and miner running during
the stall — your continued attempts at block 10110 are what
let me confirm the cause once the seed was patched.

If you operate a SOST node or miner and want to confirm your binary
is healthy, run the two strings|grep checks in section 5 and reply
with the result. Anything in the form "X / Y" (where Y > 0) is fine.

— NeoB

═══════════════════════════════════════════════════════════════════
[ANN] SOST — V12.1 hotfix release: SbPoW build-flag safety + miner
log label fix (cosmetic). Action required: optional recompile
at your convenience. Block production unaffected.
═══════════════════════════════════════════════════════════════════

TL;DR
─────
* On 2026-05-24 the mainnet chain stalled for [VERIFICAR DURACIÓN:
calcular desde el timestamp del bloque 10109 al 10110] around
block 10,109 because a fresh miner build was compiled without
the SOST_ENABLE_PHASE2_SBPOW=ON flag, producing blocks that
failed the V11 Phase-2 Schnorr (SbPoW) verification path.
* Chain recovered on its own once a correctly-flagged binary
was relaunched. No reorg, no loss of funds, no consensus rule
changed.
* Two defence-in-depth fixes are now in main:
1. CMake default flipped OFF -> ON so future builds are
consensus-capable by default.
2. Runtime guard in sost-node: if a mainnet binary is started
without SbPoW compiled in, it now exits with FATAL instead
of silently mining unverifiable blocks.
* Separately: a cosmetic bug in the miner's status log printed
"H13" for any cASERT profile from H14 through H35. The miner's
internal profile index (used for the actual dataset, signing
and difficulty target) was always correct — only the operator-
facing label was wrong. Fixed in main.

What happened (block 10,109 stall)
──────────────────────────────────
A node operator rebuilt the V13 binary from main and relaunched.
The default value of the SOST_ENABLE_PHASE2_SBPOW CMake option
was OFF, so the new binary linked the Phase-2 verification stub
instead of the real Schnorr/BIP-340 path that V11 activated at
block 7,100.

The resulting binary could PRODUCE blocks but its peers could
not VERIFY them, because the network had been on Phase-2 SbPoW
for ~3,000 blocks. Block production stalled until a binary
compiled with -DSOST_ENABLE_PHASE2_SBPOW=ON came back online.

Total downtime: [VERIFICAR DURACIÓN — mismo valor que en el TL;DR].
The chain resumed at block 10,110 with no reorg required. No block
was orphaned, no transaction was lost, no consensus rule was
changed by this incident.

Fixes shipped in main (V12.1 hotfix series)
───────────────────────────────────────────
[P0] CMakeLists.txt -- SOST_ENABLE_PHASE2_SBPOW default
changed from OFF to ON. Comment updated to read "REQUIRED
for mainnet consensus". Anyone rebuilding from main now
gets a consensus-capable binary by default; you have to
go out of your way (-DSOST_ENABLE_PHASE2_SBPOW=OFF) to
reproduce the failure mode.

[P1] V13 mainnet operator checklist updated. Pre-deploy step
now explicitly verifies the flag is present in
build/CMakeCache.txt before the binary is allowed to
run against mainnet.

[P1.5] Runtime guard in src/sost-node.cpp -- on startup, if
ACTIVE_PROFILE == MAINNET and the binary does NOT have
the Phase-2 SbPoW verification path compiled in, the
node now prints FATAL and exits with code 2 instead of
continuing to mine unverifiable blocks. This is a
START-UP SAFETY CHECK, not a consensus rule change.

Net effect: it is now substantially harder to repeat the
2026-05-24 incident, even for an operator who rebuilds the
wrong flag by accident.

Cosmetic bug — miner status line says "H13" for H14..H35
─────────────────────────────────────────────────────────
The miner's diagnostic log lines used a static 21-entry name
table (E7..H13) that was correct under the pre-V12 ceiling
H13 but was never extended when V12 raised the ceiling to H20
at block 7,350. Operator-visible symptom:

[MINING] H13 bitsQ=9.754 | <att/s> | stable=...
[LAG-CHECK] Node says H13, mining H13 -> triggering restart
[LAG-ADJUST] Profile changed: H13 -> H13. Restarting search.

Despite what the log says, the miner is mining the CORRECT
profile. The miner uses the integer stab_profile_index for
the SbPoW dataset, the signing message, and the difficulty
target. Only the text rendering of that integer was wrong.
The "H13 -> H13" restart messages are real profile changes
(e.g. H20 -> H19 -> H17) hidden by the same label collapse.

This is COSMETIC. Block production is not affected. Blocks
are accepted normally. Reward distribution is normal. The
difficulty seen on the explorer's main dashboard (which
reads the integer index directly via RPC) is the truthful
value.

Fix in main:
eed7ec95 profile_label() now spans the full E7..H35 range
5efd1f89 inline truncated array in [MINING] status line
replaced with a call to profile_label() so all
diagnostic lines share one source of truth

A related display bug in the explorer's block-detail page
(cASERT_target was hardcoded at H13 and never updated for
V12) is also fixed:
18d95da6 block-detail ceilingH ternary now covers V12
(H20 at 7,350+) and V13 (H35 at 12,000+)

What miners should do
─────────────────────
SHORT VERSION:
- You do NOT need to stop or restart your miner.
- You do NOT need to recompile urgently.
- Pull main and rebuild at your convenience.

LONG VERSION:
- If you rebuilt the miner between block 10,100 and 10,109
on 2026-05-24 from main without explicitly setting
-DSOST_ENABLE_PHASE2_SBPOW=ON, your binary was the wrong
one. Pull main and recompile -- the default is now ON, so
a plain cmake -B build && cmake --build build produces
a consensus-capable binary.
- If your miner log shows "H13" while the explorer's
cASERT panel shows H17 / H18 / H19 / H20 -- it is the
cosmetic bug above. Your mining is correct. Pull main
and recompile only when convenient. Existing binaries
are NOT at risk and do NOT need to be replaced right
now.
- Verification command after recompile (-n 3 because
"H20" is 3 characters and default strings is min-4):

strings -n 3 build/sost-miner | grep -cE '^H[1-3][0-9]$'

Should report ~26 distinct labels (H10..H35).
- V13 hard fork lands at block 12,000. The current chain
is at block ~10,180 at time of writing, so there is a
comfortable window. The V13 pre-activation announcement
(target: block ~11,900) will include the operator
checklist with the runtime SbPoW guard listed as a
pre-flight item.

What this changes for the protocol
──────────────────────────────────
NOTHING. The incident did not require, and the fixes do not
introduce, any consensus rule change. V13 hard-fork rules,
[VERIFICAR: la altura y versión de activación del HTLC atomic-swap.
El ANN original decía "V14 / block 15,000" pero la rama de
desarrollo se llama feat/atomic-swap-htlc-v13-candidate. Confirmar
con el código antes de publicar], cASERT equalizer profiles
and ceilings, Slingshot V12 cascade, dynamic cap, slew rate,
and PoPC contract logic are all unchanged.

V12.1 is a build-system and operator-tooling release. It is
deliberately not a hard fork.

Repo / commits
──────────────
github.com/Neob1844/sost-core/commit/ed72670f (P0: CMake default OFF->ON)
github.com/Neob1844/sost-core/commit/0b3a4fda (P1.5: runtime guard in sost-node)
github.com/Neob1844/sost-core/commit/eed7ec95 (profile_label canonical)
github.com/Neob1844/sost-core/commit/5efd1f89 ([MINING] status uses it)
github.com/Neob1844/sost-core/commit/18d95da6 (explorer block-detail
ceilingH for V12 + V13)

Contact / questions
───────────────────
Telegram (public channel) : t.me/SOSTProtocolOfficial
E-mail : sost@sostcore.com
Website / contact form : sostcore.com