Skip to content

Latest commit

 

History

History
1299 lines (1215 loc) · 133 KB

File metadata and controls

1299 lines (1215 loc) · 133 KB

Mbongo Chain — Economic Security

Document Type: Security Specification
Last Updated: November 2025
Status: Official Reference


Table of Contents

  1. Purpose of Economic Security
  2. Fixed Supply + Deflationary Pressure
  3. PoS + PoUW Hybrid Security
  4. Attack Scenarios and Economic Costs
  5. Economic Finality Model
  6. Role of Slashing
  7. Long-Term Stability (50-Year Horizon)
  8. Summary for Auditors and Researchers

1. Purpose of Economic Security

1.1 Security Through Economics

Mbongo Chain's security model is fundamentally economic. Rather than relying solely on cryptographic assumptions or probabilistic guarantees, the protocol makes attacks economically irrational. Honest behavior is profitable; malicious behavior is costly.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         ECONOMIC SECURITY FOUNDATIONS                                   │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   DETERMINISTIC EXECUTION                                                       │  │
│   │   ═══════════════════════                                                       │  │
│   │                                                                                 │  │
│   │   Security depends on determinism because:                                     │  │
│   │                                                                                 │  │
│   │   • Every node computes identical state transitions                            │  │
│   │   • Invalid states are detectable by any observer                              │  │
│   │   • Fraud proofs are conclusive and verifiable                                 │  │
│   │   • No ambiguity in what constitutes "correct" behavior                        │  │
│   │                                                                                 │  │
│   │   Without determinism:                                                          │  │
│   │   • Nodes could disagree on validity                                           │  │
│   │   • Slashing evidence could be contested                                       │  │
│   │   • Attacks could exploit non-deterministic outcomes                           │  │
│   │                                                                                 │  │
│   │   Mbongo ensures determinism through:                                           │  │
│   │   • Integer-only arithmetic                                                    │  │
│   │   • Canonical execution order                                                  │  │
│   │   • Reproducible state transitions                                             │  │
│   │   • Verifiable compute receipts                                                │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   ECONOMIC GUARANTEES VS PROBABILISTIC ASSUMPTIONS                              │  │
│   │   ════════════════════════════════════════════════                              │  │
│   │                                                                                 │  │
│   │   Traditional Security (Probabilistic):                                         │  │
│   │   • "Attacks are unlikely because..."                                          │  │
│   │   • "With high probability, consensus holds..."                                │  │
│   │   • "The honest majority is assumed to..."                                     │  │
│   │                                                                                 │  │
│   │   Mbongo's Economic Security:                                                   │  │
│   │   • "Attacks cost more than potential gain"                                    │  │
│   │   • "Misbehavior results in deterministic slashing"                            │  │
│   │   • "Economic incentives align participants with protocol"                     │  │
│   │                                                                                 │  │
│   │   Key Difference:                                                               │  │
│   │   Probabilistic: "Attack might fail"                                           │  │
│   │   Economic: "Attack is economically irrational"                                │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   COMPUTE-FIRST VALIDATION LOGIC                                                │  │
│   │   ══════════════════════════════                                                │  │
│   │                                                                                 │  │
│   │   Mbongo's compute-first design adds a unique security layer:                  │  │
│   │                                                                                 │  │
│   │   • PoUW receipts create verifiable proof of work done                         │  │
│   │   • Compute results are independently reproducible                             │  │
│   │   • GPU providers have economic stake in correctness                           │  │
│   │   • Invalid compute → slashing → economic loss                                 │  │
│   │                                                                                 │  │
│   │   Security Enhancement:                                                         │  │
│   │   • Attackers must compromise BOTH stake AND compute                           │  │
│   │   • Double the attack surface = double the cost                                │  │
│   │   • Compute receipts provide additional validation layer                       │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

1.2 Security Model Summary

Aspect Mechanism Guarantee
Consensus PoS (50%) + PoUW (50%) Dual-layer security
Finality Economic finality Reversal economically irrational
Validation Deterministic execution All nodes agree
Enforcement Slashing Misbehavior is costly
Sustainability Fixed supply + burns Long-term value stability

2. Fixed Supply + Deflationary Pressure

2.1 Immutable Supply Cap

╔═════════════════════════════════════════════════════════════════════════════════════════╗
║                                                                                         ║
║                         TOTAL SUPPLY: 31,536,000 MBO                                    ║
║                                                                                         ║
╠═════════════════════════════════════════════════════════════════════════════════════════╣
║                                                                                         ║
║   ┌─────────────────────────────────────────────────────────────────────────────────┐  ║
║   │                                                                                 │  ║
║   │   FIXED FOREVER — NO MINTING                                                    │  ║
║   │   ══════════════════════════                                                    │  ║
║   │                                                                                 │  ║
║   │   • This number is hardcoded in consensus rules                                │  ║
║   │   • No governance proposal can increase it                                     │  ║
║   │   • No emergency mechanism can create new MBO                                  │  ║
║   │   • No smart contract can mint MBO                                             │  ║
║   │   • No Foundation action can modify supply                                     │  ║
║   │                                                                                 │  ║
║   │   Mathematical Guarantee:                                                       │  ║
║   │   Σ (all MBO ever created) ≤ 31,536,000                                        │  ║
║   │                                                                                 │  ║
║   │   This is UNCONDITIONALLY TRUE for all time.                                   │  ║
║   │                                                                                 │  ║
║   └─────────────────────────────────────────────────────────────────────────────────┘  ║
║                                                                                         ║
╚═════════════════════════════════════════════════════════════════════════════════════════╝

