Overview

​

Abstract

• Trustless computation verification using redundant execution and zero-knowledge proofs
• Dynamic pricing mechanism based on real-time supply and demand
• Multi-tiered reputation system ensuring quality and reliability
• Cross-chain payment infrastructure for global accessibility
• Fault-tolerant distributed task orchestration

​

Document Navigation

​

Foundation Sections

• Getting Started - What is Centrix and why it matters
• The Problem - Why centralized cloud computing is insufficient
• Our Solution - How Centrix solves these problems
• Market Opportunity - Market size, targets, and competitive advantages

​

How to Use Centrix

• For Providers - Earn by sharing computational resources
• For Requestors - Access computing power cheaply and instantly
• For Developers - Build applications on Centrix

​

Technical Details

• Protocol Overview - Network participants and task lifecycle
• Key Concepts - Protocol basics and architecture
• Using Centrix - Technical integration guides

• Openness: Anyone can participate without permission
• Transparency: All transactions and protocols are public
• Fairness: Market forces, not corporate interests, determine pricing
• Efficiency: Maximum utilization of global resources
• Security: Cryptographic guarantees protect all participants

​

2.2 The Problem with Centralized Cloud Computing

​

2.2.1 Monopolistic Market Structure

• Amazon Web Services (AWS): 32%
• Microsoft Azure: 23%
• Google Cloud Platform (GCP): 11%

• Arbitrary pricing with 30-50% profit margins
• Lack of price competition in many regions
• Coordinated pricing strategies across providers
• Barriers to market entry for new competitors

​

2.2.2 Vendor Lock-In

• Proprietary APIs incompatible with competitors
• Specialized services that don’t exist elsewhere
• Data egress fees making migration expensive
• Training and expertise tied to specific platforms

​

2.2.3 Resource Inefficiency

• 85% of global computing capacity is idle at any given time
• $100B+ in unused hardware value depreciates annually
• Massive environmental cost from underutilized data centers
• Capital waste as hardware sits unused while new capacity is built

​

2.2.4 Access Inequality

• Limited presence in developing regions
• High latency from distant data centers
• Expensive pricing prohibitive for small users
• Payment barriers (credit cards, enterprise contracts)

​

2.2.5 Privacy and Control Concerns

• Sensitive data processed on provider hardware
• Proprietary algorithms running on provider infrastructure
• Compliance with unknown internal policies
• Government access via legal compulsion

​

2.3 Our Solution: Decentralized Computing

​

2.3.1 Core Principles

• No approval required to join as provider or requestor
• Open-source software enables transparency
• Anyone can fork and extend the protocol
• Meritocratic reputation system, not arbitrary gatekeeping

• Providers set their own rates based on costs and demand
• Requestors choose based on price, performance, and reputation
• Real-time price discovery through competitive bidding
• No artificial premiums or hidden fees

• Results verified using redundant execution
• Zero-knowledge proofs enable trustless validation
• Slashing mechanisms punish fraudulent behavior
• Reputation system rewards honest participation

• Idle hardware worldwide can be monetized
• Dynamic workload distribution maximizes utilization
• Elastic scaling matches supply with demand
• Environmental benefit from better resource use

• Data and compute stay under user control
• Portable workloads can move between providers
• Transparent execution with auditable results
• Censorship-resistant infrastructure

​

2.3.2 How Centrix Works

• Requestor submits computational task to network
• Specifies requirements (CPU/GPU, memory, duration)
• Sets maximum price willing to pay
• Provides verification parameters

• Available providers receive task broadcast
• Submit bids based on their pricing
• Include reputation score and performance history
• Requestor selects optimal provider(s)

• Task deployed to provider’s isolated environment
• Resource usage monitored in real-time
• Intermediate checkpoints enable fault recovery
• Network ensures provider remains honest

• Results submitted to verification layer
• Multiple methods: redundant execution, ZK proofs, spot checks
• Reputation updated based on performance
• Disputes resolved through arbitration

• Smart contract releases escrowed funds
• Provider receives payment in CXT tokens
• Protocol fee distributed to stakeholders
• Transaction recorded on blockchain

​

2.3.3 Key Differentiators

​

2.4 Market Opportunity and Timing

​

2.4.1 Market Size

• Infrastructure as a Service (IaaS): $150B
• Platform as a Service (PaaS): $120B
• Software as a Service (SaaS): $410B

• Compute-intensive workloads suitable for decentralization
• Price-sensitive customers (SMBs, startups, researchers)
• Use cases requiring flexible scaling
• Privacy-conscious applications

• Year 1: $27M (0.01% of SAM)
• Year 2: $270M (0.1% of SAM)
• Year 3: $2.7B (1% of SAM)

​

2.4.2 Target Markets

1. CGI Rendering & Media Production ($15B)
   • Film and television rendering
   • Architectural visualization
   • Game asset creation
   • 3D modeling and animation
2. AI/ML Training & Inference ($90B)
   • Model training for startups
   • Hyperparameter optimization
   • Inference at scale
   • Research experimentation
3. Scientific Computing ($50B)
   • Academic research simulations
   • Genomics and bioinformatics
   • Climate modeling
   • Particle physics
4. DeFi and Blockchain ($20B)
   • MEV extraction
   • Node operation
   • Blockchain indexing
   • Smart contract testing

5. Web3 Infrastructure ($30B)
   • Decentralized storage encoding
   • IPFS pinning services
   • Blockchain full nodes
   • Distributed databases
