Sequential PoW dependency chains, memory-hard mining, consensus-enforced integer arithmetic, layered bond deterrence, entropy-derived audits, and dual-gate emergency authorization. Security is structural, not promised.
Each ConvergenceX attempt requires 8 GB RAM (4 GB dataset + 4 GB scratchpad) and 100,000 sequential rounds. Even an attacker with unlimited CPUs cannot speed up a single attempt — parallelism only adds more independent attempts. Node validation requires only ~500 MB via Transcript V2 (11-phase verification at ~0.2ms).
| Property | Value |
|---|---|
| RAM per attempt | 8 GB (4 GB dataset + 4 GB scratchpad) |
| Rounds per attempt | 100,000 (strictly sequential) |
| Intra-attempt parallelism | Eliminated by state dependency |
| Inter-attempt parallelism | Multiple cores = multiple independent attempts |
| ASIC advantage estimate | Low multiples over modern CPUs |
| Difficulty adjustment | cASERT per-block, stable regardless of hashrate |
| Node RAM (verify only) | ~500 MB (no dataset, no scratchpad — anyone can run a node) |
SOST uses best-chain-by-cumulative-work selection, not longest-chain. Each block contributes work = floor(2^256 / (target + 1)). The chain with the highest total accumulated work wins. This prevents attacks using many easy blocks to outpace a shorter chain with more real work. This is the same approach used by Bitcoin.
| Chain selection | Highest cumulative work (NOT longest chain) |
| Block work formula | floor(2^256 / (target + 1)) |
| Fork resolution | Atomic — full rollback on failure |
| Max reorg depth | 500 blocks (~3.5 days) |
| Orphan vs fork | Separated: orphans (parent unknown) vs fork candidates (parent known) |
| Mempool recovery | Valid non-coinbase txs returned to mempool after reorg; conflicts discarded |
The bond does not make fraud impossible — it makes it costly. Four layers of deterrence combine to make large-scale systematic fraud economically irrational.
Up to 30% of gold value locked as SOST bond. Immediate financial cost on slash. Bond is fully lost and redistributed to PoPC Pool and Gold Funding Vault.
Permanent record. Stars reset to zero. Future contracts blocked at all levels. Rebuilding reputation requires starting from scratch with 0.5 oz limits.
Known fraudulent wallets excluded at the application layer. This is not consensus and does not affect the base chain — it is PoPC policy enforcement.
New users (0 stars) can only commit 0.5 oz maximum. Large commitments require proven track record (5 stars = max 10 oz). Slow unlock prevents mass fraud.
| Property | Analysis |
|---|---|
| Audit source | ConvergenceX block entropy triple (block_id, commit, checkpoints_root) |
| Predictability | None — depends on 100K-round PoW that hasn't occurred |
| Influence | No party can predict or influence the schedule |
| Post-audit fraud window | Next random audit within the period (5-30% probability) |
| Detection cost | Full bond slash |
| Continuous custody | Historical balance sampling at deterministic checkpoints |
| Property | Analysis |
|---|---|
| Consensus oracle dependency | None — all consensus uses chain-internal data only |
| Bond price source | 7-day TWAP from exchanges with verifiable liquidity (resistant to single-block manipulation) |
| Price data role | Advisory for PoPC bond sizing, not consensus-critical |
| User consent | Required — user signs exact bond terms before submission |
| Malicious bulletin | Users simply refuse to sign — no funds at risk |
The asymmetric cASERT policy prevents attackers from exploiting difficulty relaxation.
| Scenario | Signal | cASERT Response |
|---|---|---|
| Attacker with high hashrate | Chain fast (negative signal) | NORMAL mode — no relaxation |
| Genuine hashrate drop | Chain slow (positive signal) | Relaxed stability — liveness preserved |
| Attacker benefit | None — stability requirements remain at maximum | |
Relaxed stability is only available when the chain needs help (hashrate dropped), never when an attacker is dominating. This is the correct security trade-off.
| Parameter | V1 (blocks <1450) | V2 (blocks ≥1450) |
|---|---|---|
| Halflife | 48 hours | 24 hours |
| Per-block delta cap | 6.25% | 12.5% symmetric |
| Target spacing | 600s (unchanged) | |
V2 activated at block 1450 (no regenesis). Faster response to hashrate changes while maintaining stability.
| Scenario | Response |
|---|---|
| Critical bug | Foundation pauses new PoPC contracts. Existing contracts continue unaffected. |
| Exchange hack | Heritage Reserve on Ethereum is sealed with no operational interaction. Gold Funding Vault requires Foundation authorization for all operations. |
| XAUT/PAXG issuer risk | Emergency Catastrophe: rotate (E1) or liquidate-buy-redistribute (E2). Requires dual gate. |
| Issuer risk (future only) | Foundation redirects future purchases without consensus. Existing assets sealed. |
| Chain death (90 days) | Dead-man switch. 60-day dissolution notice. After notice, Foundation may access reserve for orderly wind-down. |
| Practice | Detail |
|---|---|
| Institutional keys | Offline (cold), never on public nodes |
| Public nodes | Low-balance hot wallets, no reserve keys |
| Address rotation | Published with full traceability and proofs |
| Wallet encryption | AES-256-GCM + scrypt (N=32768, r=8, p=1) |
| Feature | Detail |
|---|---|
| Build hardening | Stack protector, ASLR (PIE), RELRO, FORTIFY_SOURCE |
| Wallet encryption | AES-256-GCM + scrypt (N=32768), key material wiped with OPENSSL_cleanse |
| ECDSA signing | libsecp256k1 with LOW-S enforcement, side-channel resistant context |
| Fee-rate ordering | Rational arithmetic (integer-only), no floating-point consensus bugs |
| P2P protection | Ban system (100pts = 24h), 64 max inbound, 4 per IP |
| RPC security | Localhost-only default, Basic Auth, dangerous method documentation |
| cASERT RPC | Real-time profile from node (casert_profile, casert_lag), no wall-clock estimation |
| Feature | Status |
|---|---|
| Trusted address book | Complete — local address whitelisting with 4 trust levels (trusted/known/new/blocked) |
| New-address cooldown | Complete — first-send warning + high-value alert for unknown addresses |
| Pre-send summary | Complete — full transaction summary with confirmation prompt before broadcast |
| Treasury safety profile | Complete — daily limits, per-TX limits, vault mode, policy file (~/.sost/wallet_policy.json) |
| RBF (Replace-by-Fee) | Complete — full RBF mempool policy, higher fee-rate replacement, no consensus change |
| CPFP (Child-Pays-for-Parent) | Complete — package fee-rate aware block template builder, miner policy only |
| SOST-PSBT offline signing | Complete — JSON+base64 format, create/sign/combine/finalize/broadcast |
| Native multisig (sost3) | Complete — redeemScript-hash M-of-N CHECKMULTISIG, 2-of-3 treasury support |
| HD wallet (BIP39) | Complete — 12-word seed phrases, CLI + web wallet compatible |
| Component | Status |
|---|---|
| Transaction signing (libsecp256k1) | Complete |
| Consensus validation (R1-R14, S1-S12, CB1-CB10) | Complete |
| cASERT unified difficulty (bitsQ + equalizer, E4–H9 profiles) | Complete |
| Mempool validation and relay | Complete |
| Transaction confirmation in blocks | Complete |
| RPC authentication (--rpc-user/--rpc-pass) | Complete |
| Coinbase maturity filter (1000 blocks) | Complete |
| Dynamic fee calculation (CLI v1.3) | Complete |
| Wallet encryption (AES-256-GCM + scrypt) | Complete |
| P2P DoS protection (ban scoring, peer limits) | Complete |
| Checkpoints + reorg limit (500 blocks / ~3.5 days) | Complete |
| P2P encryption | Active (X25519 + ChaCha20-Poly1305, default on) |
| Trusted address book (4 trust levels) | Complete |
| New-address cooldown warning | Complete |
| Pre-send confirmation summary | Complete |
| Treasury safety profile (vault mode) | Complete |
| RBF (Replace-by-Fee) mempool policy | Complete |
| CPFP (Child-Pays-for-Parent) miner policy | Complete |
| HD wallet (BIP39 seed phrases) | Complete — web + CLI compatible |
Do not open a public issue for security vulnerabilities. Use the private contact form.
| Channel | URL |
|---|---|
| Security vulnerability report | sostcore.com/sost-contact.html → Select: Security Vulnerability Report |
| General issues | github.com/Neob1844/sost-core/issues |
If you discover a security vulnerability in SOST Protocol, please report it responsibly through our secure contact channel: 1. Go to the Contact page: https://sostcore.com/sost-contact.html 2. Select subject: “Security Vulnerability Report” 3. Include the following ticket code in your message: SEC-DISC-2026 4. Describe the vulnerability in detail: • Affected component (node, wallet, explorer, P2P, RPC, consensus) • Steps to reproduce • Potential impact assessment • Suggested fix (if any) 5. Do NOT disclose the vulnerability publicly until we have acknowledged and addressed it. Response time: We aim to acknowledge reports within 48 hours and provide an initial assessment within 7 days. Severity classification: CRITICAL — Consensus bypass, double-spend, remote code execution HIGH — Key exposure, fund theft, P2P network disruption MEDIUM — Denial of service, information disclosure, RPC abuse LOW — UI bugs, non-exploitable edge cases Reports classified as CRITICAL or HIGH may be eligible for recognition in the project’s Security Hall of Fame.
| In Scope | Out of Scope |
|---|---|
| Consensus rule bypass | Social engineering |
| Private key exposure | Attacks requiring physical access |
| Remote code execution | Third-party dependencies (report upstream) |
| P2P protocol exploits | Denial of service via network flooding |
| RPC authentication bypass | Explorer HTML (client-side only) |
| Wallet encryption weakness |