2.2 Fee Burning Mechanism

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         FEE STRUCTURE                                                   │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   BASE FEE: 100% BURNED                                                                 │
│   ═════════════════════                                                                 │
│                                                                                         │
│   • Every transaction pays a base fee                                                  │
│   • This fee is PERMANENTLY DESTROYED                                                  │
│   • Sent to null address (0x0000...0000)                                               │
│   • Reduces circulating supply                                                         │
│   • Creates deflationary pressure                                                      │
│                                                                                         │
│   burn_amount = gas_used × base_fee_per_gas                                            │
│                                                                                         │
│                                                                                         │
│   PRIORITY FEE: REDIRECTED TO PARTICIPANTS                                              │
│   ════════════════════════════════════════                                              │
│                                                                                         │
│   • Users optionally add priority fee for faster inclusion                             │
│   • Standard transactions → Block proposer (validator)                                 │
│   • Compute transactions → GPU provider                                                │
│   • Oracle messages → Attesters                                                        │
│                                                                                         │
│   priority_payment = gas_used × priority_fee_per_gas                                   │
│                                                                                         │
│                                                                                         │
│   NET EFFECT                                                                            │
│   ══════════                                                                            │
│                                                                                         │
│   Every transaction:                                                                   │
│   • DECREASES circulating supply (base fee burned)                                     │
│   • TRANSFERS value (priority fee to service provider)                                 │
│   • CREATES NO NEW MBO                                                                 │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

2.3 Long-Term Token Value Stability

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         WHY THIS ENSURES VALUE STABILITY                                │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   SUPPLY DYNAMICS                                                                       │
│   ═══════════════                                                                       │
│                                                                                         │
│   Circulating_Supply(t) = Total_Issued(t) - Total_Burned(t)                            │
│                                                                                         │
│   Where:                                                                                │
│   • Total_Issued increases (block rewards) but decelerates (halving)                   │
│   • Total_Burned increases continuously with network usage                             │
│                                                                                         │
│   Long-term: Total_Burned may exceed new issuance → Net Deflation                      │
│                                                                                         │
│                                                                                         │
│   VALUE STABILITY MECHANISM                                                             │
│   ═════════════════════════                                                             │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   High Network Usage                                                            │  │
│   │        │                                                                        │  │
│   │        ▼                                                                        │  │
│   │   More Transactions                                                             │  │
│   │        │                                                                        │  │
│   │        ▼                                                                        │  │
│   │   More Fees Burned ──────────▶ Lower Circulating Supply                        │  │
│   │        │                              │                                         │  │
│   │        │                              ▼                                         │  │
│   │        │                       Higher Scarcity                                  │  │
│   │        │                              │                                         │  │
│   │        │                              ▼                                         │  │
│   │        └──────────────────────▶ Value Appreciation                             │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   CONTRAST WITH INFLATIONARY MODELS                                                     │
│   ═════════════════════════════════                                                     │
│                                                                                         │
│   Inflationary chains:                                                                 │
│   • Continuous dilution of existing holders                                            │
│   • Validators must sell to cover costs                                                │
│   • Constant downward price pressure                                                   │
│                                                                                         │
│   Mbongo:                                                                               │
│   • No dilution (fixed supply)                                                         │
│   • Fee burns offset any issuance                                                      │
│   • Network success → token appreciation                                               │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

2.4 Circulating Supply Projection (50-Year)

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         CIRCULATING SUPPLY PROJECTION                                   │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   Circulating                                                                           │
│   Supply                                                                                │
│   (Million                                                                              │
│    MBO)                                                                                 │
│                                                                                         │
│   31.5 ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─  Total Supply Cap               │
│     │                                                                                   │
│     │                 ●───●                                                             │
│   30 │            ●───┘   └───●                                                        │
│     │         ●──┘            └───●        Issued - Burned                             │
│     │       ●─┘                   └───●                                                │
│   25 │     ●                          └───●                                            │
│     │    ●                                └───●                                        │
│     │   ●                                     └───●                                    │
│   20 │  ●                                         └───●                                │
│     │ ●                                               └───●                            │
│     │●                                                    └───●                        │
│   15 │                                                        └───●                    │
│     │                                                             └───●                │
│     │                                                                 └───●            │
│   10 │                                                                    └───●        │
│     │                                                                         └───●    │
│     │                                                                                   │
│    5 │     If burns > issuance, supply decreases                                       │
│     │                                                                                   │
│     │                                                                                   │
│    0 └──┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬────▶ Years             │
│         5    10    15    20    25    30    35    40    45    50                         │
│                                                                                         │
│   ASSUMPTIONS                                                                           │
│   ───────────                                                                           │
│   • Network usage grows moderately over time                                           │
│   • Burn rate eventually exceeds halved block rewards                                  │
│   • Peak circulating supply ~Year 10-15                                                │
│   • Long-term trend: deflationary                                                      │
│                                                                                         │
│   Note: Actual trajectory depends on network adoption and usage patterns.              │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

3. PoS + PoUW Hybrid Security

3.1 Dual-Layer Security Model

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         HYBRID PoS + PoUW SECURITY                                      │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ╔═════════════════════════════════════════════════════════════════════════════════╗  │
│   ║                                                                                 ║  │
│   ║   REWARD SPLIT: 50% PoS + 50% PoUW                                              ║  │
│   ║                                                                                 ║  │
│   ╚═════════════════════════════════════════════════════════════════════════════════╝  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   50% PoS: STAKE-BASED HONEST-MAJORITY                                          │  │
│   │   ════════════════════════════════════                                          │  │
│   │                                                                                 │  │
│   │   How it provides security:                                                     │  │
│   │   • Validators lock MBO as collateral                                          │  │
│   │   • Misbehavior → stake slashing                                               │  │
│   │   • Attack requires controlling >1/3 of staked MBO                             │  │
│   │   • Economic cost of attack = cost to acquire stake                            │  │
│   │                                                                                 │  │
│   │   Security Guarantee:                                                           │  │
│   │   With 2/3+ honest stake, consensus is safe and live.                          │  │
│   │                                                                                 │  │
│   │   Attack Cost:                                                                  │  │
│   │   To control 1/3 stake = ~10,512,000 MBO (at full staking)                     │  │
│   │   Plus risk of slashing if detected                                            │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   50% PoUW: COMPUTE-BASED SECURITY                                              │  │
│   │   ════════════════════════════════                                              │  │
│   │                                                                                 │  │
│   │   How it provides security:                                                     │  │
│   │   • GPU providers stake collateral + perform useful work                       │  │
│   │   • Compute receipts are verifiable proofs                                     │  │
│   │   • Invalid compute → slashing                                                 │  │
│   │   • Results can be independently reproduced                                    │  │
│   │                                                                                 │  │
│   │   Security Guarantee:                                                           │  │
│   │   Compute receipts add deterministic verification layer.                       │  │
│   │   Fraudulent compute is detectable and punishable.                             │  │
│   │                                                                                 │  │
│   │   Attack Cost:                                                                  │  │
│   │   To control compute = massive hardware investment                             │  │
│   │   Plus electricity costs                                                       │  │
│   │   Plus slashing risk                                                           │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