6. Data Processing ($40B)
   • ETL pipelines
   • Data analytics
   • Video transcoding
   • Log processing

​

2.4.3 Why Now?

• Blockchain maturity: Ethereum and L2s provide scalable infrastructure
• Containerization: Docker/Kubernetes enable secure isolation
• Cryptographic advances: ZK proofs make verification practical
• P2P networks: libp2p and IPFS provide robust communication

• Cloud costs rising: Providers increasing prices 10-30% annually
• Crypto adoption: 500M+ users comfortable with tokens
• Remote work: Distributed teams comfortable with decentralized tools
• AI boom: Explosive demand for compute exceeding supply

• Early movers (Golem, iExec, Akash) have validated the model
• No dominant player yet established
• Market ready for next-generation solution
• Window of opportunity before cloud giants adapt

​

2.4.4 Competitive Advantages

• 70-90% cost savings
• No vendor lock-in
• Faster geographical expansion
• Censorship resistance

• Superior verification mechanisms (ZK proofs)
• Better developer experience (simple APIs)
• Stronger economic model (token utility)
• More flexible architecture (multi-chain support)

• More providers → Better pricing for requestors
• More requestors → Better earnings for providers
• More usage → Higher token value
• Higher token value → More participants

​

3. Key Concepts

​

3.1 Protocol Overview

​

3.1.1 Network Participants

• Submit computational tasks to the network
• Specify resource requirements and constraints
• Set maximum price willing to pay
• Review and select provider bids
• Verify results and trigger payment

• Register hardware with the network
• Set pricing and availability schedules
• Bid on tasks matching their capabilities
• Execute tasks in isolated environments
• Submit results for verification

• Operate verification nodes
• Validate computation results
• Maintain consensus on task outcomes
• Earn fees for verification services
• Can be slashed for dishonest behavior

• Provide liquidity and stability
• Earn staking rewards from protocol fees
• Participate in governance decisions (future)
• Benefit from network growth

​

3.1.2 Task Lifecycle

1. SUBMITTED → Task posted by requestor
2. BIDDING → Providers submit competing bids
3. ASSIGNED → Requestor selects winning provider
4. EXECUTING → Provider processes the task
5. COMPLETED → Results submitted to network
6. VERIFYING → Validators check correctness
7. SETTLED → Payment released, reputation updated

• Automatic progression for successful tasks
• Timeout mechanisms prevent stalling
• Dispute resolution for contested results
• Checkpoint recovery for interrupted tasks

​

3.1.3 Economic Primitives

• Native currency of the Centrix network
• Required for all task payments
• Staked by validators and premium providers
• Burned partially as deflationary mechanism
• ERC-20 compatible for broad accessibility

• Dynamic pricing based on supply and demand
• Providers set base rates + bid adjustments
• Requestors set maximum acceptable price
• Market clearing through competitive bidding
• Premium pricing for urgent tasks

Total Cost = Provider Payment + Protocol Fee
Protocol Fee = 5% of Provider Payment

Distribution:
- 60% → Token stakers (passive income)
- 25% → Validators (active verification)
- 10% → Development fund (ongoing R&D)
- 5% → Insurance pool (dispute resolution)

​

3.2 Protocol Basics

​

3.2.1 Task Specification

{
  "taskId": "0x...",
  "requestor": "0x...",
  "requirements": {
    "cpu": "8 cores",
    "memory": "32 GB",
    "storage": "100 GB",
    "gpu": "RTX 3080 or equivalent",
    "network": "1 Gbps",
    "duration": "2 hours estimated"
  },
  "input": {
    "type": "ipfs",
    "cid": "Qm..."
  },
  "container": {
    "image": "centrix/blender:latest",
    "command": ["blender", "-b", "scene.blend", "-o", "/output/frame####", "-f", "1..100"]
  },
  "verification": {
    "method": "redundant",
    "redundancy": 3,
    "threshold": 0.67
  },
  "payment": {
    "maxPrice": "50 CXT",
    "escrow": "52.5 CXT"
  }
}

• Requirements: Hardware specifications needed
• Input: Data sources (IPFS, HTTP, S3-compatible)
• Container: Docker image and execution command
• Verification: How results will be validated
• Payment: Pricing and escrow details

​

3.2.2 Provider Discovery

{
  "providerId": "0x...",
  "hardware": {
    "cpu": "AMD Ryzen 9 5950X (16 cores)",
    "memory": "64 GB DDR4",
    "storage": "2 TB NVMe",
    "gpu": ["NVIDIA RTX 3090", "NVIDIA RTX 3080 Ti"],
    "network": "10 Gbps"
  },
  "pricing": {
    "cpuPerCoreHour": "0.5 CXT",
    "gpuPerHour": "5 CXT",
    "storagePerGB": "0.01 CXT"
  },
  "reputation": {
    "score": 4.8,
    "completedTasks": 1523,
    "successRate": 99.2,
    "avgResponseTime": "45 seconds"
  },
  "availability": {
    "schedule": "24/7",
    "nextAvailable": "immediate"
  }
}

1. Filter providers meeting minimum requirements
2. Rank by combination of price and reputation
3. Request bids from top N candidates
4. Requestor selects based on bid competitiveness

​

3.2.3 Execution Environment

• Separate namespaces (PID, network, mount)
• Resource limits (cgroups)
• Read-only root filesystem
• Dropped capabilities
• seccomp/AppArmor profiles

• Real-time CPU/memory/network tracking
• Alert system for limit violations
• Automatic throttling if exceeded
• Usage data for billing accuracy

