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). Confirmed on the real code path (scaled devnet lab): a reorg at/below the cap converges to the most-work chain; a reorg deeper than the cap is REJECTED — the node keeps its own chain even against more valid work, producing a persistent split (restart-stable). This bounds deep reorgs but can prevent automatic convergence after a very long partition — the deep-reorg recovery for that case is devnet research, post-fork. Not a finality guarantee. |
| 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 |
SOST nodes independently verify Proof-of-Work and chain validity. SACS is an autonomous safety layer that detects forks and reorganizations, protects affected transactions and applications, and supports autonomous recovery — without masternodes, privileged validators, quorums or a developer-selected chain. It is not a finality guarantee and does not make blocks irreversible against an adversary able to produce a valid higher-work chain.
| Chain selection | Highest cumulative VERIFIED work (never height, never peer-reported work) |
| SACS Core (V16-compatible) | Fork/reorg monitor, structured events, getchainsafety RPC, transaction-safety states (CONFIRMED→REORGED→REENTERED_MEMPOOL→CONFLICTED), wallet/DEX/exchange reconciliation, recovery/persistence — observability & application safety, no consensus change |
| Status (Core) | LAB VERIFIED on the research branch; not yet deployed to mainnet (no node binary swapped before the #30,000 fork) |
| Deep-reorg model | Research only (devnet): whether the 500-block cap should become an operational alert (a valid higher-work chain adopted after re-verification) rather than an automatic rejection. Would require a future coordinated upgrade — never auto-added to V16. |
| Mainnet today | Unchanged: MAX_REORG_DEPTH = 500, hard checkpoints (≤3,554), atomic reorg with rollback |
Principle: consensus decides valid/invalid; SACS observes and protects. A SACS alert can make a wallet, the DEX or an exchange wait for more confirmations or pause a sensitive credit — it can never, by itself, turn a valid block into an invalid one, nor halt honest mining. Blockchain truth always outranks any local database or UI.
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 (HISTORICAL) | V1 (<1450) | V2 (≥1450) | V3 (≥4100) | V3.1 (≥4110) | V4 (≥4170) | V5 (≥4300) | V6 (≥5000) |
|---|---|---|---|---|---|---|---|
| Halflife | 48h | 24h | 24h | 24h | 24h | 24h | 24h |
| Delta cap | 6.25% | 12.5% | 12.5% | 12.5% | 1.56% down when ahead* | 1.56% down when ahead* | 12.5% |
| Slew rate | ±1 | ±1 | ±3 | ±3 (stored) | ±3 (stored) | ±3 (stored) | ±1 |
| H10/H11 scale | 3 | 2 (smoothed) | |||||
| Anti-stall | max(lag×600, 7200s) | max(lag×600, 7200s) | Always 7,200s | Always 7,200s | 3,600s | 3,600s | |
| Ahead Guard | — | Enter ≥16, exit ≤8 | Enter ≥16, exit ≤8 | — (ended #4,999) | |||
All forks are forward-only (no regenesis). This table is HISTORICAL (blocks < 5,175). *V4 Ahead Guard (active #4,170–#4,999 only): when chain ≥16 blocks ahead, bitsQ downward delta clamped to 1/64 (≈1.56%) per block. CURRENT MAINNET RULE: bitsQ avg288 (#5,175+) with dead band ±15 s and 0.5/1.0/2.0/3.0% steps (#5,270+); Equalizer 43 profiles E7–H35 via direct lag map (#5,323+), anti-stall at 3,600 s (60 min), V12 triangular cascade (#7,350+).
| Scenario | Response |
|---|---|
| Critical bug | Protocol pauses new PoPC contracts. Existing contracts continue unaffected. |
| Exchange hack | Heritage Reserve on Ethereum is sealed with no operational interaction. Gold Funding Vault requires consensus authorization for all operations. |
| XAUT/PAXG issuer risk | Emergency Catastrophe: rotate (E1) or liquidate-buy-redistribute (E2). Requires dual gate. |
| Issuer risk (future only) | Protocol redirects future purchases without consensus. Existing assets sealed. |
| Chain death (90 days) | Dead-man switch. 60-day dissolution notice. After notice, protocol 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 avg288 + equalizer, E7–H35, 43 profiles, H13 ceiling pre-V12 / H20 ceiling V12 #7,350+) | 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 |
| SEC2 (V30000) — RPC hardening: getblockhash/getblock crash fixes (dispatch try/catch, JSON parser delimiter-advance, nested-array cap) | Complete |
SOST uses secp256k1 ECDSA (same as Bitcoin) for transaction signatures, and ECDSA remains the active signing scheme. Post-quantum cryptography is an open research track — it is not active, has no activation height or date, and makes no quantum-resistance claim. The notes below record the direction of that research, not a committed deployment schedule.
| Current scheme | ECDSA secp256k1 (libsecp256k1) — 64-byte signatures — active |
| PQC algorithm under study | ML-DSA (NIST FIPS 204; formerly CRYSTALS-Dilithium) — candidate, not adopted |
| PQC signature size | 2,420 bytes (Level 3) |
| PQC address prefix | sost2 — reserved, not active |
| SHA-256 status | Grover reduces to 128-bit, still sufficient |
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, 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 |