Economy Simulation — Reference

Language-agnostic reference extracted from Phoenix Python source. Source file: simulate_economy.py (integration harness, exact size not listed in port-map).


1. Purpose

simulate_economy.py is the only integration-level test corpus that exercises the full Phoenix algorithm stack together. It serves as:

  1. A functional specification — proves the algorithms work as designed end-to-end
  2. A regression baseline — any port must produce identical results on the same scenarios
  3. A parameter validation tool — verifies that BPS constants, decay rates, and thresholds produce correct equilibrium behavior
  4. The only runnable BFT/reputation test environment before Colibri implements these algorithms in Node.js

2. Test Scenarios the Simulation Validates

Scenario 1: Reputation Growth and Decay

Setup:    3 nodes (Alice, Bob, Charlie); 100 epochs; Alice active, Bob inactive
Expected: Alice's reputation grows in action domains; Bob's decays at configured rates
Validates: apply_decay(), tiered gain ceiling, domain independence

Scenario 2: Token Promotion L0 → L1 → L2 → L3

Setup:    1 node completes commit→deliver→confirm 10 times; 5 same-pattern repetitions
Expected: L0 minted on first event; L1 after first full cycle; L2a after 5 patterns;
          L2b after diversity requirement met; L3 on L2b promotion
Validates: token hierarchy, minting conditions, L2a/L2b distinction, L3 permanence

Scenario 3: Fork Creation and Merge

Setup:    4 nodes; rule version conflict introduced at epoch 20
Expected: fork created with RULE_VERSION_CONFLICT reason; fork accumulates 5 epochs;
          merge protocol initiated; checkpoint signed by 7/10 arbiters;
          merged state applies 50% rep discount
Validates: fork_id derivation, isolation modes, checkpoint threshold, merge protocol

Scenario 4: Governance Proposal Lifecycle

Setup:    5 nodes; one ECONOMICS proposal; 3 votes FOR, 1 AGAINST, 1 ABSTAIN
Expected: proposal activates; quadratic vote tallied;
          if FOR weight >= 66%: PASSED → time-lock → execute
          if not: REJECTED
Validates: quadratic voting (cost=v², power=sqrt(c)), 66% threshold, time-lock stages

Scenario 5: Arbitration with VRF Arbiter Selection

Setup:    10 nodes (3 eligible arbiters); L0 dispute between Alice and Bob
Expected: 3 arbiters selected via VRF deterministically; commit-reveal voting;
          majority ruling applied; loser stake distributed; arbiters earn rep
Validates: VRF selection, anti-collusion cap, commit-reveal, stake distribution

Scenario 6: Offense Penalty and Scar Application

Setup:    1 node; FRAUD offense applied
Expected: 100% penalty (10000 bps); permanent scar; ban applied; max_score locked
Validates: calculate_damage(), scar rules, double-jeopardy protection

Scenario 7: Anti-Bias Dampening

Setup:    1 node earns arbitration rep exclusively from 1 counterparty (>90% correlation)
Expected: gains reduced by 50% once correlation threshold exceeded
Validates: compute_counterparty_correlation(), anti-bias reduction

Scenario 8: Sentinel Dampening

Setup:    1 node flagged WARN; then flagged CRITICAL; rep gains attempted
Expected: WARN node earns 50% of normal gains; CRITICAL node earns 0%
Validates: apply_sentinel_dampening(), SentinelStatus enum

3. What the Simulation Proves

Property Proved By
Reputation is bounded (0 to max_score) Scenarios 1, 6
Decay is monotonic downward from inactivity Scenario 1
Token hierarchy is enforced (L2a → L2b → L3, not L2a → L3) Scenario 2
Fork IDs are deterministic (same inputs = same ID) Scenario 3
Fork merge applies correct rep discount Scenario 3
Quadratic voting prevents vote accumulation attacks Scenario 4
VRF arbiter selection is deterministic and verifiable Scenario 5
Anti-oligarchy cap holds (max 30% same entity) Scenario 5
Scar is permanent (max_score never increases after fraud) Scenario 6
Anti-bias triggers correctly at 90% correlation Scenario 7
Sentinel dampening is advisory (does not block, only reduces) Scenario 8

4. How to Replicate as a Node.js Integration Test Suite

Each simulation scenario maps to one Node.js integration test file:

tests/integration/
  reputation-growth-decay.test.js          → Scenario 1
  token-promotion-hierarchy.test.js        → Scenario 2
  fork-create-merge.test.js                → Scenario 3
  governance-proposal-lifecycle.test.js    → Scenario 4
  arbitration-vrf-selection.test.js        → Scenario 5
  offense-penalty-scar.test.js             → Scenario 6
  anti-bias-dampening.test.js              → Scenario 7
  sentinel-dampening.test.js               → Scenario 8

