⬢ SOST RESEARCH NOTICE — #40,000 RESEARCH HORIZON
Reward evolution · Decentralization · SOST Asset Market
Research only — NOT consensus — NOT an activation commitment
#30,000 builds the foundation. #40,000 is the current target research horizon for the next coordinated SOST upgrade.
This is not an activation commitment.
Nothing will be scheduled until the required code, tests, external audit, legal/regulatory analysis where applicable, and an explicit public announcement exist.
If the work is not ready, the upgrade simply moves later — for example to #50,000.
1 · REWARD EVOLUTIONThe main scenario currently being researched is:
80% Direct PoW miner reward
15% Normal DTD distribution per block
5% Existing DTD Jackpot pool
The 5% is
not a direct payment to nodes.
It would accumulate inside the existing DTD Jackpot pool. When a jackpot is eventually distributed, the existing eligibility framework — including the relevant node / NODE_BIND requirements — would still apply.
No new supply would be created.All three components would come from the existing block emission.
The current consensus remains unchanged:
The 80 / 15 / 5 model is only a research candidate for a future coordinated hard fork.
2 · DECENTRALIZATIONThe objective is
maximum practical protocol decentralization.
Research and engineering work includes:
- Persistent peer storage
- Independent seeds
- Address gossip
- Autonomous peer discovery
- Automatic recovery from network partitions and competing branches
- More independent nodes
- More independent operators
- Different hosting providers and ASNs
- More geographic distribution
- More independent miners
The objective is that consensus does not depend on SOSTcore infrastructure.
Several of these foundations have already been built and tested in the laboratory, but real decentralization ultimately requires independent operators outside the project itself.
3 · ECONOMIC INFRASTRUCTUREA major research target is to mature the native-asset framework and build the:
SOST ASSET MARKET
Order book · Price discovery · Atomic settlement · Asset Passport
The intended initial state would be:
Technically functional, but developer-gated.There would be no public market access until:
- External security audits
- Legal and regulatory integration
- Asset-classification rules
- Economic-rights definitions
- An explicit decision to open public access
The objective is not simply to create tokens.
The longer-term architecture is:
REAL ASSET / BUSINESS / RIGHT
|
v
ASSET PASSPORT
|
v
ECONOMIC RIGHTS
|
v
REGULATORY CLASSIFICATION
|
v
TOKENIZATION
|
v
SOST ASSET MARKET
|
+-----+-----+
| |
BUY SELL
| |
+-----+-----+
|
v
PRICE DISCOVERY
|
v
ATOMIC SETTLEMENT
|
v
VERIFIED LIFECYCLE
MARKET PRICE IS NOT THE SAME AS ASSET VALUEOne of the most important design principles is:
SOST should not decide what an asset is worth.
The market determines the trading price.
External valuations, audited NAV, financial data and other verified information provide reference values — not an imposed market price.
Consider a tokenized hotel.
ASSET: HOTEL-MURCIA
Supply: 1,000,000 HOTEL
Issue Price: €1.00 per token
One year later, several reference values may exist:
Issuer valuation: €1.70 / token
Independent valuation: €1.85 / token
Audited / calculated NAV: €1.78 / token
Last market trade: €2.32 / token
What is the market price?
€2.32Why?
Because €2.32 is the last price at which a buyer and seller actually agreed to trade.
The other values remain references.
That difference is precisely what makes genuine
price discovery possible.
EXAMPLE — INTERNAL ORDER BOOKImagine that buyers expect the hotel business to grow.
HOTEL-MURCIA / SOST
BUY ORDERS
10,000 HOTEL @ €2.20
20,000 HOTEL @ €2.15
15,000 HOTEL @ €2.10
SELL ORDERS
5,000 HOTEL @ €2.25
12,000 HOTEL @ €2.30
30,000 HOTEL @ €2.50
If somebody accepts the €2.25 sell order:
Later, stronger demand appears:
If matching sellers exist:
Even if the latest independent valuation says:
that does not automatically mean the market is wrong.
The market may be pricing future growth.
The opposite can also happen:
Reference Value: €1.80
Market Price: €1.25
The market may be discounting risk, debt, poor performance, illiquidity or uncertainty.
This is normal market behaviour.
WHAT SHOULD THE SOST ASSET MARKET DISPLAY?The interface should clearly separate four different concepts:
| DATA | WHO / WHAT DETERMINES IT |
| Issue Price | Issuer / initial offering |
| Reference Value / NAV | Valuation, auditor, verified financial data, defined methodology |
| Market Price | Buyers and sellers |
| Economic Rights | Asset Passport + underlying legal documentation |
For example:
HOTEL-MURCIA
Last Price €2.32
24h Change +6.4%
Best Bid €2.30
Best Ask €2.34
24h High €2.45
24h Low €2.08
Volume 187,430 HOTEL
Issue Price €1.00
Reference Value €1.80
Market Premium +28.9%
Indicative Market Cap €2.32 M
Reference Asset Value €1.80 M
And its order book:
ORDER BOOK
SELL
€2.45 10,000
€2.40 8,500
€2.34 5,000
----------------
€2.30 12,000
€2.25 20,000
€2.20 35,000
BUY
REFERENCE VALUE IS NOT "THE TRUE PRICE"SOST should never publish a single number and claim:
"This is the true value of the asset."
Instead, the system may display multiple reference sources:
REFERENCE DATA
Issuer valuation: €1.72
Independent valuation: €1.84
Audited NAV calculation: €1.79
Last verified market trade: €2.31
The platform could eventually calculate a transparent reference composite, for example:
Independent valuation 50%
Audited NAV 30%
Verified financial data 20%
But it should still be labelled something such as:
Reference Estimate—not:
True PriceA core principle of the proposed market is:
SOST does not determine fair value.
SOST provides the infrastructure, verifiable information and market mechanisms through which buyers and sellers determine the trading price.
SPECULATION IS PART OF PRICE DISCOVERYA participant may believe:
"The hotel may be worth €1.8 million today, but I believe it could be worth €5 million in three years."
That participant may therefore be willing to pay:
€2.40 per token.Another participant may believe the asset is overvalued and sell.
That disagreement is exactly what creates a market.
The SOST protocol should not manipulate that price.
Its role is to provide:
MARKET
+
RULES
+
ORDERS
+
SETTLEMENT
+
DATA
+
TRANSPARENCY
and allow participants to form prices.
FUNDAMENTALS · MARKET · EXPECTATIONSA mature SOST Asset Market could separate information into three areas:
FUNDAMENTALS
Independent valuation
Revenue
Debt
Cash
Reserves
NAV
MARKET
Last price
Best bid
Best ask
Volume
Market capitalization
EXPECTATIONS
Premium / discount vs NAV
Price change
Historical chart
Market activity
This would allow speculation while keeping fundamental information visible.
That distinction is important.
A serious asset market is not simply:
"Create a token and hope the price goes up."
It should provide structured information about the underlying asset, its rights, its reference data and its market activity.
ASSET PASSPORT INTEGRATIONThe Asset Passport is intended to describe what the token actually represents.
For example:
ASSET:
HOTEL-MURCIA
Economic Rights:
Revenue Share
Initial Supply:
1,000,000 HOTEL
Issue Price:
€1.00
Reference Valuation:
External / independently sourced
Regulatory Classification:
Pending / Restricted
Transferability:
Defined by asset policy
Possible Economic Rights may eventually include:
Equity / participation
Revenue share
Debt / credit
Redemption right
Usage right
Ownership claim
No economic claim
This distinction matters.
A token that represents an economic participation in a business is fundamentally different from a token that only gives a hotel-room discount.
If the business increases in value, a utility token does not automatically acquire ownership rights in that value.
The Asset Passport is therefore expected to make those rights explicit.
IMPORTANT: SOST NATIVE COINThe native SOST coin has no burn mechanism and no SOST burn mechanism is planned.
Asset-level cancellation, redemption, retirement or ASSET_BURN applies only to separately issued native assets where their lifecycle rules require it.
It never burns SOST.SOST COIN
Burn: NO
Fee burn: NO
Supply destruction: NO
NATIVE ASSETS
Asset retirement/cancellation: possible where explicitly defined
Effect on SOST supply: NONE
CURRENT STATUSCurrent consensus remains:
The #40,000 roadmap described above is
research only.
It is not activated consensus.
It is not a promise that a hard fork will occur at exactly #40,000.
Every consensus-changing component would require:
- Completed implementation
- Extensive regression testing
- Security testing
- External review / audit where required
- Network compatibility analysis
- A coordinated hard-fork plan
- A separate public announcement
If those requirements are not satisfied by #40,000, the work moves to a later coordinated activation height.
#30,000 = FOUNDATION
#40,000 = CURRENT RESEARCH HORIZON
Security and correctness take priority over a block-height target.
⚠⚠⚠ MANDATORY UPDATE — ALL NODES AND ALL MINERS ⚠⚠⚠
SOST V30000 FINAL SECURITY BUILD
RECOMPILE (OR DOWNLOAD AND VERIFY) THE NEW sost-node + sost-miner + sost-cli
AND RESTART YOUR NODE AND YOUR MINER AFTER BLOCK #29,900 AND BEFORE BLOCK #30,000
OTHERWISE THERE IS A REAL DANGER OF A CHAIN SPLIT, AND THE NEW PROTOCOL CHANGES WILL NOT APPLY TO YOUR NODE OR MINER.
WHYA final pre-activation security review of V30000 found and fixed several problems:
- how transactions are admitted to the mempool;
- native-asset validation;
- peer recovery after a chain split;
- NODE_BIND ownership.
The NODE_BIND fix is a consensus rule that activates at #30,000. From that block a NODE_BIND must be signed by
both the mining key
and the node key.
A node or miner still running an older binary will
reject or accept different blocks from the first NODE_BIND onwards.
That is a chain split.SUPERSEDED — DO NOT RUN THESE AT #30,000:- the original v30000 release;
- v30000-rc1;
- any intermediate emergency build;
- any v16.x build.
THE ONLY VALID BINARIES — VERIFY ALL THREEV30000 FINAL SECURITY BUILD — tag v30000-final — commit 3acd952bd2c321fe9c6cb276259ff712d6b466bb
ef608cf9e7f6434f8d60b29c3287ca7045cb83de1be1ddf585a9176bf45b39cd sost-node
53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75 sost-miner
09d9a5022b3c03dfbe85df1ea728f931f5287712739921e17138e89dad14f62b sost-cli
Release:
https://github.com/Neob1844/sost-core/releases/tag/v30000-finalFull guide:
https://sostcore.com/sost-upgrade.html
WHEN- NOW — you can already recompile or download the FINAL binaries and verify their SHA256 (steps below).
- #29,900 → #30,000 — MANDATORY: restart your node and your miner on the FINAL binaries, and keep them running through #30,000.
- #30,000 — activation happens automatically by block height. Nothing is restarted at #30,000 itself; you must already be running the FINAL binaries.
OPTION A — RECOMPILE FROM SOURCE (Ubuntu / Debian / WSL2)Verified today: a clean clone of the tag, built exactly like this, reproduces the three official hashes byte-for-byte (Ubuntu 22.04, gcc 11.4).
# 1. build dependencies (once)
sudo apt update
sudo apt install -y build-essential cmake git libssl-dev libsecp256k1-dev
# 2. get the FINAL source
git clone https://github.com/Neob1844/sost-core.git sost-v30000-final
cd sost-v30000-final
git checkout v30000-final
git log -1 --format=%H # must print 3acd952bd2c321fe9c6cb276259ff712d6b466bb
# 3. build — the build directory MUST be named "build"
cmake -S . -B build -DSOST_ENABLE_PHASE2_SBPOW=ON -DSOST_TESTNET_FORKS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target sost-node sost-miner sost-cli -j"$(nproc)"
# 4. verify
sha256sum build/sost-node build/sost-miner build/sost-cli
# ef608cf9e7f6434f8d60b29c3287ca7045cb83de1be1ddf585a9176bf45b39cd build/sost-node
# 53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75 build/sost-miner
# 09d9a5022b3c03dfbe85df1ea728f931f5287712739921e17138e89dad14f62b build/sost-cli
- Your compiler or libraries differ from the reference build. Use Option B (official binaries) instead.
- Never run a binary whose hash you cannot match against the list above.
OPTION B — DOWNLOAD THE OFFICIAL BINARIESmkdir sost-v30000-final && cd sost-v30000-final
for f in sost-node sost-miner sost-cli SHA256SUMS; do
wget -q https://github.com/Neob1844/sost-core/releases/download/v30000-final/$f
done
sha256sum -c SHA256SUMS # all three MUST print: OK
chmod +x sost-node sost-miner sost-cli
RESTART YOUR NODE ON THE NEW sost-node — between #29,900 and #30,000# --- if you run the node with systemd ---
sudo systemctl stop sost-node
sudo cp /path/to/your/sost-node /path/to/your/sost-node.bak-before-final # rollback copy
sudo install -m 0755 build/sost-node /path/to/your/sost-node # (Option B: ./sost-node)
sha256sum /path/to/your/sost-node # ef608cf9e7f6434f...
sudo systemctl start sost-node
# --- if you run the node by hand: stop it (Ctrl+C), then start the NEW binary with your usual flags ---
./sost-node --genesis genesis_block.json --chain chain.json \
--rpc-user <your-user> --rpc-pass-file ~/.sost/rpc.pass \
--profile mainnet --p2p-enc on
# --- check it is up, on the chain, with peers ---
curl -s -u <your-user>:$(cat ~/.sost/rpc.pass) -H 'content-type: application/json' \
--data '{"method":"getblockcount","params":[],"id":1}' http://127.0.0.1:18232/
curl -s -u <your-user>:$(cat ~/.sost/rpc.pass) -H 'content-type: application/json' \
--data '{"method":"getpeerinfo","params":[],"id":1}' http://127.0.0.1:18232/
Your chain data is kept. There is no resync and no reindex.
RESTART YOUR MINER ON THE NEW sost-miner — between #29,900 and #30,000# stop the old miner (Ctrl+C in its terminal, or kill its PID — never a broad pkill on a shared box)
sha256sum build/sost-miner # 53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75
./build/sost-miner \
--wallet ~/sost-keys/my-wallet.json \
--mining-key-label "my-mining-key" \
--genesis genesis_block.json \
--rpc 127.0.0.1:18232 \
--rpc-user <your-user> \
--rpc-pass-file ~/.sost/rpc.pass \
--blocks 999999 --max-nonce 500000 \
--profile mainnet --realtime --threads <N>
- --realtime is mandatory. Without it every block you find is rejected ("timestamp too far in future").
- The miner is working correctly if you see:
- bitsQ sync ... node canonical=...
- [MINING] h=<current height + 1>
- when you find a block: [BLOCK N] ... submitted to node OK
[/list]
NODE_BIND — READ THIS- DO NOT SUBMIT A NODE_BIND YET. Wait for the explicit go-ahead on sostcore.com and in this thread. A bind mined while a major miner still runs an old build would split the chain.
- When it is announced, use the FINAL sost-cli. The command is unchanged; it now signs with both keys:
./build/sost-cli --wallet ~/sost-keys/my-wallet.json --mining-key-label "my-mining-key" createnodebind 1 --node-key-file ~/.sost/node.key
- After it confirms, check two things:
- the registered owner is your mining address;
- your heartbeats follow it.
- NODE_BIND affects Jackpot eligibility only. It gives nobody access to your wallet, and it cannot create, spend or burn SOST.
WHAT DOES NOT CHANGE- Monetary rule: 50% miner / 50% DTD — unchanged.
- SOST burn: NONE. SOST has no burn mechanism — not supported, not planned.
- Native Assets: DEFERRED / FAIL-CLOSED on mainnet.
- SACS V2: DEFERRED on mainnet.
- Activation: automatic at #30,000 by block height. First DTD Jackpot V2 draw at #30,186.
UPDATE NOW. VERIFY THE THREE HASHES.
RESTART NODE + MINER ON V30000 FINAL BETWEEN #29,900 AND #30,000.
OLD BINARY AT #30,000 = DANGER OF CHAIN SPLIT.