• Regular checkpointing of progress
• State saved to persistent storage
• Restart from last checkpoint on failure
• Automatic provider reassignment if unresponsive

​

3.2.4 Result Verification

• Task executed by 3+ independent providers
• Results compared using cryptographic hashes
• Consensus determined by majority agreement
• Dissenters penalized through reputation slashing

• Provider generates ZK proof of correct execution
• Validators verify proof without re-execution
• Dramatically reduces verification cost
• Applicable to certain computational classes

• Random sampling of task results
• Re-execution on trusted validator nodes
• Statistical guarantee of correctness
• Cost-effective for large batches

• Providers stake CXT proportional to task value
• Stake slashed if fraud detected
• Makes dishonesty economically irrational
• Bonds returned after successful verification

​

3.3 Architecture

​

3.3.1 System Components

• Ethereum mainnet for settlements and token
• Smart contracts for payments and escrow
• Layer 2 (Optimistic Rollups) for scalability
• Cross-chain bridges for multi-chain support

• Task queue and distribution
• Provider discovery (DHT)
• Bid collection and matching
• State management and consensus

• Containerized compute environments
• Resource isolation and monitoring
• Result collection and submission
• Local storage and caching

• Result validation nodes
• Consensus mechanisms
• Dispute resolution
• Reputation tracking

• IPFS for distributed storage
• BitTorrent for large file distribution
• CDN integration for performance
• Encrypted data transmission

​

3.3.2 Network Topology

                  ┌──────────────────┐
                  │   Blockchain     │
                  │   (Ethereum L1)  │
                  └────────┬─────────┘
                           │
              ┌────────────┴────────────┐
              │                         │
      ┌───────▼──────┐         ┌───────▼──────┐
      │  L2 Rollup   │         │ Token Bridge │
      │   (Scaling)  │         │ (Multi-chain)│
      └───────┬──────┘         └───────┬──────┘
              │                        │
              └────────────┬───────────┘
                           │
                  ┌────────▼─────────┐
                  │  Task Manager    │
                  │  (Coordination)  │
                  └────────┬─────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
┌───────▼──────┐  ┌────────▼────────┐  ┌─────▼────────┐
│  Requestor   │  │  Provider Pool  │  │  Validators  │
│   Network    │  │  (Execution)    │  │  (Verify)    │
└──────────────┘  └─────────────────┘  └──────────────┘
                           │
                  ┌────────▼─────────┐
                  │   Data Layer     │
                  │  (IPFS/BT/CDN)   │
                  └──────────────────┘

​

3.3.3 Communication Protocols

• libp2p protocol stack
• Gossipsub for message propagation
• DHT (Kademlia) for peer discovery
• NAT traversal (hole punching, TURN relays)

• RESTful HTTP API for requestors
• WebSocket for real-time updates
• gRPC for high-performance internal communication
• GraphQL for complex queries

• IPFS for content-addressed storage
• BitTorrent for redundant downloads
• Direct peer-to-peer when possible
• Fallback to CDN for reliability

​

3.3.4 Smart Contract Architecture

• Task creation and lifecycle management
• Bid collection and provider selection
• Escrow management
• Event emission for off-chain tracking

• CXT token transfers
• Fee distribution to stakeholders
• Slashing penalties
• Withdrawal mechanisms

• Provider reputation scores
• Historical performance data
• Weighted rating algorithms
• Stake tracking

• Dispute initiation and resolution
• Evidence submission
• Voting by validator set
• Appeal mechanisms

// Task submission flow
1. Requestor approves CXT spending
2. TaskManager.createTask() called
3. Escrow locked in contract
4. TaskCreated event emitted
5. Providers submit bids off-chain
6. Requestor calls selectProvider()
7. Task assigned, execution begins

// Payment flow
1. Provider submits results
2. Verification process initiated
3. Validators confirm correctness
4. PaymentProcessor.releasePayment()
5. Provider receives funds
6. Fees distributed to stakeholders
7. Reputation updated

​

3.3.5 Scalability Architecture

• Add more providers → Linear capacity increase
• Sharded task queues for parallelism
• Geographic distribution reduces latency
• No central bottleneck

• Optimistic Rollups for 10,000+ TPS
• Batch processing for gas efficiency
• Off-chain computation, on-chain settlement
• Fraud proofs for security

• Provider metadata cached locally
• Popular task templates pre-loaded
• IPFS data pinned on multiple nodes
• CDN for static resources

• Task submission: < 1 second
• Provider matching: < 5 seconds
• Result verification: < 30 seconds
• Payment settlement: < 60 seconds
• Network capacity: 1M+ concurrent tasks

​

4. Using Centrix

​

4.1 For Providers

​

4.1.1 Getting Started as a Provider

• Minimum: 4-core CPU, 8GB RAM, 100GB storage, 100 Mbps Internet
• Recommended: 16+ core CPU, 32GB+ RAM, 1TB+ SSD, 1 Gbps Internet
• Optional: GPU (NVIDIA RTX 3060+) for higher earnings
• Operating System: Linux (recommended), macOS, or Windows

# Download and install Centrix Provider Node
curl -L https://centrix.network/install | bash

# Initialize your provider
centrix-provider init \
  --wallet 0x1234567890abcdef... \
  --cpu 16 \
  --memory 32000 \
  --storage 1000000

# Start the provider node
centrix-provider start

