SOST Protocol — VT Governance / PoPC / Escrow Activation
PoPC (Proof of Personal Custody) operational launch, Gold Vault governance & Model B escrow: block 10,000
Original target was block 5,000. After the internal audit, these mechanisms were moved to block 10,000 for full integration and validation. The chain-stability-only V6 fork is now separated and
activates earlier at block 5,000.
TL;DR — 6 lines - VT activation at block 10,000. This is the governance / custody / PoPC activation fork.
- Gold Vault governance becomes consensus-enforced from block 10,000. The vault is protected by five independent consensus-level defenses. The protocol developer loses executive vault control at
the same block. - Signature-bound Proof of Work is included in the block 10,000 activation package, making conventional mining pools structurally incompatible with SOST consensus. Solo and P2Pool-style cooperative
mining remain unaffected. - PoPC Model A operational launch begins at block 10,000 — Tier 1 (100% multiplier) for the first 25 contracts. Hold tokenized gold in your own wallet, earn SOST. The gold never leaves the holder's
wallet. - PoPC Model B escrow contract written, audited for 10 attack vectors, and published in the repository (contracts/SOSTEscrow.sol). Immutable timelock escrow for XAUT/PAXG on Ethereum — no
admin key, no upgrade proxy, no pause function, no emergency withdrawal. Deployment to Ethereum mainnet is scheduled after Sepolia testnet validation. - Honest audit disclosure: GV1-GV4 rules were unit-tested but were never fully wired into production validation. That integration ships properly at block 10,000.
Status of the chain The SOST Protocol is alive, mined by ~26 independent participants, and accumulating its constitutional 25% Gold Vault and 25% PoPC Pool allocations every block since genesis (March 15, 2026).
The chain
is healthy. The V6 chain-stability fork (CASERT equalizer slew rate ±3 → ±1) activates at block 5,000. The chain-stability improvement was validated across 4,350+ simulation runs covering all 17 profiles (E4 through
H12), multiple variance levels, stall injection, and shock scenarios. Results: std dev −48%, sawtooth −99.9%, mean block time unchanged, E-profile recovery marginally slower but within acceptable bounds.
The larger governance / custody / PoPC package activates later at block 10,000:
- PoPC operational launch (Model A registration + reward payout)
- PoPC Model B escrow contract (Ethereum, pending Sepolia validation)
- Gold Vault governance rules (GV1-GV4 spending control, 5-defense model)
- Bond / Escrow lock output types
- Capsule activation
- Signature-bound Proof of Work (anti-pool)
This post covers the
block 10,000 activation package.
What the audit found The Gold Vault governance system (rules GV1 through GV4 — gold purchases, monthly operational limits, miner-voted approvals, automatic rejection) was
designed and unit-tested (17/17 tests passing in
tests/test_gold_vault.cpp), but the validator wiring connecting it to the live transaction pipeline
was never completed. In practical terms: at block 5,000 the old activation would have
triggered nothing, because the rules engine sat in the codebase as a library with no production caller.
This was found by reading the source code line by line, the same way the project asks others to verify its claims. The honest sequence of events is straightforward: the rules logic was written first, the
wiring was deferred, and that deferral had to be corrected properly before activation.
The audit also found that the version-bit signaling RPC (
getproposals) was returning placeholder data instead of reading actual block versions from the chain.
What this means in practice today: the Gold Vault and PoPC Pool addresses have been accumulating their 25% allocations since genesis, exactly as the whitepaper specifies. That part is enforced at the
deepest consensus level — every node rejects a block whose coinbase does not pay those allocations correctly.
The accumulation is real and verifiable. What is
not yet fully enforced by consensus is the
spending governance of those balances. Until the block 10,000 activation, the Gold Vault remains under
developer custody (the single
person maintaining the SOST codebase). The custody arrangement is at the developer's operational discretion and is intentionally not detailed publicly — disclosing operational security details creates
attack surface, not transparency. After block 10,000, the protocol itself enforces the spending logic via on-chain miner governance, and the developer loses executive control of the vault. The transition is
direct from developer custody to protocol custody, with no intermediate institutional layer.
Disclosing this proactively was chosen over shipping a rushed patch, because
a hard fork done right is worth more than a constant fix done in panic.
VT — what is being bundled at block 10,000 The block 10,000 activation package does six things in a single coordinated fork.
1. Gold Vault 5-defense governance model (wired into consensus) From block 10,000 onwards, any transaction spending from the Gold Vault address must pass ALL five independent consensus-level defenses simultaneously:
- Defense 1 — Purpose restriction: the vault can only be used for gold reserve operations. Any other purpose is rejected at consensus, regardless of voting outcome.
- Defense 2 — Destination whitelists: the vault can only send to constitutional addresses hardcoded in the protocol source code, organized into reserve destinations and emergency destinations
(initially empty). Adding any new destination requires a hard fork. No miner vote, no matter how unanimous, can authorize a transfer to any address outside these whitelists. - Defense 3 — Hard per-spend cap: no single transaction can move more than 2% of the current vault balance.
- Defense 4 — Aggregate rate limit: routine gold purchases are capped at 5% of the vault balance per ~30-day window. Emergency spends require a hard 30-day cooldown between transactions.
- Defense 5 — Supermajority approval: non-routine spends require ≥95% miner signaling over a 288-block window.
The vault has no burn route. Vault SOST is never destroyed under any conditions.
The Gold Vault must be able to change form, but not purpose. Epoch policy — 95% from day one The original whitepaper specified a 75% threshold during Epoch 0-1 and 95% from Epoch 2 onwards. After internal review,
the threshold is raised to 95% from the start. This is intentionally strict.
The vault exists to back the protocol with gold, not to fund discretionary spending.
2. Signature-bound Proof of Work (anti-pool protocol) Every winning block must include a digital signature made by the miner's private key over the PoW commitment. The block is valid only if:
- the signature verifies against a public key included in the block header, and
- the miner reward in the coinbase pays to the address derived from that same public key.
A conventional pool operator cannot delegate work to thousands of remote workers without either giving them the pool's private key or signing every attempt centrally. Conventional pool models become
structurally incompatible with SOST consensus. P2Pool-style cooperative mining remains fully supported.
3. PoPC Model A — operational launch Model A is
fully implemented and ready for block 10,000. All core components are operational:
- Registration, status, release, and slash RPCs — complete
- Dynamic reward system (Pool Utilization Ratio, 6 participation tiers, anti-whale tiers) — complete
- Bond sizing, protocol fee (5% uniform), reward cap (1,000 SOST/contract) — complete
- Price Bulletin system for pre-exchange bond computation — complete
- Automation scripts (daemon, oracle, Ethereum balance checker, cron installer) — complete
- 17/17 Gold Vault governance tests passing
Reward schedule:
Duration Base reward Tier 1 (first 25 contracts)
1 month 1% of bond 1.0%
3 months 4% of bond 4.0%
6 months 9% of bond 9.0%
9 months 15% of bond 15.0%
12 months 22% of bond 22.0%
The first
25 active contracts receive the full 100% multiplier (Tier 1). After that, the multiplier steps down automatically — 75%, 50%, 30%, 15%, 8%. Anti-whale tiers reduce the multiplier above 10
oz committed; the maximum is 200 oz, beyond which registration is rejected.
PoPC is intentionally application-layer, not consensus-layer. The 25% accumulation is consensus-enforced. Reward distribution is operator-mediated for the first 4 weeks of operation, transitioning to fully
automatic via the
popc_daemon.py cron daemon once safe production data has been gathered.
4. PoPC Model B — timelocked gold escrow (SOSTEscrow smart contract) Model B is the escrow complement to Model A. Instead of committing to hold gold in their own wallet (Model A), the participant deposits XAUT or PAXG into an
immutable smart contract on Ethereum with
a timelock. The SOST reward is paid immediately at deposit. At expiry, the original depositor — and only the original depositor — can withdraw the full gold amount.
The smart contract (
contracts/SOSTEscrow.sol) is now written, published in the repository, and includes:
- Zero admin keys — no owner, no admin, no Ownable pattern
- Zero upgrade proxies — no UUPS, no transparent proxy, no beacon, no delegatecall
- Zero pause function — the contract cannot be stopped by anyone
- Zero emergency withdrawal — no function bypasses the timelock under any circumstance
- No extension or modification — once created, a deposit's term is immutable
- Immutable token allowlist — only XAUT and PAXG, set at construction, cannot be changed
- Reentrancy protection on all state-changing functions
- Checks-effects-interactions pattern in the withdrawal function
Contract functions:
deposit(token, amount, unlockTime) → depositId
withdraw(depositId) — only by original depositor, only after unlock
getDeposit(depositId) — view
canWithdraw(depositId) — view
getUserDepositIds(user) — view
totalLocked(token) — view
Security analysis covering 10 attack vectors is published at
contracts/SECURITY.md. Deployment tooling (Foundry), mock tokens for testnet, 14 automated tests, and Etherscan verification scripts are
included in the repository.
Model B deployment path: Sepolia testnet first, manual flow testing, source verification on Etherscan, optional independent audit, then Ethereum mainnet deployment before block 10,000. The contract
is
not deployed yet — only the code and tooling are published.
Model B reward schedule (lower than Model A because there is no slash risk):
Duration Base reward
1 month 0.4% of gold value
3 months 1.5% of gold value
6 months 3.5% of gold value
9 months 5.5% of gold value
12 months 8.0% of gold value
Same participation tiers apply. Hard cap: 1,000 SOST max per contract.
5. Real version-bit signaling The
getproposals RPC bug is fixed so that it reads actual block header versions instead of placeholder data. Miners can signal through version bits as intended.
6. Bond / Escrow / Capsule activation The lock output types (
BOND_LOCK = 0x10,
ESCROW_LOCK = 0x11) become valid post-block 10,000, together with Capsule activation.
The cooperative angle — five ways to earn SOST SOST is built on cooperativism in the literal sense, not as a slogan. The protocol creates
multiple parallel income paths for participants of all sizes. After the block 10,000 activation, the full
menu is:
1. Mining the chain Every block awards 50% of the subsidy to whoever found the nonce. With CPU-friendly ConvergenceX (8 GB RAM, no ASIC), participation remains accessible. Post-V6, the CASERT slew rate update (±1) makes block
production more consistent and less dependent on brief anti-stall windows. Post-VT, signature-bound PoW ensures a small miner's hashrate cannot be silently absorbed by a centralized pool operator.
2. Anti-stall windows (CASERT) When the network goes too long without a block, CASERT lowers the profile over time. During these windows, smaller miners have a structurally higher chance of winning a block. With the V6 slew rate update,
these windows become less extreme but still provide accessible mining opportunities.
3. PoPC Model A — gold custody commitment Hold XAUT or PAXG in your own Ethereum wallet. Commit to keep holding for 1 to 12 months. Earn SOST rewards — up to 22% of your bond annually for a 12-month commitment at Tier 1. The gold never leaves your
wallet. Zero slash risk on the gold itself; only the posted SOST bond is at risk if the commitment is broken.
4. PoPC Model B — gold escrow Deposit XAUT or PAXG into the immutable SOSTEscrow contract on Ethereum. Receive SOST reward immediately. At expiry, withdraw full gold amount. Zero slash risk, zero audit risk, zero bond requirement. The
trade-off: lower reward rates than Model A, and the gold is locked (no liquidity during the term).
5. Gold Vault OTC participation and governance bot operation The OTC desk enables direct SOST acquisition against USDC/EUR. Every sale funds gold reserve purchases. The Phase II governance path includes a relayer bot that posts SOST chain state to Reality.eth on
Ethereum. Anyone can run a competing bot and earn small rewards for correct relay participation.
The point: a small participant — a single laptop, no specialized mining hardware, and 0.5 oz of gold in a MetaMask wallet — can earn meaningful SOST through mining, anti-stall windows, and PoPC
simultaneously. Earning a return does not depend on outcompeting a $10,000 mining rig.
Vault custody — two phases Vault custody transitions in a single, irreversible step from developer custody to protocol custody at the block 10,000 activation height. There is no intermediate institutional layer.
Phase I — now to block 10,000 (developer custody) The Gold Vault is custodied by the protocol developer (NeoB) until block 10,000. The custody arrangement is at the developer's operational discretion and is intentionally not detailed publicly. What IS
disclosed:
- The developer commits not to move funds from the Gold Vault for any purpose other than the constitutional one (gold reserve operations).
- Every reserve operation is documented publicly.
- The developer has no premine, no allocation, and no special income route other than mining the chain like everyone else.
- This is openly declared Phase I trust based on reputation and transparency until the protocol takes over automatically.
Phase II — block 10,000 onwards (protocol-governed custody) At the block 10,000 activation height, vault control transitions from developer custody to protocol-governed logic with the five independent consensus-level defenses described above. The protocol developer
can no longer move the vault unilaterally. The transition is rule-based and has a hard date encoded in the consensus rules — it is not subject to the developer's later willingness to step back.
Phase III — later, conditional on growth Migration from tokenized gold (XAUT, PAXG) to physical gold custody in a regulated vault (Switzerland or London), audited by a recognized custodian. This eliminates issuer risk (Tether, Paxos), eliminates
smart-contract risk, and provides physical audit reports tied to specific bar serial numbers. No bridges, no wSOST, no cross-chain attack surface.
Why this is being done — the philosophical part SOST exists on the assumption that the post-fiat era requires infrastructure with
three properties simultaneously:
- Decentralized mining — no single entity, including the developer, controls block production
- Real-world backing — value tied to physical gold, not to abstract scarcity
- Cooperative economics — multiple participation paths so that small participants can earn alongside large ones
There is no foundation behind SOST. There is no council, no DAO, no allocation of pre-mined tokens. There is one developer who wrote the codebase, one set of consensus rules anyone can read, and a chain
maintained in the open. The developer does not own SOST. Nobody owns SOST. The developer maintains it until the protocol can maintain itself, and then steps back.
The goal is that nobody, not even the developer, ever has to be trusted permanently.
Timeline Block ~4,754 Current chain height
V6 code deployed on VPS and available on GitHub
VT mechanisms under development
Block 5,000 V6 ACTIVATION HEIGHT
(~246 blocks away) - CASERT equalizer slew rate ±3 → ±1
- All miners and nodes must upgrade before this height
Block ~9,000 VT release candidate published
SOSTEscrow deployed on Sepolia testnet (Model B)
4-week upgrade window for miners and nodes
Block 10,000 VT ACTIVATION HEIGHT
- Gold Vault 5-defense governance enforced
- Signature-bound PoW required
- PoPC Model A operational launch
- PoPC Model B (escrow) available on Ethereum mainnet
- Bond / Escrow / Capsule output types valid
- Developer → protocol custody transition
Block 10,000 + 4 weeks PoPC reward distribution transitions
from supervised manual flow to automated cron daemon
What participants need to do Node operators: upgrade before block 5,000 for the V6 stability fork, and later again before block 10,000 for the VT governance / custody / PoPC activation package.
Miners: continue mining as usual. Two milestones require rebuilding from updated sources:
- Block 5,000 — V6 chain-stability fork (rebuild miner binary)
- Block 10,000 — VT activation (rebuild miner with signature-bound PoW support + hot mining key)
Tokenized gold holders interested in PoPC Model A: nothing to do until block 10,000. Prepare an Ethereum wallet holding XAUT or PAXG. The registration guide at
sostcore.com/sost-popc-quickstart.html documents the process. The first 25 contracts receive Tier 1 (100% multiplier).
Tokenized gold holders interested in PoPC Model B: the SOSTEscrow contract will be deployed on Ethereum mainnet before block 10,000. The contract address will be published on
sostcore.com and verified on Etherscan. Model B requires depositing gold tokens into the escrow contract — review the contract source at
contracts/SOSTEscrow.sol and
the security analysis at
contracts/SECURITY.md before participating.
Verifiers: clone the repo at
github.com/Neob1844/sost-core and verify directly. The smart contract, deployment tooling, 14 automated tests, and full
security analysis are public. Independent audit contributions are welcome.
Q&A — questions to expect Q: Is SOST safe to hold today? A: Yes. The 25% accumulation to Gold Vault and PoPC Pool has been consensus-enforced since genesis. The audit findings concerned
spending governance, not accumulation. Those spending rules become
consensus-enforced at block 10,000.
Q: Could the developer drain the Gold Vault right now? A: Until block 10,000, the Gold Vault remains under developer custody. The custody arrangement is at the developer's operational discretion and is intentionally not detailed publicly — disclosing
operational security details creates attack surface, not transparency. After block 10,000, the five-defense governance model takes over and unilateral executive control ends.
Q: What can the Gold Vault be used for? Could a colluding majority of miners drain it? A: No. After block 10,000, the Gold Vault is constrained by FIVE independent consensus-level defenses, all of which must hold simultaneously:
- Purpose restriction — only gold reserve operations
- Destination whitelists — only constitutional addresses (hard fork to modify)
- Hard per-spend cap — max 2% of vault balance per transaction
- Aggregate rate limit — 5% per 30-day window for routine purchases; 30-day cooldown for emergency spends
- Supermajority approval — ≥95% miner signaling for non-routine spends
The vault has no burn route. Vault SOST is never destroyed. The Gold Vault must be able to change form, but not purpose.
Q: Is the Model B escrow contract safe? A: The contract has been analyzed for 10 attack vectors (reentrancy, ERC-20 failures, integer overflow, timestamp manipulation, front-running, gas DoS, approval race, direct token send, deposit ID
prediction, issuer risk). It uses reentrancy guards, checks-effects-interactions, and is fully immutable (no admin, no proxy, no pause). However, it has NOT been independently audited by a third party yet.
The code and security analysis are published for review. Sepolia testnet validation is planned before mainnet deployment.
Q: What is the difference between Model A and Model B? A:
Model A (Commitment) Model B (Escrow)
Gold location Your own wallet Smart contract
Gold moves? No Yes (into escrow)
Bond required? Yes (SOST bond) No
Slash risk? Yes (bond at risk) No
Audit risk? Yes (random audits) No (escrow enforces)
Reward rate Higher (1-22% of bond) Lower (0.4-8% of gold)
Reward timing At completion Immediately at deposit
Trust model Audit system + bond Smart contract code
A: Because the vault should be extremely hard to misuse. With ~26 miners, 95% means essentially all active miners must approve. The threshold is self-protecting: changing it requires meeting it.
Q: When will SOST be on an exchange? A: When the system is ready, not before. Conditions: publishable transparency reports, verifiable Gold Vault balance, working Phase II governance, and sustained OTC volume. No specific exchange has been
targeted.
Q: How can someone contribute? A: Run a node. Run a miner. Mirror the explorer. Verify the code. Review the smart contract. Participate in Sepolia testing. Report bugs via BTCTalk or the upcoming Telegram channel.
Public audit trail All simulation data, test scripts, contract source, and audit reports are publicly available:
- contracts/SOSTEscrow.sol — Model B escrow contract
- contracts/SECURITY.md — 10-vector security analysis
- contracts/test/SOSTEscrow.t.sol — 14 automated tests
- contracts/README.md — deployment guide
- reports/simulator_parity_report.md — simulator vs C++ audit
- reports/pid_tuning_campaign.md — 2,630-config tuning campaign
- reports/slew_prefork_validation.md — 1,650-run slew validation
- reports/e_profile_regression.md — 2,700-run E-profile regression
- reports/casert_dual_audit.md — joint bitsQ/equalizer audit
Independent review is welcome.
NeoB — SOST Protocol sostcore.com ·
GitHub ·
Explorer Not financial advice. SOST is experimental software. PoPC is an experimental cooperative reward system. The SOSTEscrow smart contract has not been independently audited. Gold Vault spending
governance becomes consensus-enforced at block 10,000. The V6 chain-stability fork activates earlier at block 5,000. Review the source code, run the verification commands, and form an independent opinion
before participating.