3.2 Why Hybrid Rejects Classical 51% Attacks

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         REJECTION OF 51% ATTACKS                                        │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   CLASSICAL 51% ATTACK                                                                  │
│   ════════════════════                                                                  │
│                                                                                         │
│   In single-resource systems (PoW or PoS alone):                                       │
│   • Attacker controls >50% of ONE resource                                             │
│   • Can rewrite history, double-spend, censor                                          │
│                                                                                         │
│                                                                                         │
│   WHY THIS FAILS AGAINST MBONGO                                                         │
│   ═════════════════════════════                                                         │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   REQUIREMENT 1: Control Stake                                                  │  │
│   │   ─────────────────────────────                                                 │  │
│   │   • Need >1/3 of staked MBO for safety attack                                  │  │
│   │   • Need >2/3 of staked MBO for liveness attack                                │  │
│   │   • Cost: Millions of MBO + market impact                                      │  │
│   │                                                                                 │  │
│   │   REQUIREMENT 2: Control Compute                                                │  │
│   │   ──────────────────────────────                                                │  │
│   │   • Need significant GPU capacity                                              │  │
│   │   • Need to produce valid compute receipts                                     │  │
│   │   • Cost: Hardware + electricity + operational expertise                       │  │
│   │                                                                                 │  │
│   │   REQUIREMENT 3: Avoid Detection                                                │  │
│   │   ──────────────────────────────                                                │  │
│   │   • Invalid receipts are detectable                                            │  │
│   │   • Slashing is automatic                                                      │  │
│   │   • Cannot hide attack from network                                            │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ATTACK COMPLEXITY COMPARISON                                                          │
│   ════════════════════════════                                                          │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   System          │ Resources to Control │ Attack Complexity                   │  │
│   │   ────────────────┼──────────────────────┼─────────────────────────────────────│  │
│   │   Pure PoW        │ Hashrate only        │ Single resource                     │  │
│   │   Pure PoS        │ Stake only           │ Single resource                     │  │
│   │   Mbongo (Hybrid) │ Stake AND Compute    │ Two independent resources           │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   Mbongo's hybrid model requires attackers to simultaneously compromise               │
│   TWO independent economic systems, effectively squaring the attack cost.              │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

3.3 Why Compute Receipts Add Determinism

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         COMPUTE RECEIPTS AND DETERMINISM                                │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   WHAT IS A COMPUTE RECEIPT?                                                            │
│   ══════════════════════════                                                            │
│                                                                                         │
│   A compute receipt is a cryptographic attestation that:                               │
│   • A specific computation was performed                                               │
│   • By a registered GPU provider                                                       │
│   • With a verifiable result hash                                                      │
│   • Signed by attesters                                                                │
│                                                                                         │
│                                                                                         │
│   HOW RECEIPTS ADD DETERMINISM                                                          │
│   ════════════════════════════                                                          │
│                                                                                         │
│   1. VERIFIABLE EXECUTION                                                               │
│      • Receipt includes result_hash                                                    │
│      • Anyone can re-execute and verify                                                │
│      • Mismatch = fraud proof                                                          │
│                                                                                         │
│   2. IMMUTABLE RECORD                                                                   │
│      • Receipts stored on-chain                                                        │
│      • Cannot be altered retroactively                                                 │
│      • Full audit trail                                                                │
│                                                                                         │
│   3. ECONOMIC BINDING                                                                   │
│      • Provider stake backs receipt validity                                           │
│      • Invalid receipt → slashing                                                      │
│      • Economic incentive for correctness                                              │
│                                                                                         │
│   4. CONSENSUS INTEGRATION                                                              │
│      • Receipts contribute to block validity                                           │
│      • Validators verify receipt authenticity                                          │
│      • Invalid blocks with bad receipts rejected                                       │
│                                                                                         │
│                                                                                         │
│   DETERMINISM GUARANTEE                                                                 │
│   ═════════════════════                                                                 │
│                                                                                         │
│   For any compute task T with receipt R:                                               │
│   • Execute(T) on any compliant node → result_hash H                                   │
│   • R.result_hash MUST equal H                                                         │
│   • If R.result_hash ≠ H → R is INVALID → Provider slashed                            │
│                                                                                         │
│   This creates a deterministic, verifiable compute layer.                              │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

4. Attack Scenarios and Economic Costs