# ~/.centrix/provider.yml
hardware:
  cpu_cores: 16
  memory_mb: 32000
  storage_gb: 1000
  gpu_models:
    - NVIDIA RTX 3090
    - NVIDIA RTX 3080

pricing:
  cpu_per_core_hour: 0.50 CXT
  gpu_per_hour: 5.00 CXT
  storage_per_gb: 0.01 CXT

availability:
  schedule: "24/7"
  uptime_target: 99.5
  
security:
  stake_amount: 100 CXT
  reputation_multiplier: 1.2

• Stake minimum 100 CXT as security deposit
• Higher stakes = higher visibility and priority
• Earn reputation faster with consistent performance
• Slashed if dishonest (fraud penalties)

​

4.1.2 Earning Model

1. Task Execution (Primary income)
   • Earn 95% of task cost
   • Price set by market competition
   • Average earnings: $500-$5,000/month per provider
2. Staking Rewards (Secondary income)
   • 5% protocol fee distributed to stakers
   • Annual yield: 20-40% (varies with network activity)
   • Automatic distribution (monthly)
3. Reputation Bonuses (Premium tiers)
   • 5-star providers: 10% earnings multiplier
   • Guaranteed minimum availability: 5% bonus
   • Long-term commitment: additional 5% bonus

Hardware: 16-core CPU, 32GB RAM, 1x RTX 3080
Pricing: $0.50/CPU hour, $5/GPU hour

Daily Activity:
- 20 CPU-intensive tasks: 50 hours @ $0.50 = $25
- 10 GPU tasks: 30 hours @ $5 = $150
- Daily Revenue: $175

Monthly Projection:
- $175/day × 30 days = $5,250
- Plus staking rewards: +$100
- Total Monthly: ~$5,350

​

4.1.3 Provider Best Practices

• Monitor network latency (target: <50ms)
• Maintain consistent uptime (track dashboard)
• Update software regularly (security patches)
• Scale resources based on demand

• Complete tasks quickly and reliably
• Maintain 99%+ success rate
• Respond to customer queries promptly
• Achieve 5-star ratings through excellence

• Start with conservative stake
• Gradually increase capacity
• Monitor system resources
• Have backup internet connection
• Regular backups of critical data

​

4.2 For Requestors

​

4.2.1 Getting Started as a Requestor

• Visit centrix.network
• Sign up with email or Web3 wallet
• Verify email address
• Set up payment method (CXT wallet or credit card bridge)

# Option 1: Direct CXT transfer
centrix wallet transfer \
  --to centrix-account:user@example.com \
  --amount 100 CXT

# Option 2: Swap stablecoins for CXT
# Via exchange (Uniswap, Curve, etc.)

# Option 3: Credit card (via onramp partner)
# Automatic conversion to CXT

# task.yml
name: "Blender Render - My Scene"
description: "Render 100 frames of animated scene"

requirements:
  cpu_cores: 8
  memory_mb: 16000
  storage_gb: 100
  gpu: "NVIDIA RTX 3080+"  # Optional
  duration_estimate: "2 hours"

input:
  files:
    - source: "s3://my-bucket/scene.blend"
      destination: "/input/scene.blend"
    - source: "local:textures/"
      destination: "/input/textures/"

execution:
  container: "centrix/blender:4.0"
  command: [
    "blender",
    "-b",
    "/input/scene.blend",
    "-o",
    "/output/frame_####",
    "-f",
    "1..100"
  ]

output:
  files:
    - source: "/output/frame_*.png"
      destination: "s3://my-bucket/output/"
    - source: "/output/metadata.json"
      destination: "local:results/"

verification:
  method: "redundant"
  redundancy_factor: 3
  threshold: 0.67

pricing:
  max_price: 50 CXT
  urgency: "normal"
  quality_multiplier: 1.0

# Submit task
centrix task submit task.yml

# Monitor progress
centrix task status <task-id>

# View real-time logs
centrix task logs <task-id> --follow

# Download results when complete
centrix task download <task-id> --output ./results/

​

4.2.2 Task Types and Templates

1. Blender Rendering
   • 3D model rendering
   • Animation sequences
   • Batch rendering
   • Pre-configured environment
2. AI/ML Training
   • PyTorch/TensorFlow support
   • Distributed training setup
   • GPU acceleration
   • Custom dataset handling
3. Video Processing
   • FFmpeg transcoding
   • NVIDIA GPU acceleration
   • Batch processing
   • Multi-format support
4. Scientific Computing
   • Python/NumPy/SciPy
   • MATLAB compatibility
   • Large dataset processing
   • Distributed algorithms
5. Data Analysis
   • SQL queries on large datasets
   • Statistical analysis
   • ETL pipelines
   • Custom Python scripts

# Create custom task from Docker image
centrix task create-custom \
  --image "my-organization/my-app:latest" \
  --name "custom-processing" \
  --cpu 8 \
  --memory 16000

# Test locally before submitting
centrix task test ./my-task.yml --local

​

4.2.3 Cost Optimization

1. Off-Peak Scheduling
   • Submit non-urgent tasks during low-demand periods
   • Price drops 30-50% during off-peak hours
   • Potential savings: $10-$50 per task
2. Batch Processing
   • Combine multiple small tasks into larger ones
   • Reduced per-task overhead
   • Better provider selection
   • Potential savings: 20% per task
3. Provider Selection
   • New/unestablished providers offer discounts (20-40%)
   • Still reliable with reputation system protection
   • Geographic optimization reduces latency fees
