Economic Modeling for Mutual Credit Systems
Status: ✅ COMPLETE (Track B3) Last Updated: 2025-01-14 Simulation Results: sims/mutual-credit/RESULTS_SUMMARY.md
Purpose
Mutual credit systems have well-documented failure modes. Before deploying ICN's ledger in production, we need to:
- Catalog known failure modes from historical mutual credit systems
- Model agent behaviors that lead to system collapse
- Test economic parameters (credit limits, demurrage, default handling)
- Recommend defaults for Phase 12 (Economic Safety Rails)
This document guides the economic modeling parallel research track.
Simulation Results Summary (January 2025)
Framework Implemented: Agent-based model using Mesa 3.3.1 with 100 agents over 12 months across 5 scenarios.
Key Findings
| Intervention | Effect | Recommendation |
|---|---|---|
| Dynamic Credit Limits (2x trust multiplier) | -16% velocity, -33% defaults | ✅ Use for stability, accept lower volume |
| Demurrage (-2% monthly on >50) | -22% inequality (Gini), no velocity harm | ✅ Highly effective redistribution |
| High Free-Riders (20% vs 8%) | +51% defaults, system stressed but stable | ⚠️ System tolerates up to ~20% |
| Low Trust Network (30% density) | +100% hoarding, conservative behavior | ⚠️ Network density critical |
Validated Hypotheses
- ✅ Demurrage works: Reduced Gini from 0.36 to 0.28 without harming velocity
- ✅ Trust-gated limits reduce defaults: 1.8% vs 2.7% baseline
- ✅ System can tolerate free-riders: Up to 20% before serious stress
- ❌ Sparse networks reduce hoarding: WRONG - they increase it (counterintuitive but economically sound)
Recommended Defaults (Updated with Simulation Data)
Based on 5 scenarios with ~13,000 transactions each:
Credit Limits:
- Initial: -20 (validated - allows 2-4 small transactions)
- Maximum: -500 (validated - caps extreme exposure)
- Growth: +10 per 50 cleared (validated - agents reached -500 in 3-4 months)
- Trust multiplier: 2.0 (tested - provides meaningful differentiation)
Demurrage:
- Rate: -2% monthly on balances >50 (validated - reduces inequality 22%)
- Threshold: 50 credits (tested - exempts small savers)
- Application: Monthly (timing critical - must be synchronized)
New Member Protection:
- Initial limit: -20 (conservative, validated)
- Ramp period: 3 months (implemented in Phase 12)
- Contribution requirement: 10 credits cleared (Phase 12 feature)
Implementation Notes
All economic safety features from simulation are now implemented in ICN:
- Phase 12: Dynamic credit limits, new member throttling, dispute resolution
- Ledger: Double-entry with quarantine for conflicts
- Trust graph: Transitive trust computation with decay
See sims/mutual-credit/ for complete framework, scenarios, and analysis notebooks.
Known Failure Modes
1. Tragedy of the Credits (Hoarding / Deflation)
Symptom: Users accumulate positive balances and refuse to spend, leading to systemic deflation.
Mechanism:
- Alice provides 100 hours of service, earns +100 credits
- Alice never spends those credits (treats them as savings)
- System has net negative balance elsewhere (someone is -100)
- As more people hoard, fewer credits circulate
- New members can't earn credits because no one is spending
Historical Examples:
- LETS (Local Exchange Trading Systems) in 1990s UK: 20-30% of members held 80% of positive balances
- Ithaca Hours: Chronic deflation as businesses accumulated hours but couldn't spend them locally
Potential Mitigations:
- Demurrage: Negative interest on positive balances (e.g., -2% per month)
- Expiring credits: Credits lose value after 12 months
- Balance caps: Maximum positive balance enforced by protocol
- Contribution requirements: Must spend X% of earnings to remain in good standing
Questions for Simulation:
- What demurrage rate prevents hoarding without punishing savers?
- Does demurrage increase velocity or just annoy users?
- Do expiring credits create panic spending (bad UX) or healthy circulation?
2. Free-Rider Problem (Extraction Without Contribution)
Symptom: Users extract value from the community without contributing, exploiting trust or weak enforcement.
Mechanism:
- Bob joins, earns high trust quickly (is friendly, shows up to meetings)
- Bob racks up -50 credits (receives services)
- Bob ghosts the community, never clears debt
- Community eats the loss; trust in system degrades
Historical Examples:
- WIR Bank (Switzerland): Required mandatory membership fees + strict credit limits to prevent free-riding
- Sardex (Italy): Uses credit scoring + mandatory clearing periods
Potential Mitigations:
- New member throttling: Very low initial credit limits
- Trust-gated limits: Credit limit scales with demonstrated trustworthiness
- Mandatory clearing: Must clear debt within 90 days or lose borrowing privileges
- Default visibility: Failed obligations are publicly visible in reputation layer
Questions for Simulation:
- How low should initial credit limits be? (Too low = useless, too high = risky)
- Does trust-gated scaling work if trust graph is manipulated?
- What percentage of free-riders can a system tolerate before collapse?
3. Credit Limit Gaming (Borrow-and-Bail)
Symptom: Users maximize their credit limit, extract maximum value, then abandon the community.
Mechanism:
- Carol builds trust over 6 months (clears small debts reliably)
- Carol's credit limit increases to -200
- Carol immediately borrows -200 (receives services)
- Carol disappears, never repays
Historical Examples:
- Mutual credit systems without dynamic limits often see "graduation fraud"
- Similar to credit card bust-out schemes in traditional finance
Potential Mitigations:
- Gradual limit increases: Ramp credit slowly based on cleared volume (not just time)
- Velocity-based limits: Can only borrow X per month (rate limiting)
- Collateral requirements: High-trust members can vouch for new members (skin in the game)
- Quarantine on large debts: Debts above threshold require community approval to continue
Questions for Simulation:
- What's the optimal credit limit curve? (Linear, logarithmic, stepwise?)
- How fast should limits ramp? (Too slow = frustration, too fast = exploitation)
- Can social collateral (vouching) prevent gaming?
4. Velocity Collapse (Trust Breakdown → No Spending)
Symptom: After a few defaults or conflicts, members stop transacting out of fear.
Mechanism:
- Dan defaults on -30 credits
- Community becomes risk-averse
- Members only transact with known-safe people (high trust scores)
- New members can't break into the trade network
- Velocity drops to near-zero; system is technically alive but functionally dead
Historical Examples:
- Many LETS systems collapsed not from technical failure but from "loss of nerve"
- TimeBanks suffer from this when a few bad experiences go unresolved
Potential Mitigations:
- Trust graph resilience: Default by one member shouldn't tank trust in the system
- Dispute resolution: Fast, fair handling of conflicts prevents fear spiral
- System insurance: Community reserve pool to absorb small losses
- Velocity targets: Alert community if transaction volume drops below threshold
Questions for Simulation:
- What trust graph structure is resilient to local failures?
- Can insurance pools prevent velocity collapse without creating moral hazard?
- What's the minimum viable transaction volume for a healthy system?
5. Pricing Instability (No Shared Unit of Account)
Symptom: Different members value the credit unit differently, leading to price chaos.
Mechanism:
- Alice charges 10 credits/hour for massage
- Bob charges 50 credits/hour for plumbing
- Carol charges 5 credits/hour for childcare
- No one can agree on "fair" exchange rates
- System fragments into micro-economies with incompatible pricing
Historical Examples:
- Ithaca Hours struggled with this: Was 1 Hour = 1 hour of labor, or 1 Hour = $10?
- LETS systems often saw "professional service" vs. "manual labor" pricing conflicts
Potential Mitigations:
- Anchoring to external unit: 1 credit = 1 hour of time (TimeBanks)
- Pricing guidelines: Community-approved rate sheets for common services
- Market feedback: Show "typical rates" for similar services
- Trust-weighted pricing: Trusted members' pricing signals influence norms
Questions for Simulation:
- Does anchoring (1 credit = 1 hour) prevent pricing chaos or cause other problems?
- Can pricing norms emerge organically, or do they need governance?
- What happens if a few members consistently over/underprice?
Agent-Based Simulation Design
Goals
- Model 50-200 agents with heterogeneous behaviors
- Simulate 1-2 years of transactions
- Test different parameter sets (credit limits, demurrage, trust dynamics)
- Identify failure modes and resilience thresholds
Agent Types
Reciprocators (60-70% of population):
- Provide and consume services roughly equally
- Clear debts within reasonable time
- Build trust through consistent behavior
- Realistic model of "good community members"
Hoarders (10-15%):
- Accumulate positive balances
- Rarely spend earned credits
- Not malicious, just risk-averse or have fewer needs
- Test demurrage effectiveness
Free-Riders (5-10%):
- Consume more than they provide
- May ghost after hitting credit limit
- Test robustness of credit policies
Opportunists (5-10%):
- Game the system (build trust, then extract maximum)
- Test security of trust-gated limits
Super-Contributors (5-10%):
- Provide far more than they consume
- Anchor the economy with consistent supply
- Can become resentful if taken advantage of
Simulation Parameters
Economic:
initial_credit_limit: Starting borrowing limit (e.g., -10 to -50)max_credit_limit: Maximum borrowing limit (e.g., -500)limit_growth_rate: How fast limits increase (e.g., 10% of cleared volume)demurrage_rate: Negative interest on positive balances (e.g., -2% per month)default_threshold: When is someone considered in default? (e.g., -100 for >90 days)
Trust:
trust_growth_rate: How fast trust builds with successful transactionstrust_decay_rate: How fast trust decays with failed obligationstrust_limit_multiplier: How much trust boosts credit limit (e.g., 2x at max trust)
Network:
network_density: How connected is the trust graph? (affects transaction opportunities)new_member_rate: How many new members join per month?churn_rate: How many members leave per month?
Metrics to Track
System Health:
- Total transaction volume per month (velocity)
- Gini coefficient of balances (inequality)
- Number of defaults / write-offs
- Percentage of members in good standing
Individual Outcomes:
- Average balance over time
- Credit limit distribution
- Trust score distribution
- Time to clear debts
Failure Indicators:
- Velocity collapse: Transactions drop below threshold
- Deflation spiral: Positive balance accumulation accelerates
- Default cascade: Multiple simultaneous defaults
- Network fragmentation: Isolated clusters stop trading
Simulation Implementation
Tools
Option 1: Python + Mesa (Agent-Based Modeling)
- Pros: Fast prototyping, good visualization, familiar to social scientists
- Cons: Slower execution for large simulations
Option 2: Rust (Custom Simulation)
- Pros: Fast, can reuse ICN types (DID, Ledger, TrustGraph)
- Cons: More code to write, less off-the-shelf visualization
Recommendation: Start with Python/Mesa for rapid iteration, rewrite in Rust if performance matters.
Directory Structure
sims/mutual-credit/
├── agents.py # Agent behavior definitions
├── economy.py # Transaction logic, credit limits
├── trust.py # Trust graph dynamics
├── model.py # Mesa model orchestration
├── scenarios/ # Parameter sets for different tests
│ ├── baseline.json
│ ├── high_demurrage.json
│ ├── low_trust.json
├── analysis/ # Jupyter notebooks for visualization
│ ├── velocity.ipynb
│ ├── inequality.ipynb
├── results/ # Simulation output (CSV, plots)
└── README.md
Validation Against Pilot Data
Once the pilot community (Phase C2) is running:
Export real transaction data:
- Transaction volume per week
- Balance distribution
- Default rate
- Trust dynamics
Calibrate simulation:
- Adjust agent behavior probabilities to match observed patterns
- Tune parameters to reproduce actual velocity, inequality, defaults
Test counterfactuals:
- "What if we had 10% higher demurrage?"
- "What if credit limits were 2x higher?"
- "What if we had 5% more free-riders?"
Predict outcomes:
- "If we grow to 200 members, will velocity hold?"
- "If defaults spike, what interventions work?"
Success Criteria: Simulation predictions match pilot outcomes within 20% margin.
Recommended Defaults (Preliminary)
IMPORTANT: These are hypotheses to be tested, not final values.
Credit Limits
- Initial: -20 credits (enough for 2-3 small transactions)
- Maximum: -500 credits (caps extreme exposure)
- Growth: +10 credits per 50 credits cleared (rewards reliability)
- Trust multiplier: 2x at max trust (score > 0.8)
Demurrage
- Rate: -1% per month on positive balances > 50
- Rationale: Gentle nudge to spend, not punitive
- Exempt: Balances under 50 (don't punish small savers)
Default Handling
- Threshold: Negative balance > 100 for > 90 days
- Action: Freeze further borrowing, flag for dispute resolution
- Write-off: Community vote can socialize loss (mark as bad debt)
New Member Protection
- Ramp period: 3 months before reaching baseline credit limit
- Contribution requirement: Must clear at least 10 credits in first month
- Monitoring: Flag accounts with unusual borrowing patterns
Open Questions
- Demurrage psychology: Does it create resentment or acceptance? (Can't simulate this, need real users)
- Trust graph manipulation: Can agents collude to artificially boost each other's trust?
- External shocks: How does the system handle sudden loss of high-trust members?
- Interoperability: If ICN connects to traditional banking, how does pricing stability change?
Next Steps
Immediate (Week 1-2):
- Set up Python/Mesa simulation environment
- Implement basic agent types (reciprocators, hoarders, free-riders)
- Run baseline scenario (no demurrage, fixed credit limits)
Short-term (Month 1):
- Test demurrage scenarios (0%, 1%, 2%, 5%)
- Test credit limit curves (linear, logarithmic, stepwise)
- Visualize velocity, inequality, default rates
Medium-term (Month 2-3):
- Calibrate against pilot data (once available)
- Run sensitivity analysis (which parameters matter most?)
- Document recommended defaults for Phase 12
Long-term (Month 4+):
- Rewrite in Rust for performance (if needed)
- Add governance modeling (how do decisions affect economics?)
- Model federation scenarios (multi-community trade)
References
Historical Mutual Credit Systems:
- Lietaer, Bernard. "The Future of Money" (2001) - Comprehensive survey
- Williams, Colin. "A Commodified World? Mapping the Limits of Capitalism" (2005) - LETS case studies
- Stodder, James. "Reciprocal Exchange Networks" (2009) - WIR Bank analysis
Agent-Based Modeling:
- Wilensky, Uri. "NetLogo" - Classic ABM platform
- Mesa: Python framework for ABM (mesa.readthedocs.io)
- Epstein, Joshua. "Generative Social Science" (2006) - ABM methodology
Economic Theory:
- Graeber, David. "Debt: The First 5,000 Years" (2011) - Historical context
- North, Peter. "Money and Liberation" (2007) - Mutual credit philosophy
- Gesell, Silvio. "The Natural Economic Order" (1916) - Original demurrage theory
Status: This is a living research document. Add findings, update hypotheses, link to simulation results as they emerge.