4.1 Attack Analysis

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         ATTACK SCENARIO ANALYSIS                                        │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   ATTACK 1: LONG-RANGE ATTACK                                                   │  │
│   │   ═══════════════════════════                                                   │  │
│   │                                                                                 │  │
│   │   Description:                                                                  │  │
│   │   Attacker creates alternate chain from historical point using old keys        │  │
│   │                                                                                 │  │
│   │   Mitigation:                                                                   │  │
│   │   • Deterministic compute receipts anchor chain to real work                   │  │
│   │   • Checkpoints prevent deep reorganizations                                   │  │
│   │   • Slashing for equivocation detectable                                       │  │
│   │   • Unbonding period (21 days) prevents quick exit                             │  │
│   │                                                                                 │  │
│   │   Why Attack Fails:                                                             │  │
│   │   • Cannot forge historical compute receipts                                   │  │
│   │   • Old validators' keys are known; equivocation detected                      │  │
│   │   • Economic cost of slashing exceeds potential gain                           │  │
│   │                                                                                 │  │
│   │   Required Resources: Historical keys + stake + fake receipts                  │  │
│   │   Success Probability: < 0.01%                                                 │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   ATTACK 2: COMPUTE FRAUD                                                       │  │
│   │   ═══════════════════════                                                       │  │
│   │                                                                                 │  │
│   │   Description:                                                                  │  │
│   │   GPU provider submits invalid compute receipts                                │  │
│   │                                                                                 │  │
│   │   Mitigation:                                                                   │  │
│   │   • Proof-based verification (replicated compute or ZK)                        │  │
│   │   • Probabilistic sampling catches fraud                                       │  │
│   │   • Attesters independently verify before signing                              │  │
│   │   • 1,000 MBO fixed slashing per invalid receipt                               │  │
│   │                                                                                 │  │
│   │   Why Attack Fails:                                                             │  │
│   │   • Detection probability is high (sampling)                                   │  │
│   │   • Cost of slashing exceeds fraudulent reward                                 │  │
│   │   • Reputation damage prevents future participation                            │  │
│   │                                                                                 │  │
│   │   Required Resources: GPU capacity + willingness to lose stake                 │  │
│   │   Success Probability: < 1% per receipt                                        │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   ATTACK 3: STAKE GRINDING                                                      │  │
│   │   ════════════════════════                                                      │  │
│   │                                                                                 │  │
│   │   Description:                                                                  │  │
│   │   Attacker manipulates randomness to gain unfair advantage in leader selection │  │
│   │                                                                                 │  │
│   │   Mitigation:                                                                   │  │
│   │   • Fixed stake snapshots (no last-minute changes)                             │  │
│   │   • Deterministic randomness from block hashes                                 │  │
│   │   • VRF-based leader selection (future)                                        │  │
│   │   • Compute receipts add entropy                                               │  │
│   │                                                                                 │  │
│   │   Why Attack Fails:                                                             │  │
│   │   • Cannot predict or manipulate future randomness                             │  │
│   │   • Snapshot prevents stake repositioning                                      │  │
│   │   • Deterministic selection is verifiable                                      │  │
│   │                                                                                 │  │
│   │   Required Resources: Prediction of future randomness                          │  │
│   │   Success Probability: < 0.1%                                                  │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   ATTACK 4: SPAM / DoS ATTACK                                                   │  │
│   │   ═══════════════════════════                                                   │  │
│   │                                                                                 │  │
│   │   Description:                                                                  │  │
│   │   Attacker floods network with transactions to exhaust resources               │  │
│   │                                                                                 │  │
│   │   Mitigation:                                                                   │  │
│   │   • Minimum gas price enforced                                                 │  │
│   │   • Exponential cost scaling for repeated spam                                 │  │
│   │   • Per-address rate limiting                                                  │  │
│   │   • 1% reserved block space for system messages                                │  │
│   │                                                                                 │  │
│   │   Why Attack Fails:                                                             │  │
│   │   • Cost scales exponentially with spam volume                                 │  │
│   │   • All fees are burned (attacker loses money)                                 │  │
│   │   • System messages always processed                                           │  │
│   │                                                                                 │  │
│   │   Required Resources: Large MBO holdings to burn                               │  │
│   │   Success Probability: < 5% (temporary disruption only)                        │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

4.2 Attack Cost Summary Table

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                        ATTACK ECONOMICS                                                                     │
├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                                                                             │
│   Attack Type          │ Required Resources                    │ Minimum Cost              │ Success Probability │ Economic Rationality   │
│   ─────────────────────┼───────────────────────────────────────┼───────────────────────────┼─────────────────────┼─────────────────────────│
│                        │                                       │                           │                     │                         │
│   Long-Range Attack    │ >1/3 historical stake + fake receipts │ >10M MBO + detection risk │ < 0.01%             │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   Compute Fraud        │ GPU capacity + stake collateral       │ >1,000 MBO per attempt    │ < 1%                │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   Stake Grinding       │ Prediction capability + stake         │ N/A (impossible)          │ < 0.1%              │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   Spam / DoS           │ Large MBO holdings                    │ Exponential with volume   │ < 5% (temporary)    │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   Double Signing       │ Validator keys                        │ 5% stake slashing         │ 0% (always caught)  │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   51% Stake Attack     │ >50% of staked MBO                    │ >15M MBO + market impact  │ < 10%               │ ✗ Irrational            │
│                        │                                       │                           │                     │                         │
│   Combined PoS+PoUW    │ >50% stake + >50% compute             │ >20M MBO + GPU farms      │ < 1%                │ ✗ Extremely Irrational  │
│                        │                                       │                           │                     │                         │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

4.3 Key Insight

All known attacks are economically irrational. The cost of attack exceeds any potential gain, and the probability of success is negligible. Rational actors will choose to participate honestly.


5. Economic Finality Model

5.1 What is Economic Finality?

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         ECONOMIC FINALITY                                               │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   DEFINITION                                                                            │
│   ══════════                                                                            │
│                                                                                         │
│   Economic finality occurs when reversing a block would require destroying more        │
│   economic value than could possibly be gained from the reversal.                      │
│                                                                                         │
│   In Mbongo Chain:                                                                      │
│   • Finality = Validators converged + Compute receipts verified                        │
│   • Reversal requires >1/3 stake to be slashed                                         │
│   • Slashing amount > potential double-spend gain                                      │
│                                                                                         │
│                                                                                         │
│   FINALITY CONDITION                                                                    │
│   ══════════════════                                                                    │
│                                                                                         │
│   A block B is economically final when:                                                │
│                                                                                         │
│   1. 2/3+ of stake voted PRECOMMIT for B                                               │
│   2. All compute receipts in B are verified                                            │
│   3. Reverting B requires slashing >1/3 of validators                                  │
│   4. Slashing cost > maximum extractable value from reversal                           │
│                                                                                         │
│                                                                                         │
│   FORMAL EXPRESSION                                                                     │
│   ══════════════════                                                                    │
│                                                                                         │
│   Block B is final iff:                                                                │
│                                                                                         │
│   Cost_to_Revert(B) > Max_Extractable_Value(B)                                         │
│                                                                                         │
│   Where:                                                                                │
│   Cost_to_Revert(B) = Σ (stake[v] × slash_rate) for all validators who must equivocate│
│   Max_Extractable_Value(B) = Max double-spend + MEV from reverting B                   │
│                                                                                         │
│   For Mbongo: Cost_to_Revert >> Max_Extractable_Value (by design)                      │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