4. Redundancy Configuration
   • Adjust redundancy for non-critical tasks
   • Use spot verification (30% of time)
   • Balance cost vs. security needs

Traditional Cloud (AWS EC2):
- 8-core instance: $1.20/hour
- 100 hours: $120

Centrix Network:
- 8-core CPU @ $0.50/hour: $40
- Savings: 67% ($80)

With optimization:
- Off-peak discount: -30% = $28
- Total savings: 77% ($92)

​

4.3 For Developers

​

4.3.1 SDK Integration

# Node.js / JavaScript
npm install @centrix/sdk

# Python
pip install centrix-sdk

# Go
go get github.com/centrix/sdk-go

import { Centrix } from '@centrix/sdk';

// Initialize client
const centrix = new Centrix({
  apiKey: process.env.CENTRIX_API_KEY,
  network: 'mainnet'
});

// Submit task
const task = await centrix.tasks.submit({
  name: 'Process Data',
  container: 'centrix/python:3.11',
  command: ['python', '/app/process.py'],
  resources: {
    cpu: 4,
    memory: 8000,
    storage: 50
  },
  input: {
    files: ['data.csv']
  },
  pricing: {
    maxPrice: 10 // CXT
  }
});

// Monitor progress
task.on('started', () => console.log('Task started'));
task.on('progress', (pct) => console.log(`Progress: ${pct}%`));
task.on('completed', (results) => {
  console.log('Task completed!');
  console.log(results);
});

// Wait for completion
const results = await task.wait();
console.log(results);

from centrix import Centrix

# Initialize client
centrix = Centrix(api_key='YOUR_API_KEY')

# Submit task
task = centrix.tasks.submit(
    name='ML Training',
    container='centrix/pytorch:latest',
    command=['python', '/app/train.py'],
    resources={
        'cpu': 8,
        'memory': 16000,
        'storage': 100,
        'gpu': 'NVIDIA RTX 3080'
    },
    input_files=['model.py', 'data.tar.gz'],
    max_price=50  # CXT
)

# Monitor and retrieve results
for status in task.monitor():
    print(f'Status: {status}')

results = task.get_results()
print(f'Output files: {results["files"]}')

​

4.3.2 Advanced Features

// Get task history
const history = await centrix.tasks.list({
  limit: 100,
  status: 'completed'
});

// Analyze costs
const analytics = await centrix.analytics.getCostBreakdown({
  period: '30d',
  groupBy: 'container'
});

// Monitor provider reputation
const provider = await centrix.providers.get(providerId);
console.log(`Reputation: ${provider.reputation.score}/5.0`);
console.log(`Success Rate: ${provider.reputation.successRate}%`);

// Define custom verification
const task = await centrix.tasks.submit({
  // ... task config ...
  verification: {
    method: 'custom',
    function: async (result1, result2, result3) => {
      // Custom comparison logic
      return result1.hash === result2.hash && 
             result2.hash === result3.hash;
    }
  }
});

// Register webhook
await centrix.webhooks.create({
  url: 'https://myapi.example.com/centrix-callback',
  events: ['task.completed', 'task.failed'],
  secret: 'webhook_secret_key'
});

// Backend receives webhook
app.post('/centrix-callback', (req, res) => {
  const { event, task_id, results } = req.body;
  
  if (event === 'task.completed') {
    // Process completed task
    processResults(task_id, results);
  }
  
  res.status(200).json({ ok: true });
});

​

4.3.3 Best Practices

1. Error Handling
   • Implement retry logic for transient failures
   • Set appropriate timeouts
   • Handle network interruptions gracefully
2. Resource Optimization
   • Right-size resource requests (monitor actual usage)
   • Use task templates when possible
   • Batch related tasks efficiently
3. Security
   • Never hardcode API keys (use environment variables)
   • Validate task results before using
   • Implement access controls on webhooks
4. Testing
   • Test tasks locally before production
   • Use testnet for development
   • Implement monitoring and alerts

​

5. Technical Architecture

​

6.1 Threat Model

1. Computation Attacks
   • Malicious providers returning incorrect results
   • Providers executing different code than submitted
   • Data exfiltration from task inputs
   • Silent failures without error reporting
2. User Attacks
   • Requestors submitting malicious code
   • Requestors attempting resource exhaustion
   • Submitting prohibited/illegal computations
   • Denial of service through spam tasks
3. Network Attacks
   • DDoS attacks on task managers
   • Network partition attacks
   • Man-in-the-middle on data transmission
   • Routing attacks on peer discovery
4. Economic Attacks
   • Reputation system manipulation (Sybil attacks)
   • Price manipulation and collusion
   • Temporary provider attacks (hit and run)
   • Fee structure gaming
5. Smart Contract Vulnerabilities
   • Re-entrancy exploits
   • Integer overflow/underflow
   • Logic bugs in payment distribution
   • Unauthorized access to funds

​

6.2 Defense Mechanisms

​

6.2.1 Result Verification

• Critical tasks run on 3+ independent providers
• Cryptographic hash comparison of results
• Automatic provider reassignment if outlier detected
• Quorum-based consensus (2/3 majority)

• Providers generate ZK proof of correct execution
• Validators verify proof without re-running task
• Reduces verification cost by 95%+
• Works for specific computational classes (future)

• Random sampling of task results (~10%)
• Re-execution on trusted validator nodes
• Statistical guarantee of correctness
• Cost-effective for large batches

• Providers stake CXT proportional to task value
• Stake slashed if fraud detected (up to 100%)
• Makes dishonesty economically irrational
• Bonds returned with interest after success

