Skip to content

PerformancePool.md

Latest commit

 

History

History
181 lines (139 loc) · 6.2 KB

PerformancePool.md

File metadata and controls

181 lines (139 loc) · 6.2 KB

Performance Pool Allocation: Why 50% Makes Sense

🎯 Current Allocation: LP 40% | Performance 50% | Network 10%

Economic Justification for 50% Performance Pool

1. Real Resource Costs

App hosting requires significant ongoing investment:

Resource Type Monthly Cost Annual Cost
Server (8 cores, 32GB RAM) $150-300 $1,800-3,600
Bandwidth (1TB/month) $50-100 $600-1,200
Storage (2TB SSD) $30-60 $360-720
Electricity $40-80 $480-960
Total per Node $270-540 $3,240-6,480

LP provision costs: Near zero (just opportunity cost)

2. Technical Complexity Comparison

Activity Technical Barrier Time Investment Risk Level
Providing LP Low - Click buttons on DEX 5 minutes Low
Running Apps High - Server admin, monitoring Hours daily High

3. Value to Network

Performance contributors provide:

  • ✅ Computational Power - Process transactions, smart contracts
  • ✅ Storage Capacity - Host blockchain data, user files
  • ✅ Network Infrastructure - RPC endpoints, API services
  • ✅ Oracle Services - Price feeds, external data
  • ✅ Cross-chain Bridges - Interoperability services
  • ✅ Redundancy - Network resilience and uptime

LP providers contribute:

  • ✅ Capital - Liquidity for trading
  • ✅ Price Stability - Reduce slippage
  • ✅ Economic Security - Stake for consensus

Performance Pool Distribution Tiers

Tier System Based on App Type

Tier 1: Critical Infrastructure (60% of performance pool)

  • Validator Nodes: Core consensus participation
  • RPC Endpoints: Network access points
  • Oracle Services: Price and data feeds
  • Cross-chain Bridges: Interoperability

Tier 2: Network Services (30% of performance pool)

  • Storage Nodes: Distributed file storage
  • Indexing Services: Blockchain data indexing
  • API Gateways: Developer infrastructure
  • Monitoring Services: Network health tracking

Tier 3: Applications (10% of performance pool)

  • DApps: Decentralized applications
  • Games: Blockchain gaming infrastructure
  • Social: Decentralized social platforms
  • DeFi Tools: Additional financial services

Dynamic Allocation Algorithm

Performance Score Calculation

fn calculate_performance_score(user: &User) -> u64 {
    let base_score = 100;
    
    // Core metrics (70% of score)
    let uptime_score = (user.uptime_percentage * 0.25) as u64;
    let cpu_score = (user.cpu_utilization * 0.20) as u64;
    let requests_score = (user.requests_served / 1000 * 0.15) as u64;
    let response_time_score = (1000 / user.avg_response_time * 0.10) as u64;
    
    // App tier multiplier (30% bonus potential)
    let tier_multiplier = match user.app_tier {
        Tier::Critical => 1.30,
        Tier::Services => 1.15, 
        Tier::Applications => 1.00,
    };
    
    let total_score = (base_score + uptime_score + cpu_score + 
                      requests_score + response_time_score) as f64;
    
    (total_score * tier_multiplier) as u64
}

Example Performance Allocation

Block Reward: 12 QOR

  • Performance Pool: 6 QOR (50%)

3 Users with Different Performance:

User App Type Uptime CPU Use Requests Score Reward
Alice Validator (Tier 1) 99.8% 85% 5,000 195 3.25 QOR
Bob Storage (Tier 2) 98.5% 70% 2,000 138 2.30 QOR
Carol DApp (Tier 3) 97% 60% 1,000 127 0.45 QOR

Alice gets more because:

  1. Critical infrastructure (validator)
  2. Higher performance metrics
  3. Greater network value

Alternative Allocation Models

Option A: Conservative (Current)

  • LP: 40% | Performance: 50% | Network: 10%
  • Pros: Strong app hosting incentives
  • Cons: May not attract enough initial LP

Option B: Balanced

  • LP: 45% | Performance: 45% | Network: 10%
  • Pros: Equal weight to both contributions
  • Cons: May undervalue computational work

Option C: LP-Heavy

  • LP: 50% | Performance: 40% | Network: 10%
  • Pros: Strong initial liquidity incentives
  • Cons: Insufficient app hosting rewards

Option D: Dynamic

  • Early Stage: LP: 50% | Performance: 40% | Network: 10%
  • Growth Stage: LP: 40% | Performance: 50% | Network: 10%
  • Mature Stage: LP: 35% | Performance: 55% | Network: 10%

Network Development Phases

Phase 1: Bootstrap (Months 1-6)

Priority: Attract initial liquidity

  • LP: 50% | Performance: 40% | Network: 10%
  • Lower barriers for app hosting
  • Focus on basic validator nodes

Phase 2: Growth (Months 7-18)

Priority: Scale infrastructure

  • LP: 40% | Performance: 50% | Network: 10%
  • Diverse app requirements
  • Performance quality standards

Phase 3: Maturity (18+ Months)

Priority: Optimize efficiency

  • LP: 35% | Performance: 55% | Network: 10%
  • Advanced app ecosystem
  • Strict performance requirements

Economic Impact Analysis

Higher Performance Allocation Benefits:

  1. Better Infrastructure - More reliable, faster network
  2. Increased Utility - More services attract more users
  3. Network Effects - Better apps drive demand for QOR
  4. Sustainability - Covers real operational costs
  5. Decentralization - Incentivizes more node operators

Risks of Lower Performance Allocation:

  1. Infrastructure Gaps - Not enough service providers
  2. Centralization - Only profitable for large operators
  3. Poor User Experience - Slow, unreliable services
  4. Network Stagnation - Limited growth potential

Recommendation: Start with 50% Performance

Why this allocation works:

  • ✅ Covers Real Costs - App hosting has genuine expenses
  • ✅ Drives Adoption - Better infrastructure attracts users
  • ✅ Fair Distribution - Rewards match value contribution
  • ✅ Network Growth - Incentivizes diverse app ecosystem
  • ✅ Future-Proof - Can adjust based on network needs

Monitor and adjust based on:

  • Network performance metrics
  • User adoption rates
  • LP participation levels
  • App hosting economics
  • Competitor analysis