5.2 Why Receipts Cannot Be Forged

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         RECEIPT INTEGRITY                                               │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   CRYPTOGRAPHIC BINDING                                                                 │
│   ═════════════════════                                                                 │
│                                                                                         │
│   1. RESULT HASH                                                                        │
│      • Receipt contains hash of computation result                                     │
│      • Hash function is collision-resistant                                            │
│      • Cannot find different result with same hash                                     │
│                                                                                         │
│   2. ATTESTER SIGNATURES                                                                │
│      • Multiple attesters sign each receipt                                            │
│      • Signatures are Ed25519 (cryptographically secure)                               │
│      • Cannot forge valid signature without private key                                │
│                                                                                         │
│   3. PROVIDER IDENTITY                                                                  │
│      • Provider ID is cryptographically derived                                        │
│      • Bound to registered public key                                                  │
│      • Cannot impersonate another provider                                             │
│                                                                                         │
│                                                                                         │
│   VERIFICATION CHAIN                                                                    │
│   ══════════════════                                                                    │
│                                                                                         │
│   For a receipt R to be valid:                                                         │
│   ✓ R.provider_id ∈ registered_providers                                               │
│   ✓ R.result_hash = hash(re_execute(R.task))                                           │
│   ✓ ∀ sig ∈ R.signatures: verify(sig, R.message, attester_pubkey) = TRUE               │
│   ✓ count(valid_signatures) ≥ threshold                                                │
│                                                                                         │
│   Forging requires:                                                                     │
│   • Breaking hash function (computationally infeasible)                                │
│   • Stealing attester private keys (requires compromise)                               │
│   • Corrupting majority of attesters (requires massive coordination)                   │
│                                                                                         │
│   Probability of successful forgery: Negligible (< 2^-128)                             │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

5.3 Why Reverting Final Blocks is Irrational

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         REVERSION ECONOMICS                                             │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   TO REVERT A FINAL BLOCK, AN ATTACKER MUST:                                           │
│   ════════════════════════════════════════════                                          │
│                                                                                         │
│   1. Control >1/3 of stake (to prevent finalization of honest chain)                   │
│   2. Produce valid compute receipts for alternate chain                                │
│   3. Convince other validators to switch (or control >2/3 alone)                       │
│   4. Accept slashing of their entire stake                                             │
│                                                                                         │
│                                                                                         │
│   COST-BENEFIT ANALYSIS                                                                 │
│   ═════════════════════                                                                 │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   COSTS OF REVERSION                                                            │  │
│   │   ────────────────────                                                          │  │
│   │   • Stake slashing: 5%+ of colluding validators                                │  │
│   │   • Market impact: MBO price crash from detected attack                        │  │
│   │   • Opportunity cost: Lost future staking rewards                              │  │
│   │   • Reputation: Permanent ban from network                                     │  │
│   │   • Legal risk: Potential fraud charges                                        │  │
│   │                                                                                 │  │
│   │   POTENTIAL GAINS                                                               │  │
│   │   ───────────────                                                               │  │
│   │   • Double-spend: Value of reversed transactions                               │  │
│   │   • MEV: Extractable value from reordering                                     │  │
│   │                                                                                 │  │
│   │   COMPARISON                                                                    │  │
│   │   ──────────                                                                    │  │
│   │   For any realistic scenario:                                                  │  │
│   │   Costs >> Gains                                                               │  │
│   │                                                                                 │  │
│   │   Example:                                                                      │  │
│   │   • Attacker controls 35% of stake (10.5M MBO)                                 │  │
│   │   • Slashing cost: 5% × 10.5M = 525,000 MBO                                    │  │
│   │   • Maximum double-spend: Limited by single block value                        │  │
│   │   • Typical block value: << 525,000 MBO                                        │  │
│   │                                                                                 │  │
│   │   Result: Attack is economically irrational                                    │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

5.4 Finality Diagram

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         FINALITY FLOW                                                   │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│                                                                                         │
│   ┌───────────────┐                                                                    │
│   │ BLOCK PROPOSED│                                                                    │
│   │               │                                                                    │
│   │ • Transactions│                                                                    │
│   │ • Receipts    │                                                                    │
│   └───────┬───────┘                                                                    │
│           │                                                                            │
│           ▼                                                                            │
│   ┌───────────────────────────────────────────────────────────────────────────────┐   │
│   │                                                                               │   │
│   │                          VALIDATION PHASE                                     │   │
│   │                                                                               │   │
│   │   ┌───────────────────┐          ┌───────────────────┐                       │   │
│   │   │ TRANSACTION       │          │ COMPUTE RECEIPT   │                       │   │
│   │   │ VALIDATION        │          │ VERIFICATION      │                       │   │
│   │   │                   │          │                   │                       │   │
│   │   │ ✓ Signatures      │          │ ✓ Provider valid  │                       │   │
│   │   │ ✓ Balances        │          │ ✓ Result hash     │                       │   │
│   │   │ ✓ Nonces          │          │ ✓ Attester sigs   │                       │   │
│   │   └───────────────────┘          └───────────────────┘                       │   │
│   │                                                                               │   │
│   └───────────────────────────────────────────────────────────────────────────────┘   │
│           │                                                                            │
│           ▼                                                                            │
│   ┌───────────────────────────────────────────────────────────────────────────────┐   │
│   │                                                                               │   │
│   │                          CONSENSUS PHASE                                      │   │
│   │                                                                               │   │
│   │   ┌─────────────┐      ┌─────────────┐      ┌─────────────┐                  │   │
│   │   │   PREVOTE   │ ───▶ │  PRECOMMIT  │ ───▶ │   COMMIT    │                  │   │
│   │   │             │      │             │      │             │                  │   │
│   │   │  >2/3 vote  │      │  >2/3 vote  │      │  Finalized  │                  │   │
│   │   └─────────────┘      └─────────────┘      └─────────────┘                  │   │
│   │                                                                               │   │
│   └───────────────────────────────────────────────────────────────────────────────┘   │
│           │                                                                            │
│           ▼                                                                            │
│   ╔═══════════════════════════════════════════════════════════════════════════════╗   │
│   ║                                                                               ║   │
│   ║                        ECONOMIC FINALITY ACHIEVED                             ║   │
│   ║                                                                               ║   │
│   ║   • 2/3+ validators committed                                                 ║   │
│   ║   • All receipts verified                                                     ║   │
│   ║   • Reversion cost > extractable value                                        ║   │
│   ║   • Block is IRREVERSIBLE                                                     ║   │
│   ║                                                                               ║   │
│   ╚═══════════════════════════════════════════════════════════════════════════════╝   │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