​

6.2.2 Code Sandboxing

• Docker-based execution with security hardening
• seccomp profiles restrict system calls
• AppArmor/SELinux for additional isolation
• Read-only root filesystem
• Dropped dangerous capabilities (CAP_SYS_ADMIN, etc.)

• CPU limits enforced per task
• Memory limits with OOM killer
• Network bandwidth throttling
• Disk I/O rate limiting
• Process count limits

• Pre-approved container images only
• Signed software for trusted providers
• Content-addressed container layers
• Audit trail of image updates

• Real-time process monitoring
• Behavioral analysis for anomalies
• Network connection tracking
• File access logging
• System call profiling

​

6.2.3 Network Security

• Rate limiting per provider/requestor
• Proof-of-work for task submission
• Adaptive throttling during attacks
• Geographic IP filtering
• Fallback to manual review for edge cases

• Minimum CXT stake requirement (100 CXT)
• Increasing identity cost with participation
• Reputation bootstrapping (new providers start low)
• KYC optional but recommended
• Hardware fingerprinting for provider nodes

• TLS 1.3 for all HTTP endpoints
• Perfect Forward Secrecy enabled
• Certificate pinning for critical connections
• End-to-end encryption for sensitive data
• Message authentication codes (HMAC)

• Optional Know-Your-Customer (KYC) for premium tier
• GitHub/Ethereum address verification
• Multi-factor authentication (2FA)
• Rate limiting by identity
• Fraud detection systems

​

6.2.4 Smart Contract Security

• Formal verification for critical contracts
• Multiple independent security audits
• Bug bounty program
• Staged rollout with upgradeable proxies
• Emergency pause mechanisms

• Multi-signature approval for parameter changes
• Role-based access (Admin, Operator, User)
• Time-locked governance decisions
• Transparent upgrade processes

• Daily caps on minting
• Maximum withdrawal limits
• Slashing committee oversight
• Treasury diversification

​

7. Economic Model

​

7. Economic Model

​

7.1 CXT Token Specifications

Contract Address: 0x... (to be updated at launch)
Token Name: Centrix Token
Token Symbol: CXT
Decimals: 18
Total Supply: 1,000,000,000 CXT (fixed, no minting)
Network: Ethereum Mainnet (ERC-20)
Alternative Networks: Arbitrum, Optimism (bridges)

1. Payment for Computation (Primary use)
   • Only way to purchase computational resources
   • Direct transfer from requestor to provider
   • Pricing in CXT creates native market
2. Staking and Security
   • Provider stake: Minimum 100 CXT
   • Validator stake: Minimum 1,000 CXT
   • Slashable for fraudulent behavior
   • Earn protocol fee rewards
3. Governance (Future)
   • 1 token = 1 vote on protocol changes
   • DAO treasury management
   • Quorum and voting thresholds
   • Proposal submission fees
4. Protocol Fee Distribution
   • 5% of all transaction value distributed to stakeholders
   • Token holders earn passive staking rewards
   • Deflationary over time through burning

​

7.2 Token Distribution

• TGE (Token Generation Event): Q1 2025
• Initial Circulation: 400,000,000 CXT (40% of supply)
• Year 1 Circulation: 500,000,000 CXT (50%)
• Year 2 Circulation: 650,000,000 CXT (65%)
• Year 4+ Circulation: 100% (all tokens in circulation)

​

7.3 Revenue Model and Fee Structure

Task Cost = Provider Charge (PC)
Fee = TC × 5% = 0.05 × TC
Distribution:
  - Staking Rewards: 60% × 0.05 × TC = 0.03 × TC
  - Validator Network: 25% × 0.05 × TC = 0.0125 × TC
  - Development Fund: 10% × 0.05 × TC = 0.005 × TC
  - Insurance Pool: 5% × 0.05 × TC = 0.0025 × TC

Provider Earnings: TC × 95% = 0.95 × TC

Task Cost = ∑(Resource Rate × Duration × Quantity) + Urgency Multiplier

Examples:

1. CPU-Intensive Task:
   - Base Rate: 0.50 CXT/core/hour
   - 8 cores, 2 hours
   - Cost: 8 × 0.50 × 2 = 8 CXT

2. GPU Rendering:
   - Base Rate: 5.00 CXT/GPU/hour
   - 1 RTX 3080, 4 hours
   - Cost: 1 × 5.00 × 4 = 20 CXT

3. Urgent Task (20% multiplier):
   - Base computation: 50 CXT
   - With urgency: 50 × 1.20 = 60 CXT

4. Off-Peak Discount (-30%):
   - Base computation: 40 CXT
   - Off-peak: 40 × 0.70 = 28 CXT

​

7.4 Staking and Rewards

1. Task Execution Rewards (95% of task cost)
   • Direct payment for work performed
   • Proportional to computational resources utilized
   • Higher reputation = higher task priority
   • Average APY: 50-200% (varies with utilization)
2. Protocol Fee Staking (60% of 5% fee)
   • Earn proportional to stake amount
   • Distributed monthly to all stakers
   • No active work required (passive income)
   • Base APY: 20-40% (before performance bonuses)

1. Verification Rewards (25% of 5% fee)
   • Earn for validating task results
   • Must maintain 99%+ uptime
   • Slashed for dishonest validation
   • Requires minimum 1,000 CXT stake
2. Performance Bonuses:
   • 100% uptime bonus: +5% APY
   • High accuracy bonus: +10% APY
   • Long-term commitment bonus: +5% APY
   • Total potential: 50-55% APY for validators

