Vostokzyf, I am going to answer without a script. I have spent several nights thinking about this reply and I prefer to tell you how it is rather than invent a
corporate calendar I cannot keep.
Where we actually are today
Peak active miner count: ~39. Miners updated to the latest binary (post-SbPoW + V12): roughly 7. That drop is on me and I am not going to dress it up — it is the direct
cost of choosing to close the consensus pieces before closing the commercial side. I have preferred to ship the changes the protocol needs and accept that some miners
temporarily step away, rather than freeze the design today with pieces I know are not final. What I do commit to (post #131): zero consensus changes for at least 30
days after V12, and every future hardfork announced ≥30 days in advance, with banner in node and explorer and a min_commit field so miners on an outdated binary see the warning automatically. This post is that ≥30-day notice for V13.
SbPoW — honest review
Since SbPoW is the piece that has caused the most friction, it deserves a serious explanation. What it does: from block 7,100 onwards, every block header must carry a
miner_pubkey (33 B secp256k1 compressed) and a miner_signature (64 B Schnorr BIP-340) over a domain-separated message that includes prev_hash, height, the ConvergenceX
commit, nonce, extra_nonce and the pubkey itself. The miner coinbase output (50% of the subsidy) must pay to the address derived from that same pubkey. The ConvergenceX
seed (seed_v11) also includes the pubkey, so changing keys forces a full re-run of the 100,000 rounds.
REAL ADVANTAGES
+ Post-hoc coinbase relabeling is impossible.
+ PoW bound to identity (pool topologies that delegated work
without sharing the key are no longer viable — by design).
+ Non-replayable: signature tied to height, nonce, commit, pubkey.
+ Schnorr BIP-340 over libsecp256k1, ~12 ms per verify.
+ Hard validator reject on malformed pubkey, invalid signature,
or coinbase address mismatch.
+ Enables signed Trinity capsules, legitimate DTD lottery, and
the path to PoPC bonds with cryptographic proof.
REAL DOWNSIDES
- The wallet file must live on the mining host; key custody is
the operator's responsibility.
- Pool topologies without delegated custody stop working
(threshold signatures are a future topic, not urgent at the
current network size).
- Key rotation restarts the 100k rounds — no cheap rotation.
- Header grew from 96 B to 193 B (+97 B).
- Migration friction: any miner still using --address is
hard-rejected post-7,100 — part of the 29 → 7 gap is this.
Honest conclusion: SbPoW does what it is supposed to do, and the costs are operational, not cryptographic. If you stepped away because of the friction of migrating to
--wallet --mining-key-label, come back when you can — the upgrade is awkward the first time and routine after that.
V13 at block 12,000 — full list
Important notice: V13 has grown from a small three-item fork into a major fork that activates the original value proposition of the project. I am stating that clearly
because the community deserves to know it in good time. Complete list:
1. PoPC MODEL A + B — TARGET V13 (BLOCK 12,000), FALLBACK V14 (BLOCK 15,000)
This is the big change. Proof-of-Personal-Custody moves from
"designed but inactive" to live in consensus. Both models:
- Model A (passive custody): epoch-based audits, balance
checks on tokenized gold custody, automatic slash after
grace period.
- Model B (active cycle): transfer, reward-right split,
beneficiary handoff, auto-withdraw, reward settlement,
bond release.
The Gold Funding Vault stops being passive accumulation and
enters the distribution cycle governed by PoPC contracts.
This is the pillar that separates SOST from any PoW clone:
the moment the gold reserve starts speaking to holders.
HONEST STATUS OF PoPC (operator transparency).
The DESIGN and the per-component CODE are finalised and
pass unit tests: registry (states ACTIVE / COMPLETED /
SLASHED / EXPIRED), reward + reputation calculation, TX
builders (BOND_LOCK / ESCROW_LOCK), RPC handlers
(popc_register / popc_status / popc_check / popc_release /
popc_slash), SOSTEscrow.sol contract with 47 Solidity
tests, Python Etherscan checker for manual balance
verification. 31 PoPC registry unit tests + 12 TX builder
tests pass.
What is NOT yet 100% operational for fully-automatic
activation at block 12,000:
a) Audit daemon. The primitives compute_audit_seed and
is_audit_triggered exist in src/popc.cpp, but no
thread or systemd service periodically invokes them
in production. Audits would not fire on their own.
b) Auto-slash on audit failure. popc_slash is callable
via RPC but is not yet wired to fire automatically
when an audit fails.
c) Auto-settlement of reward + bond release. popc_release
is callable via RPC but the auto-distribute script is
not yet installed on a production cron.
d) Model B Ethereum side. SOSTEscrow.sol is written and
locally tested but is not yet deployed to Sepolia or
mainnet. The deployment checklist in contracts/
SECURITY.md has zero items completed. Without the
contract live, Model B cannot accept deposits.
e) Ethereum event listener. No daemon currently watches
for GoldDeposited events to call escrow_register on
the SOST side. The roadmap in
docs/popc_model_b_roadmap.md asks for it explicitly.
f) Consensus-level activation gate. There is no
POPC_ACTIVATION_HEIGHT constant. BOND_ACTIVATION_
HEIGHT_MAINNET = 10000 only unlocks the TX types; it
does not start the automated lifecycle.
g) End-to-end automated lifecycle test that runs
"register → mature → audit → slash-or-settle → close"
without any human RPC call. Unit tests cover the
pieces; the integration test for the full automatic
loop does not yet exist.
On technical and operational grounds I therefore reserve
the right to defer PoPC activation to V14 at block 15,000
if any of (a)–(g) is not 100% production-ready by the V13
binary cut. I will not ship a half-validated PoPC into
consensus. The next three weeks before V13 are dedicated
to closing those gaps and running the missing end-to-end
test. If they all close, PoPC ships at block 12,000. If
any remains open, the slip is announced from this thread
the moment the decision is made, and PoPC ships at V14
instead. The other V13 items below do NOT depend on PoPC
and ship on schedule at block 12,000 regardless.
2. ALL cASERT EQUALIZER PROFILES ACTIVATED [CONFIRMED]
The ceiling today is H13 (21 of 43 profiles active: E7-H13).
After V13, the full 43 profiles E7-H35 become available to
absorb any hashrate scenario. This formally closes the
equalizer calibration started in V6, and lets the protocol
self-adjust to any future network size without further
calibration forks.
3. DTD LOTTERY COOLDOWN: 5 → 6 BLOCKS [CONFIRMED]
Determinism under the 1-of-3 permanent cadence (full audit
in docs/V13_COOLDOWN_AUDIT.md). Only meaningful if the
lottery is still active after the block 12,100 decision —
see below.
4. FUTURE TIMESTAMP DRIFT CAP: 60 s → 10 s [CONFIRMED]
Pre-V13 a miner could place the candidate's timestamp up to
60 s ahead of wall-clock. Post-V13, 10 s. HARD CONSEQUENCE:
synchronized NTP is MANDATORY for mining post-V13. If your
host is more than 10 s ahead, blocks will be rejected.
Anyone who tolerated a misconfigured clock before, will
not anymore.
5. BEACON PHASE II-A [CONFIRMED]
The node reads locally-signed notices from notices.json
(file-local, no P2P, no HTTP). Verification against a
hardcoded secp256k1 pubkey. It MAY inform; it MAY NOT
restart, MAY NOT block, MAY NOT change consensus, MAY NOT
execute commands. (Full Beacon protocol detail in the
appendix at the end of this post.)
6. BEACON PHASE II-B [TARGET V13, FALLBACK V15]
Extension of Phase II-A. Design candidates:
- Notice expiration by absolute height (a notice with
expires_at_height: N is silently dropped after that
height — no stale criticals).
- Threshold N-of-M signature on critical notices: a
single key cannot publish "V14 hardfork tomorrow"; M
independent keys must agree, N must sign. Single-key
compromise no longer compromises the critical channel.
- Second publication channel (mirror): the node tries
a primary path, falls back to a verified secondary if
the first is unavailable. Removes the single-point-of-
failure of one notices.json file.
- Optional revocation: a signed revocation notice with
the same notice_id silently retires a prior notice
without restarting nodes.
- Severity levels (info, warn, critical) that the miner
banner colour-codes in stderr.
Ships in V13 IF the design closes on time and the test
surface is green by the V13 binary cut. If not, it slides
to V14 at block 15,000. Does NOT block the rest of V13.
7. BEACON PHASE III [TARGET V13, FALLBACK V14]
Previously documented as "dormant at INT64_MAX". Bringing
it forward as a V13/V15 candidate. What it adds: P2P
gossip of verified notices among nodes. Today every node
must reach the operator-published notices.json file
independently (Phase II-A). With Phase III, the first
node that fetches and verifies a notice relays it to its
peers; a critical update propagates across the network in
seconds rather than relying on every operator polling on
their own schedule.
Anti-spam: only notices that verify against the hardcoded
pubkey (or the threshold set from II-B if II-B is active)
are relayed; everything else is dropped at the receive
side without scoring or banning the peer.
Constraints unchanged from II-A: MAY inform, MAY NOT
restart, MAY NOT block, MAY NOT change consensus, MAY NOT
execute commands. Phase III only changes the TRANSPORT
layer, not the privilege model.
Ships in V13 IF design + tests close in time, else V15.
8. MEMORY-LOCK PER-INSTANCE [TARGET V13, FALLBACK V14 — ANTI-POOL]
Documented in docs/V11_SPEC.md as "earliest activation, if
it ever ships, is block 12,000+ after independent
simulation". Would force the 4 GB ConvergenceX dataset to
be per-thread rather than shared across threads. Effect:
a rig with 16 threads would lose proportional advantage
over 16 separate solo miners — raw hashrate concentration
becomes mathematically penalised, not just masked.
This is the project's only anti-pool mechanism besides
SbPoW (SbPoW attacks the problem from cryptographic
identity; Memory-Lock attacks it from physical RAM).
Status: pending independent simulation. If the simulation
confirms it does not break legitimate small miners at the
8 GB RAM floor, it ships in V13. If it would require
raising the memory requirement, it slides to V14.
V14 at block 15,000 — proposed final hardfork (not guaranteed)
A few items now point at block 15,000 rather than V13: PoPC Model A + B if the operator-side reservation fires, Beacon Phase II-B and Phase III if either design does
not close in the V13 window, and Memory-Lock per-instance if its simulation does not complete in time. I want to be clear about what V14 is and is not.
V14 is the proposed final hardfork of the SOST protocol. "Final" means: after V15, no further consensus changes are planned. All evolution beyond that point lives in
non-consensus surfaces — release packaging, wallet UX, dashboard features, off-chain tooling, Trinity research. The base protocol freezes.
V14 is not guaranteed. If every V13 candidate ships cleanly at block 12,000, V14 may not be needed at all and 12,000 itself becomes the closing fork. If the V13
candidates defer, V15 carries the remainders and then closes the chapter. Either way, the commitment is the same: no fork after V15. If something genuinely critical
surfaces later (a provable consensus flaw, a security incident that requires hard mitigation), that would override the commitment — but that is the bar, not feature
requests.
The reason for framing V14 this way is honesty about how this project will mature. A protocol that needs continuous hardforks to function is not finished. SOST has
earned the right to declare its consensus base finished, and V14 is where that line is drawn. Everything after that has to fit inside the rules the protocol already
has, or live outside consensus.
Open decision at block 12,100 — DTD lottery: keep or remove
The DTD lottery was not in the original SOST design. The system was planned for extra-coinbase rewards to flow through two channels: PoPC contracts (Gold Vault +
proof-of-personal-custody) and Useful Compute (when the task families become scientifically defensible). The lottery was added in V11 Phase 2 as a redistribution
mechanism while those two channels reached production.
When PoPC is activated (either at V13 or at V14 if the reservation fires), the situation changes: the original path starts to actually work. At height 12,100 — ~100
blocks after V13 has stabilised — I will formally open the decision in this thread:
OPTION A — Keep the DTD lottery at 1-of-3 blocks permanent
Cooldown stays at 6 blocks (V13). Continues as supplementary
redistribution, IN PARALLEL with PoPC once PoPC is live.
OPTION B — Disable the DTD lottery
The protocol returns to a clean 50/25/25 split on every block.
Extra-coinbase rewards stay on the original path: PoPC
contracts + Useful Compute (when it activates). Once PoPC
is live, this is no longer a gap.
My personal position has shifted slightly: before V13 I was neutral with a bias to keep it; with PoPC moving into production (either V13 or V14), the bias moves closer
to true neutral. The lottery served its purpose while PoPC was not yet live, and disabling it once PoPC is live is consistent with the original design. But the decision
must be taken with input from active nodes and miners, not in solitude.
About the "Public Launch" on June 16 — what it means and what it does not
The site displays a countdown to "Official Public Launch — June 16, 2026". I want to clarify what that date means and what it does not, because I do not want anyone
arriving expecting a market event.
June 16 is: official end of the Infrastructure Test Phase. v1.0 binaries published, anyone can mine and use SOST without restriction, and the project stops
self-describing as "pre-market stress test". What it does not mean: it does not mean there is an exchange listing that day, it does not mean a liquid spot market
appears, it does not mean there is an official price. The difference this time is that it does line up with a substantive change: V13 lands roughly in that same window
(12,000 − 7,700 = 4,300 blocks × 10 min ≈ 30 days). The real market launch arrives when there is a real buyer on a real exchange; what June 16 does mark is that the
protocol exits its infrastructure-test posture and the v1.0 narrative is complete in code, with the value proposition (CPU PoW + gold reserve + PoPC) live in production
either at V13 or, if the reservation fires, at V14.
Cooperative nature of the project
I need to say this clearly: SOST is a cooperative project. There is no venture capital behind it, there is no large team with self-funded capital, there is no premined
treasury for paid marketing campaigns. The project is worth what the people who join it decide it is worth — miners who contribute CPU, holders who self-custody, nodes
that validate, people who read this thread and contribute tests, bugs and honest criticism. It is not a slogan, it is the structural reality.
That means success or failure depends in large measure on real adherence from people who understand what it is and choose to participate. If the community believes in
the proposal (CPU PoW + gold reserve + PoPC) and sustains it, there is a basis to grow organically. If the community decides it is not interested, no paid marketing can
compensate for that, and the right thing would be to accept it. What I have is transparency, reproducible open-source code, and a willingness to answer in this thread
as many times as it takes.
Exchange outreach, concretely
The marketing and promotion question deserves numbers, not slogans. The segment of small exchanges that historically listed CPU coins has shrunk: TradeOgre no longer
exists, neither does TradeSatoshi, neither does Cryptopia. The map today is narrower than two years ago. Realistic candidates for SOST are:
- NonKYC.io: exact audience (Monero / Wownero / Salvium miners),
historically low or zero listing fee, no KYC.
- XeggeX: similar model, small-cap listings.
- Exbitron / SafeTrade: smaller alternatives in the same niche.
Each one requires prior verification: that they are still
operational, that withdrawals currently work, that recent
listings are not graveyards. That verification I do before
committing to anything.
What I will NOT do: pay five figures to a tier-3 CEX (MEXC, Gate, Bitget) that charges a listing fee, does not guarantee volume, and sometimes lists coins that die on
screen. Without pre-market capital for marketing, that path is burning the only cartridge available in exchange for a ticker nobody buys.
To any exchange I speak with, the first message will be:
"Without regulatory compliance in the jurisdictions where the
user operates, there is no real acceptance. Without live PoPC
contracts, the value proposition is incomplete. A listing
without those two pieces is just a ticker on a screen — it
does not serve the exchange, the holder, or the project."
When PoPC activates (V13 or V14), the second condition moves from "pending" to "active". That unlocks conversations that today still do not make sense to have. In the
meantime, the SOST DEX (alpha) remains the official venue; I am going to push it harder as the primary route until an external CEX enters.
Community channels — what is missing
- Official Telegram channel: I open it this week. The CPU
altcoin audience lives on Telegram and not having a channel
has been a mistake. Announced from this thread first to
block impersonators.
- Official X/Twitter account: I create it even if initially
inactive — blocks impersonators and reserves the handle.
- Android app: under Google Play review. In the meantime,
direct APK on sostcore.com for those comfortable sideloading.
- Discord: remains deprioritised. Fragmenting attention does
not help.
Trinity — why I keep it out of the pitch
Trinity (GeaSpirit + Materials Engine + Useful Compute, orchestrated by the private AI Engine) is research-stage infrastructure. Final vision: autonomous operation
under the AI Engine — the AI runs missions across the three verticals, and when it finds something with demonstrable scientific or economic value, that result is
registered on-chain via a SOST tx (the chain acts as a notary, not as the computer that produced the result) and monetised if a path exists.
It is not a user-facing system today and I deliberately keep it outside the value proposition until it is proven and producing reproducible results. The only thing the
user will be able to do directly, when the time comes, is earn rewards by lending part of their CPU to genuinely useful workloads — primarily computational discovery of
new materials, and (less frequently, when the AI Engine deems it worthwhile) GeaSpirit prospectivity scans in previously unanalysed zones. Useful Compute rewards
remain postponed (post #133). The real headline stays: CPU PoW + gold reserve + PoPC — and once V13 or V14 activates PoPC, all three pillars are in production. Trinity
sits alongside as an R&D track that may or may not graduate.
Bottom line — no dressing
- V13 at block 12,000 is the major fork: activates all 43
cASERT equalizer profiles, ships the lottery cooldown 5→6
and drift cap 60s→10s (NTP mandatory), introduces Beacon
Phase II-A. Confirmed for block 12,000.
- PoPC Model A + B is TARGET V13, FALLBACK V14. Design and
per-component code are tested; the operational
orchestration layer (audit daemon, Ethereum event listener,
mainnet deploy of the Escrow contract, automated lifecycle
test) is the gating work over the next ~3 weeks. If any
piece slips, PoPC ships at V14.
- Beacon Phase II-B, Beacon Phase III, and Memory-Lock
per-instance are all TARGET V13, FALLBACK V14. None blocks
the rest of V13.
- V14 at block 15,000 is the PROPOSED FINAL HARDFORK, NOT
GUARANTEED. If everything fits cleanly at V13, V14 is not
needed. If anything defers, V14 catches it and closes the
consensus-evolution chapter. After V14, no further
hardforks are planned.
- Memory-Lock per-instance would be the project's second
anti-pool mechanism besides SbPoW — hashrate concentration
penalised via physical RAM instead of cryptographic
identity.
- Cooperative project, no venture capital, no pre-marketing
treasury. Value depends on real community adherence.
- A single developer with external technical advisors. Bus
factor mitigated by open-source reproducible code, not by
team size.
- No external audit by a recognised firm. Hundreds of internal
tests exist. Not the same thing and I know it.
- June 16 = v1.0 General Availability + end of Infrastructure
Test Phase, aligned with the V13 window. NOT the day a
market appears.
- First realistic listing will be on a CPU-niche platform
(NonKYC / XeggeX / similar) if they are operational —
never paying tier-3+ fees with capital the project does
not have.
- At block 12,100 I will open the DTD lottery decision (keep
1-of-3 or disable).
- Trinity stays out of the pitch until it produces real
results.
As I say in every announcement: this project may work or it may not. Competition in the sector is enormous, there are regulatory frameworks to meet, and the final
decision of exchanges and the community is not mine to make. What I can control is being honest about where we are and not selling expectations I cannot back up.
If anyone reads this and decides to keep mining or testing the code knowing all of this, thank you for the trust. If anyone reads this and decides this is not the
moment, I understand perfectly and there is no resentment.
— NeoB
---
APPENDIX — Beacon Protocol full detail of the three phases
Beacon is the on-protocol-but-not-on-consensus channel for operator-signed advisory notices to miners and node operators. It exists because critical communication
("update before block N", "known issue with binary X") should be reachable from inside the node software itself, not only from BitcoinTalk, Telegram or X — three
channels that can fragment, get censored, or be impersonated.
The three phases share five hard guarantees that the validator enforces and the static safety lint refuses to let me weaken:
- MAY inform an operator
- MAY NOT restart a node or miner
- MAY NOT block any block or transaction
- MAY NOT change consensus rules
- MAY NOT execute commands on the host
Beacon is a loudspeaker, not a remote control. It publishes verifiable news; the reader decides what to do.
PHASE II-A (V13 confirmed)
Transport: file-local. The node reads notices from
<datadir>/notices.json. No P2P, no HTTP fetch from C++.
Verification: secp256k1 BIP-340 Schnorr signature against
a single hardcoded public key compiled into the node and
miner binaries (the operator-side key, generated and
stored separately from any wallet key — separation of
roles, like Bitcoin Core's release keys).
Notice shape: notice_id, type (info | warn | critical),
activation_height, expires_at_height (optional), title,
body (≤280 chars), signature.
Miner UX: at startup and on RPC poll, the miner prints
a coloured banner to stderr with the active notices.
Distribution: published from sostcore.com/api/notices.json
and mirrored on GitHub raw. Operators copy the file into
their datadir manually, or fetch it via their own cron.
Network surface from the node: ZERO.
PHASE II-B (V13 if ready, else V14)
Adds five capabilities to Phase II-A, all backwards-
compatible with II-A binaries (II-A nodes simply ignore
the new fields):
1. Notice expiration by absolute height. expires_at_height
causes the notice to disappear from the active set at
exactly that height. Prevents stale criticals from
polluting the UI.
2. N-of-M threshold signatures on critical notices. The
critical channel becomes multi-sig: even if one key
leaks, the attacker cannot publish a fake "V14 fork
tomorrow" alone. M independent keys, N must sign,
verified at parse time.
3. Second publication channel (mirror). The node tries
primary, falls back to a verified secondary. No single
point of failure on the publish side.
4. Optional revocation. A signed revocation notice with
the same notice_id silently retires the original. No
restart, no consensus impact, just disappears from the
UI.
5. Severity levels (info | warn | critical) reflected in
the miner banner colour and stderr prefix.
PHASE III (V13 if ready, else V14)
Transport upgrade: nodes gossip verified notices to each
other over the existing P2P transport. Today every node
must obtain notices.json on its own; with Phase III, the
first node that verifies a notice relays it to its peers.
Critical updates reach the entire network in seconds
rather than on whatever schedule each operator happens
to keep.
Anti-spam: only notices that verify against the hardcoded
pubkey (or the II-B threshold set if active) are relayed.
Anything that fails verification is dropped silently,
without scoring or banning the peer — so a hostile peer
flooding garbage cannot DoS the network or cause peer-ban
cascades.
Per-notice bandwidth: under 1 KB. Per-node memory:
bounded ring buffer of the last 100 notice_ids to dedup
gossip. No persistence across restarts.
Privacy: the node never has to know or expose the URL of
the operator publication channel. The gossip layer IS
the channel.
Critically, Phase III only changes the TRANSPORT of
notices. The privilege model from II-A is preserved bit
for bit: a Phase III notice still cannot restart, block,
change consensus, or execute commands. The gossip layer
earns notices a faster path through the network — nothing
else.
WHAT NONE OF THE PHASES DO
- No automatic node restart on receipt of a notice.
- No "hardfork at height N" trigger that activates
consensus changes without an operator's prior binary
rebuild and restart.
- No way for a leaked single key to forge a critical
notice once II-B is active.
- No persistence to disk of relayed notices beyond what
the operator chooses to write.
In short: Beacon is the protocol's loudspeaker. Not its remote control.
— NeoB
APPENDIX — Gold Vault 90% supermajority decentralization
(target V13 / fallback V14)
Background. From genesis every block has hard-allocated 25% of
its coinbase to the Gold Vault address. That part has always
been consensus-enforced: every node rejects a block whose
coinbase doesn't pay the 50/25/25 split. The *accumulation*
side is solved.
What was never wired in at consensus level is the *spending*
side. Until that lands, the only thing standing between the
vault and a hostile spend is operational key custody by a
single person (NeoB). That is openly disclosed and not the
target architecture. The original commitment in the ANN at
https://bitcointalk.org/index.php?topic=5579432 and in
docs/convergencex_whitepaper.txt was to flip vault custody
from developer to protocol at V6 / block 10,000 under the
5-defense Gold Vault model. The chain has passed block 10,000
without that landing. V13 / block 12,000 is the next
coordinated hard fork that can land it; V14 / block 15,000 is
the explicit fallback if any of the five defenses are not
ready by the V13 release candidate.
The five constitutional defenses, all of which MUST hold
simultaneously for any vault spend to be valid:
1. Purpose restriction. The vault must be able to change
form (e.g. SOST -> XAUT/PAXG -> physical attestation),
but never purpose. The destination of any spend is
constrained at consensus level to a small set of
reserve-purpose addresses. The vault can never be drained
to "fund operations", "pay the team", or "buy non-gold
assets". Even a 100% colluding miner cabal cannot vote
this away — the whitelists are enforced at the validator
level, not at the signaling level.
2. Dual destination whitelists. The set of legal spend
destinations is committed twice in different parts of
the consensus surface (constants table + tx-validation
rule). Both must match, both are immutable at the V13
fork that introduces them, and any spend that names a
destination not in BOTH lists is rejected by every
validator regardless of signaling.
3. Per-spend cap. The absolute amount that any single
vault-spend transaction can move is capped at a small
fraction of the vault balance. Large routine drains
require many separate spends across many blocks, each
individually requiring fresh signaling — there is no
"one click empty the vault" path even with full
governance approval.
4. Rate limiting. The frequency at which vault spends can
happen is capped at consensus level (e.g. no more than
one approved spend per N blocks). This forces every
migration / rebalance to take real wall-clock time,
during which the wider community can detect and respond
to a hostile proposal before it completes.
5. ≥90% miner supermajority signaling. Every spend tx
must be accompanied by an on-chain signaling artefact
showing that at least 90% of recently active mining
identities have signalled approval. Recently-active is
defined by miner identity participation over the
previous signaling window (e.g. the last 1,000 blocks).
With the current ~24 active miners, 90% means at least
22 of 24 must sign. The threshold has evolved with the
protocol: 75% in the original whitepaper, raised to 95%
during the V6 internal review out of caution against
miner collusion, and finalised at 90% in the V13 review
after observing real network behaviour. The reasoning
for the V13 calibration: at 95% the system was brittle
against routine miner unavailability (a single offline
miner in a 20-miner network blocks every legitimate
spend), while at 90% the system tolerates two offline
miners out of twenty-four without sacrificing collusion
resistance — a hostile cabal would still need to
control 90% of recently active miners AND get past the
four other defenses, which are enforced regardless of
signaling. The threshold is the operability defense, not
the security defense; the whitelists are the security
defense.
Phase I -> Phase II custody transition. Until the V13 (or
V14 fallback) activation lands all five defenses in the
validator, the Gold Vault address remains under single-key
operational custody by the protocol developer. After
activation, custody transitions DIRECTLY from developer
to protocol — no intermediate institutional layer, no
intermediate multisig, no foundation. The Heritage Reserve
contract on Ethereum mainnet is governed by a Zodiac +
Reality.eth module architecture: any spend is proposed on
Reality.eth, the SOST chain state (the 90% miner signaling
result) is relayed to Reality.eth by an open relayer set
(anyone can run a relayer; relayers earn ETH bond rewards
for posting correct undisputed answers), and the spend
executes only if the Reality.eth oracle confirms the 90%
signaling threshold was met on-chain. No single key, no
single entity, no developer override controls the vault
after activation. This is irreversible: decentralization
only moves forward.
V13 target / V14 fallback gates. The five defenses each
have a binary readiness gate that the V13 release
candidate must satisfy. If ALL five gates are green on the
V13 RC, vault governance activates at block 12,000
alongside the rest of V13. If ANY gate is amber or red,
vault governance is deferred to V14 / block 15,000 with no
shame — shipping a half-implemented constitutional
constraint would be worse than waiting. The gates are:
G1. Validator enforcement of purpose restriction (dest
not in whitelist -> reject) implemented + tested.
G2. Both whitelists committed + cross-checked at tx
validation time.
G3. Per-spend cap and rate limit constants finalised
+ cross-validator agreement test passing.
G4. On-chain miner-signaling tx-type wired in,
signaling-window math implemented, 90% threshold
check live in tx validation.
G5. Heritage Reserve contract deployed on Ethereum
mainnet (Zodiac + Reality.eth), open relayer set
documented, end-to-end test (propose -> signal ->
relay -> execute) green on Sepolia testnet.
If any of G1..G5 are not green by the V13 RC freeze, the
vault governance bundle defers cleanly to V14. The
accumulation side (25% per block) is unaffected — it has
been consensus-enforced since genesis and stays that way
regardless of when the governance side lands.
WHAT THIS DOES NOT DO
- Does not change the emission schedule.
- Does not change the 4,669,201 SOST hard cap.
- Does not change the 50/25/25 coinbase split.
- Does not let miners vote on any consensus rule
beyond the narrow vault-spend governance — emission,
cap, split, difficulty, supply, SbPoW, cASERT, DTD
and the constitutional invariants stay immutable.
- Does not authorise vault spends to non-whitelisted
destinations even at 100% miner approval.
- Does not give the protocol developer any override
path after activation — custody transitions directly
to protocol, with no developer-held bypass key.
- Does not require any wallet change for ordinary
users / miners — only the vault address gains
consensus-level spend restrictions; user UTXOs
remain ordinary.
In short: the Gold Vault must be able to change form, but
not purpose. The protocol enforces that, not the
developer. The developer's job is to ship the gates
green; the chain's job is to refuse any spend that breaks
any of them.
— NeoB