6. Role of Slashing

6.1 Slashing Overview

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         SLASHING MECHANISM                                              │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   PURPOSE                                                                               │
│   ═══════                                                                               │
│                                                                                         │
│   Slashing enforces honest behavior by making misbehavior economically painful.        │
│   It transforms security from "trust" to "verify and punish."                          │
│                                                                                         │
│   PROPERTIES                                                                            │
│   ══════════                                                                            │
│                                                                                         │
│   • DETERMINISTIC: Same evidence → same penalty on all nodes                           │
│   • AUTOMATIC: No human judgment required                                              │
│   • IRREVERSIBLE: Slashed stake is permanently destroyed                               │
│   • TRANSPARENT: All slashing events recorded on-chain                                 │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

6.2 Slashing Conditions

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         SLASHING CONDITIONS                                             │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   DOUBLE-SIGNING (EQUIVOCATION)                                                 │  │
│   │   ═════════════════════════════                                                 │  │
│   │                                                                                 │  │
│   │   Penalty: 5% of validator stake                                               │  │
│   │                                                                                 │  │
│   │   Trigger:                                                                      │  │
│   │   • Validator signs two conflicting blocks at same height                      │  │
│   │   • Validator signs conflicting PREVOTE or PRECOMMIT                           │  │
│   │                                                                                 │  │
│   │   Evidence:                                                                     │  │
│   │   • Two valid signatures from same validator                                   │  │
│   │   • On conflicting data at same height/round                                   │  │
│   │                                                                                 │  │
│   │   Additional Consequences:                                                      │  │
│   │   • Validator jailed for 30 days                                               │  │
│   │   • Cannot participate in consensus during jail                                │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   DOWNTIME (LIVENESS FAILURE)                                                   │  │
│   │   ═══════════════════════════                                                   │  │
│   │                                                                                 │  │
│   │   Penalty: 0.5% of validator stake                                             │  │
│   │                                                                                 │  │
│   │   Trigger:                                                                      │  │
│   │   • Validator offline for >500 consecutive blocks (~8 hours)                   │  │
│   │   • Validator fails to sign attestations                                       │  │
│   │                                                                                 │  │
│   │   Evidence:                                                                     │  │
│   │   • Absence of validator signatures in block headers                           │  │
│   │   • Automatic detection by protocol                                            │  │
│   │                                                                                 │  │
│   │   Additional Consequences:                                                      │  │
│   │   • Validator jailed for 1 hour                                                │  │
│   │   • Escalating penalties for repeated offenses                                 │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

6.3 Burn (Not Redistribute)

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         SLASHED STAKE IS BURNED                                         │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ╔═════════════════════════════════════════════════════════════════════════════════╗  │
│   ║                                                                                 ║  │
│   ║   SLASHED MBO IS PERMANENTLY DESTROYED                                          ║  │
│   ║                                                                                 ║  │
║   ║   • NOT given to reporter                                                      ║  │
│   ║   • NOT redistributed to other validators                                      ║  │
│   ║   • NOT sent to treasury                                                       ║  │
│   ║   • Sent to null address and removed from circulation                          ║  │
│   ║                                                                                 ║  │
│   ╚═════════════════════════════════════════════════════════════════════════════════╝  │
│                                                                                         │
│   WHY BURN INSTEAD OF REDISTRIBUTE?                                                     │
│   ══════════════════════════════════                                                    │
│                                                                                         │
│   1. PREVENTS PERVERSE INCENTIVES                                                       │
│      • No profit motive for false accusations                                          │
│      • No collusion to slash and share proceeds                                        │
│      • No "slashing as a service" attacks                                              │
│                                                                                         │
│   2. BENEFITS ALL HOLDERS                                                               │
│      • Reduced supply increases scarcity                                               │
│      • All MBO holders benefit proportionally                                          │
│      • Fairer than redistributing to subset                                            │
│                                                                                         │
│   3. SIMPLIFIES PROTOCOL                                                                │
│      • No complex distribution logic                                                   │
│      • No disputes over who receives slashed stake                                     │
│      • Deterministic outcome                                                           │
│                                                                                         │
│   ECONOMIC EFFECT                                                                       │
│   ═══════════════                                                                       │
│                                                                                         │
│   slashing_event → circulating_supply ↓ → scarcity ↑ → value ↑                         │
│                                                                                         │
│   Slashing benefits the entire network, not specific parties.                          │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

6.4 Economic Discipline

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         STRICT ECONOMIC DISCIPLINE                                      │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   HOW SLASHING CREATES DISCIPLINE                                                       │
│   ═══════════════════════════════                                                       │
│                                                                                         │
│   1. CERTAINTY OF PUNISHMENT                                                            │
│      • Evidence-based detection is deterministic                                       │
│      • Cannot bribe way out of slashing                                                │
│      • Cannot negotiate or appeal                                                      │
│      • Penalty is automatic and immediate                                              │
│                                                                                         │
│   2. PROPORTIONAL PAIN                                                                  │
│      • 5% slash for double-signing is significant                                      │
│      • For 100,000 MBO stake: 5,000 MBO lost                                           │
│      • Pain exceeds any benefit from attack                                            │
│                                                                                         │
│   3. REPUTATION DAMAGE                                                                  │
│      • Slashing events are public                                                      │
│      • Delegators will flee slashed validators                                         │
│      • Long-term income destroyed                                                      │
│                                                                                         │
│   4. GAME THEORY                                                                        │
│      • Honest behavior: Expected reward > 0                                            │
│      • Malicious behavior: Expected reward < 0                                         │
│      • Rational actors choose honesty                                                  │
│                                                                                         │
│                                                                                         │
│   EXPECTED VALUE COMPARISON                                                             │
│   ═════════════════════════                                                             │
│                                                                                         │
│   Honest Validator:                                                                    │
│   E[reward] = block_rewards + fees + appreciation                                      │
│   E[risk] = minimal (only operational risk)                                            │
│   E[value] = POSITIVE                                                                  │
│                                                                                         │
│   Malicious Validator:                                                                 │
│   E[reward] = potential_exploit_value × P(success)                                     │
│   E[risk] = stake × slash_rate × P(detection)                                          │
│   E[value] = NEGATIVE (since P(detection) ≈ 100%)                                      │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