1. Liquidity Provider Staking:
   • Provide CXT liquidity on DEXs (Uniswap, Curve)
   • Earn swap fees and protocol revenue share
   • APY: 15-30% (varies with volume)
2. Long-term Holder Benefits:
   • Governance voting rights
   • Parameter adjustment participation
   • Treasury management involvement
   • Future airdrops and incentives

​

7.5 Tokenomics Parameters

• Protocol fee (5% → 3-10% range)
• Fee distribution percentages
• Staking requirements
• Slashing penalties
• Upgrade schedule

​

8. Governance and Community

​

8.1 Initial Phase (2025-2026)

• Protocol upgrades managed by Centrix Foundation
• Emergency actions require multi-sig approval (3-of-5)
• Community feedback via Discord/governance forum
• Quarterly transparency reports on GitHub
• Public smart contract audits

​

8.2 Decentralized Governance (2027+)

• CXT holders vote on proposals
• 1 token = 1 vote (snapshot voting)
• 7-day voting period (5-day discussion + 2-day voting)
• 10% quorum requirement (minimum participation)
• 66% supermajority for protocol changes
• 50% majority for budget allocations

• Protocol fee adjustments (5% → 3-10% range)
• Feature prioritization and roadmap
• Treasury allocation and spending
• Emergency response and bug fixes
• Parameter adjustments (staking requirements, etc.)
• New committee formation
• Validator/Provider eligibility changes

1. Proposal Phase: Community posts RFC (Request for Comments)
2. Discussion Phase: 5-day open discussion, feedback collection
3. Voting Phase: 2-day on-chain voting via Snapshot
4. Execution: Multi-sig executes approved proposals (24-48 hour delay)
5. Review: Quarterly audit of executed changes

• Development & Research: 40-50%
• Community & Marketing: 20-30%
• Operations & Infrastructure: 15-25%
• Grants & Partnerships: 5-10%
• Contingency Reserve: 5%

​

8.3 Community Structure

1. Contributors
   • Submit code, documentation, design
   • Earn bounties from treasury
   • Participate in governance
   • No formal requirements
2. Moderators
   • Maintain community standards
   • Manage Discord/forums
   • Represent community interests
   • Nominated and voted by community
3. Ambassadors
   • Promote Centrix globally
   • Organize local meetups
   • Translate documentation
   • Earn monthly stipends (100-500 CXT)
4. Researchers
   • Academic research on protocol
   • Publish findings
   • Contribute to specifications
   • Earn grants (1,000-10,000 CXT)

• Discord: Day-to-day discussion, support
• Forum: Long-form discussions, RFCs
• GitHub: Code, issues, technical discussions
• Twitter: Announcements, news
• Weekly Calls: Community meetings (every Tuesday)

​

9. Development Roadmap

​

Phase 1: Stone (Q1 2025) ✅

• Testnet launch
• Basic task templates (Blender rendering)
• CLI tools
• 1,000+ beta providers
• Community feedback collection

​

Phase 2: Bronze (Q2 2025)

• Mainnet launch
• Token generation event (TGE)
• Web dashboard and UI
• 10,000+ providers
• Mobile app beta

​

Phase 3: Iron (Q3 2025)

• GPU support (NVIDIA, AMD)
• AI/ML templates (PyTorch, TensorFlow)
• Marketplace and rating system
• 50,000+ providers
• Enterprise SLA support

​

Phase 4: Steel (Q4 2025)

• Advanced verification (ZK proofs)
• Cross-chain integration (Arbitrum, Optimism)
• Enterprise features (batching, scheduling)
• 100,000+ providers
• Institutional partnerships

​

Phase 5: Diamond (2026+)

• Full decentralization (DAO governance)
• Protocol 2.0 improvements
• Global expansion (Asia, Africa, Latin America)
• 1M+ providers
• Mainstream adoption

​

10. Use Cases and Applications

​

10.1 CGI Rendering & Media Production

• On-demand rendering capacity at 70-90% lower cost
• Scale from 100 to 10,000 cores instantly
• No upfront hardware investment
• Pay only for actual usage

Traditional Studio Cost:
- Feature film (1000 hours rendering): $500,000
- 90 days timeline
- Fixed capacity

Centrix Cost:
- Same workload: $50,000
- 90 days timeline (same)
- Savings: $450,000 (90%)

ROI for Studio: Immediate
Timeline to break-even: Same-day payment

• Submit Blender/3DS Max scenes
• Centrix handles distribution
• Results auto-assembled
• Direct integration with production pipelines

​

10.2 AI and Machine Learning

• Access to diverse GPU inventory
• Elastic scaling during training
• Cost-effective hyperparameter tuning
• No long-term contracts or pre-commitment

AWS GPU Cluster (Training):
- 8x A100 GPUs: $40/hour
- 100 hours training: $4,000
- Monthly cost (research): $20,000

Centrix (on-demand):
- 8x A100 equivalent: $8/hour
- 100 hours training: $800
- Monthly cost (research): $4,000
- Savings: 80% ($16,000/month)

• PyTorch, TensorFlow, JAX, MXNet
• Distributed training (Horovod, Ray)
• AutoML platforms
• Custom training scripts

​

10.3 Scientific Research & Academia

• Democratize supercomputer access
• Sub-$1,000 supercomputer hours
• Reproducible research environments
• Global collaboration