Test Harness Pattern

// Node.js test harness pattern (equivalent to simulate_economy.py structure)

function setup_test_world(n_nodes: int, initial_rep?: Map) -> TestWorld:
    return {
        nodes:    [create_node(i) for i in range(n_nodes)],
        state:    empty_state(),
        epoch:    0,
        rule_version: "test-v1",
        fork_id:  GENESIS_FORK_ID,
    }

function advance_epoch(world: TestWorld, actions: Action[]):
    for action in actions:
        result = process_action(action.type, action.actor, world.state)
        apply_mutations(world.state, result.mutations)
    apply_decay_all(world.state, world.epoch)
    world.epoch += 1

// Each test:
// 1. setup_test_world(...)
// 2. advance_epoch(...) × N
// 3. assert specific state values match expected

Cross-Implementation Verification

The simulation acts as a golden corpus for cross-implementation verification:

1. Run simulate_economy.py → capture all state snapshots as JSON
2. Run Node.js test suite with same inputs
3. Compare outputs byte-for-byte
4. Any divergence = implementation bug

Determinism requirement: 10,000 random inputs → identical outputs across languages

5. Key Simulation Parameters

These are the constants that the simulation uses as ground truth. Any Node.js implementation must use the same values:

Parameter Value Notes
BPS_100_PERCENT 10000 100% in basis points
decay_rates_bps[EXECUTION] 500 5% per epoch
decay_rates_bps[COMMISSIONING] 300 3% per epoch
decay_rates_bps[ARBITRATION] 1000 10% per epoch
decay_rates_bps[GOVERNANCE] 200 2% per epoch
decay_rates_bps[SOCIAL] 100 1% per epoch
entropy_cap_bps 5000 Max 50% decay per epoch
ANTI_BIAS_THRESHOLD 0.90 90% correlation triggers dampening
ANTI_BIAS_REDUCTION_BPS 5000 50% gain reduction
SENTINEL_WARN_BPS 5000 50% of normal gain
SENTINEL_CRITICAL_BPS 0 0% of normal gain
WITNESS_MAX_WEIGHT 0.30 Max 30% per WitnessToken
WITNESS_PORTFOLIO_CAP 0.40 Max 40% of portfolio
SSS_SHARES 5 Guardian shares for recovery
SSS_THRESHOLD 3 Recovery requires 3 of 5
RECOVERY_REP_DISCOUNT_BPS 5000 50% rep discount on recovery
FORK_REP_DISCOUNT_BPS 5000 50% discount on fork-local gains at merge
CHECKPOINT_THRESHOLD 7 7 of 10 threshold signatures
CHECKPOINT_TOTAL 10 10 total signers for checkpoints
ARBITERS_REQUIRED[L0] 3 L0 dispute arbiter count
ARBITERS_REQUIRED[L1] 5 L1 dispute arbiter count
ARBITERS_REQUIRED[L2] 7 L2 dispute arbiter count
QUADRATIC_THRESHOLD 0.66 66% weighted votes to pass
APPEAL_STAKE_MULTIPLIER 2 Each appeal doubles required stake
ANTI_OLIGARCHY_CAP 0.30 Max 30% same entity in arbiter pool
TIME_LOCK_STAGE_1_EPOCHS 10 Stage 1 time-lock
TIME_LOCK_STAGE_2_EPOCHS 20 Stage 2 time-lock
TIME_LOCK_STAGE_3_EPOCHS 50 Stage 3 time-lock (INVARIANTS only)
FINALITY_QUORUM_TO_HARD_EPOCHS 100 Epochs from QUORUM to HARD
BLOOM_RESET_INTERVAL 1000 Reset Bloom filter every N events

6. Phase Completion Gate

Per phoenix-port-map.md:

Port simulation scenarios as integration tests for Phase 3 completion gate.

The simulation must be replicated as a Node.js test suite before Phase 3 (θ Consensus) is declared complete. This provides the only test corpus that exercises the full stack interaction between κ, λ, θ, ι, and π.


[[concepts/λ-reputation λ Reputation]] · [[spec/S04-reputation S04 Reputation Spec]] · [[guides/implementation/phoenix-port-map Phoenix Port Map]] · [[reference/extractions/lambda-reputation-extraction λ Extraction]] · [[reference/extractions/theta-consensus-extraction θ Extraction]] · [[reference/extractions/kappa-rule-engine-extraction κ Extraction]]

Back to top

Colibri — documentation-first MCP runtime. Apache 2.0 + Commons Clause.

This site uses Just the Docs, a documentation theme for Jekyll.