6.5 Slashing Summary Table

Offense Penalty Destination Jail Time Detection
Double-Signing 5% stake BURNED 30 days Evidence-based
Downtime 0.5% stake BURNED 1 hour Automatic
Invalid Compute 1,000 MBO BURNED 7 days Verification
Repeated Offenses Escalating BURNED Permanent Cumulative

7. Long-Term Stability (50-Year Horizon)

7.1 Stability Factors

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         50-YEAR STABILITY ANALYSIS                                      │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   FACTOR 1: NO INFLATION                                                        │  │
│   │   ══════════════════════                                                        │  │
│   │                                                                                 │  │
│   │   • Total supply fixed at 31,536,000 MBO                                       │  │
│   │   • No mechanism to create new tokens                                          │  │
│   │   • Existing holders never diluted                                             │  │
│   │                                                                                 │  │
│   │   50-Year Implication:                                                          │  │
│   │   Your percentage ownership cannot decrease due to inflation.                  │  │
│   │   If you hold 1% today, you hold ≥1% in 50 years.                              │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   FACTOR 2: DECLINING SUPPLY (via burns)                                        │  │
│   │   ══════════════════════════════════════                                        │  │
│   │                                                                                 │  │
│   │   • Every transaction burns base fees                                          │  │
│   │   • Slashing destroys stake                                                    │  │
│   │   • No mechanism to recover burned MBO                                         │  │
│   │                                                                                 │  │
│   │   50-Year Implication:                                                          │  │
│   │   Circulating supply will be LESS than 31,536,000 MBO.                         │  │
│   │   Potentially significantly less if network is heavily used.                   │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   FACTOR 3: DETERMINISTIC RELEASE SCHEDULES                                     │  │
│   │   ═════════════════════════════════════════                                     │  │
│   │                                                                                 │  │
│   │   • Block rewards follow halving schedule                                      │  │
│   │   • Vesting schedules are fixed                                                │  │
│   │   • No surprises or discretionary releases                                     │  │
│   │                                                                                 │  │
│   │   50-Year Implication:                                                          │  │
│   │   You can calculate exact issuance at any future date.                         │  │
│   │   Economic planning is possible with certainty.                                │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   FACTOR 4: FEE BURN EQUILIBRIUM                                                │  │
│   │   ══════════════════════════════                                                │  │
│   │                                                                                 │  │
│   │   • High usage → more burns → lower supply → higher value                      │  │
│   │   • Low usage → fewer burns → stable supply → stable value                     │  │
│   │   • Self-regulating economic system                                            │  │
│   │                                                                                 │  │
│   │   50-Year Implication:                                                          │  │
│   │   Network success is automatically reflected in token value.                   │  │
│   │   No need for external intervention.                                           │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

7.2 Why This Supports High-Value Applications

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         HIGH-VALUE APPLICATION SUPPORT                                  │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   REQUIREMENTS FOR HIGH-VALUE APPLICATIONS                                              │
│   ════════════════════════════════════════                                              │
│                                                                                         │
│   1. PREDICTABLE ECONOMICS                                                              │
│      ✓ Mbongo: Fixed supply, known issuance schedule                                   │
│                                                                                         │
│   2. LONG-TERM VALUE STABILITY                                                          │
│      ✓ Mbongo: Deflationary pressure, no inflation                                     │
│                                                                                         │
│   3. SECURITY GUARANTEES                                                                │
│      ✓ Mbongo: Economic finality, slashing enforcement                                 │
│                                                                                         │
│   4. DETERMINISTIC EXECUTION                                                            │
│      ✓ Mbongo: Reproducible state transitions                                          │
│                                                                                         │
│   5. COMPUTE AVAILABILITY                                                               │
│      ✓ Mbongo: PoUW incentivizes compute provision                                     │
│                                                                                         │
│                                                                                         │
│   APPLICATIONS ENABLED                                                                  │
│   ════════════════════                                                                  │
│                                                                                         │
│   • DeFi: Billions in TVL require predictable economics                               │
│   • AI/ML: Compute marketplace needs stable pricing                                    │
│   • Enterprise: Long-term contracts need reliability                                   │
│   • Cross-chain: Bridges need finality guarantees                                      │
│   • Gaming: Virtual economies need stable base currency                                │
│                                                                                         │
│                                                                                         │
│   50-YEAR VIABILITY                                                                     │
│   ═════════════════                                                                     │
│                                                                                         │
│   ┌─────────────────────────────────────────────────────────────────────────────────┐  │
│   │                                                                                 │  │
│   │   Year 1-10:   Bootstrap phase, block rewards dominant                         │  │
│   │   Year 11-25:  Transition phase, fees becoming significant                     │  │
│   │   Year 26-50:  Mature phase, fee-based security model                          │  │
│   │   Year 50+:    Sustainable indefinitely                                        │  │
│   │                                                                                 │  │
│   │   At no point does the economic model break down or require intervention.      │  │
│   │                                                                                 │  │
│   └─────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

8. Summary for Auditors and Researchers