• Climate modeling
• Protein folding simulation
• Particle physics
• Genomics analysis
• Chemical simulations

Traditional Supercomputer:
- Annual membership: $50,000
- Queue time: 2-6 weeks
- Limited availability

Centrix:
- Pay as you go
- Immediate availability
- Global researcher collaboration
- Cost: $200-500 per research task

​

10.4 Blockchain and DeFi Infrastructure

• Run full nodes efficiently
• Process blockchain data at scale
• Decentralized indexing (The Graph alternative)
• Smart contract simulation and testing

• Full node operation
• MEV extraction and protection
• Blockchain indexing
• Smart contract testing
• Data analytics

​

10.5 Web3 Infrastructure Services

• IPFS node operation and pinning
• Decentralized storage services
• Content delivery network nodes
• Distributed database nodes

• IPFS/Protocol Labs
• Arweave
• Chainlink
• The Graph
• Filecoin

​

11. Risk Analysis and Mitigation

​

11.1 Technical Risks

• Probability: Medium
• Impact: High (payment disputes)
• Mitigation: Redundant execution, ZK proofs, multi-layer verification

• Probability: Medium-Low
• Impact: High (loss of funds)
• Mitigation: Staking, slashing, reputation system, insurance pool

• Probability: Low (scalable architecture)
• Impact: Medium (service degradation)
• Mitigation: Layer 2, sharding, off-chain coordination

• Probability: Low (audited)
• Impact: Critical (loss of funds)
• Mitigation: Formal verification, bug bounty, gradual rollout

​

11.2 Economic Risks

• Probability: High
• Impact: Medium (affects incentives)
• Mitigation: Stablecoin bridge, long-term vesting, protocol diversification

• Probability: Medium
• Impact: High (service unavailable)
• Mitigation: Attractive rewards, geographic incentives, partnerships

• Probability: Medium
• Impact: High (token value decays)
• Mitigation: Use case development, partnerships, marketing

• Probability: Low-Medium
• Impact: Medium (higher prices)
• Mitigation: Open market, transparency, new provider incentives

​

11.3 Regulatory Risks

• Probability: Medium (crypto uncertainty)
• Impact: High (business model disruption)
• Mitigation: Regulatory compliance, utility token positioning, jurisdiction diversification

• Probability: Low
• Impact: Critical (legal liability)
• Mitigation: Content filtering, provider vetting, legal framework, insurance

• Probability: Medium
• Impact: Low-Medium (compliance burden)
• Mitigation: Tax guidance documentation, accounting integrations

​

11.4 Adoption Risks

• Probability: Medium
• Impact: Medium (limited capacity)
• Mitigation: Attractive APY, ease of setup, geographic expansion

• Probability: Medium
• Impact: High (no demand)
• Mitigation: Superior UX, cost advantage, partnerships, education

• Probability: High
• Impact: High (market share pressure)
• Mitigation: Decentralized advantage, niche focus, continuous innovation

​

12. Conclusion and Vision

• 2025: Mainnet launch, first 100k providers, early adopter users
• 2026: 1M+ providers, mainstream awareness, institutional adoption
• 2027: Full decentralization, DAO governance, global markets
• 2030: Centrix as primary compute infrastructure for Web3 and beyond

• 85% of idle computing capacity monetized
• $100B+ in provider earnings annually
• $50B+ in cost savings for requestors
• Democratized access to supercomputing
• New economic opportunities for billions

​

Appendix A: Frequently Asked Questions

​

Appendix B: Technical Specifications

• Task creation and lifecycle
• Provider matching algorithm
• Escrow management
• Event emission

• CXT token transfers
• Fee distribution
• Slashing execution
• Withdrawal mechanisms

• Provider scores (1-5 stars)
• Success rate tracking
• Response time metrics
• Historical data storage

• Dispute initiation
• Evidence submission
• Validator voting
• Appeal mechanisms

• Task Submission Latency: < 1 second
• Provider Matching Time: < 5 seconds
• Execution Start: < 30 seconds
• Result Verification: < 60 seconds
• Payment Settlement: < 2 minutes
• Network Capacity: 1M+ concurrent tasks

• 10,000+ TPS on Layer 2
• Horizontal scaling with provider addition
• Vertical scaling with container orchestration
• Geographic distribution for low latency
• Caching strategies for common tasks

​

Appendix C: References and Reading List

1. Ethereum Yellowpaper (Buterin, Wood)
2. IPFS Whitepaper (Benet)
3. BitTorrent Protocol Specification
4. Docker Security Best Practices
5. Zero-Knowledge Proofs in Distributed Systems

1. Golem Network Whitepaper (https://whitepaper.io/document/21/golem-whitepaper)
2. Akash Network Documentation (https://docs.akash.network/)
3. iExec Network Whitepaper

1. “Proof of Replication” (Proof systems for distributed storage)
2. “The Byzantine Generals Problem” (Consensus mechanisms)
3. “Practical Byzantine Fault Tolerance” (PBFT consensus)
4. “Verifiable Computation” (Result verification methods)

1. Gartner Cloud Market Share Reports
2. IDC Worldwide Infrastructure Survey
3. Forrester Cloud Computing Studies

• Website: centrix.network
• Documentation: docs.centrix.network
• GitHub: github.com/centrix
• Discord: discord.gg/centrix
• Email: info@centrix.network
• Twitter: @centrix_network

• Version: 1.0
• Date: December 2025
• Author: Centrix Foundation
• License: CC0 (Public Domain)
• Repository: github.com/centrix/whitepaper