8.1 Executive Summary

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         AUDITOR & RESEARCHER SUMMARY                                    │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   DETERMINISTIC ECONOMIC SYSTEM                                                         │
│   ═════════════════════════════                                                         │
│                                                                                         │
│   • All economic rules are algorithmically defined                                     │
│   • Same inputs → same outputs on all nodes                                            │
│   • No randomness in fee/reward calculations                                           │
│   • Integer arithmetic only (no floating-point)                                        │
│   • Reproducible execution for any historical block                                    │
│                                                                                         │
│                                                                                         │
│   NO DISCRETIONARY INTERVENTIONS                                                        │
│   ══════════════════════════════                                                        │
│                                                                                         │
│   • No admin keys can modify economic parameters                                       │
│   • No governance can increase supply                                                  │
│   • No Foundation can override slashing                                                │
│   • No emergency mechanisms for economic changes                                       │
│   • Protocol rules are the only authority                                              │
│                                                                                         │
│                                                                                         │
│   MATHEMATICALLY BOUNDED RISK                                                           │
│   ═══════════════════════════                                                           │
│                                                                                         │
│   • Total supply bounded: ≤ 31,536,000 MBO                                             │
│   • Slashing penalties bounded: 0.5% - 5% per offense                                  │
│   • Attack costs calculable: Cost > Gain for all known attacks                         │
│   • Finality is economic: Reversion cost exceeds extractable value                     │
│                                                                                         │
│                                                                                         │
│   HYBRID CONSENSUS SECURITY                                                             │
│   ═════════════════════════                                                             │
│                                                                                         │
│   • 50% PoS: Stake-based Sybil resistance                                              │
│   • 50% PoUW: Compute-based verification layer                                         │
│   • Dual resources required for attack (multiplicative security)                       │
│   • BFT-style finality with >2/3 honest assumption                                     │
│                                                                                         │
│                                                                                         │
│   COMPUTE-FIRST EXECUTION GUARANTEES                                                    │
│   ════════════════════════════════════                                                  │
│                                                                                         │
│   • Compute receipts provide verifiable work proofs                                    │
│   • Results are independently reproducible                                             │
│   • Invalid compute triggers deterministic slashing                                    │
│   • GPU providers have economic stake in correctness                                   │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

8.2 Key Properties Checklist

Property Status Verification Method
Fixed Supply ✓ Guaranteed total_supply ≤ 31,536,000
No Inflation ✓ Guaranteed No mint function exists
Deterministic Execution ✓ Guaranteed Replay any block
Economic Finality ✓ Guaranteed Cost analysis
Slashing Enforcement ✓ Guaranteed Evidence-based
Fee Burning ✓ Guaranteed Base fees → null address
50/50 Split ✓ Guaranteed Protocol-enforced
No Admin Keys ✓ Guaranteed Code audit

8.3 Formal Security Claims

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         FORMAL SECURITY CLAIMS                                          │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   CLAIM 1: SUPPLY INVARIANT                                                             │
│   ─────────────────────────                                                             │
│   ∀t: Σ(all MBO at time t) ≤ 31,536,000                                                │
│                                                                                         │
│   CLAIM 2: ECONOMIC FINALITY                                                            │
│   ──────────────────────────                                                            │
│   ∀ block B: Cost_to_Revert(B) > Max_Extractable_Value(B)                              │
│                                                                                         │
│   CLAIM 3: DETERMINISTIC SLASHING                                                       │
│   ───────────────────────────────                                                       │
│   ∀ evidence E: Verify(E) = TRUE → Slash(E.validator) is AUTOMATIC                     │
│                                                                                         │
│   CLAIM 4: NO DISCRETIONARY MINTING                                                     │
│   ─────────────────────────────────                                                     │
│   ∄ function F: F() → increase(total_supply)                                           │
│                                                                                         │
│   CLAIM 5: ATTACK IRRATIONALITY                                                         │
│   ─────────────────────────────                                                         │
│   ∀ attack A: Expected_Cost(A) > Expected_Gain(A)                                      │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

8.4 Recommended Audit Focus Areas

  1. Supply Constraints: Verify no code path can create MBO beyond block rewards
  2. Slashing Logic: Verify evidence validation is correct and automatic
  3. Fee Calculations: Verify integer arithmetic and overflow protection
  4. Receipt Verification: Verify compute receipt validation is complete
  5. Finality Logic: Verify 2/3+ threshold is correctly enforced
  6. Burn Mechanism: Verify base fees are sent to null address

Appendix: Quick Reference

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                         ECONOMIC SECURITY QUICK REFERENCE                               │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                         │
│   SUPPLY                                                                                │
│   ──────                                                                                │
│   Total:         31,536,000 MBO (fixed forever)                                        │
│   Inflation:     0% (no minting)                                                       │
│   Deflationary:  Yes (fee burning)                                                     │
│                                                                                         │
│   SECURITY MODEL                                                                        │
│   ──────────────                                                                        │
│   PoS Weight:    50%                                                                   │
│   PoUW Weight:   50%                                                                   │
│   Finality:      Economic (2/3+ stake + verified receipts)                             │
│                                                                                         │
│   SLASHING                                                                              │
│   ────────                                                                              │
│   Double-Sign:   5% stake → BURNED                                                     │
│   Downtime:      0.5% stake → BURNED                                                   │
│   Detection:     Automatic, evidence-based                                             │
│                                                                                         │
│   FEES                                                                                  │
│   ────                                                                                  │
│   Base Fee:      100% BURNED                                                           │
│   Priority Fee:  To validator/provider                                                 │
│                                                                                         │
│   ATTACK COSTS                                                                          │
│   ────────────                                                                          │
│   51% PoS:       >15M MBO + slashing risk                                              │
│   Compute Fraud: 1,000 MBO per attempt + detection                                     │
│   Spam:          Exponential cost scaling                                              │
│                                                                                         │
│   GUARANTEES                                                                            │
│   ──────────                                                                            │
│   ✓ Deterministic execution                                                            │
│   ✓ No discretionary intervention                                                      │
│   ✓ Mathematically bounded risk                                                        │
│   ✓ Hybrid consensus security                                                          │
│   ✓ Compute-first verification                                                         │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘

Related Documentation

Document Description
tokenomics.md Canonical economic specification
supply_schedule.md Emission schedule
staking_model.md Staking specification
fee_model.md Fee structure
consensus_master_overview.md Consensus details

This document defines the economic security model for Mbongo Chain. All security properties are enforced by protocol rules and verifiable on-chain.