Performance Index & Payouts
How your earnings are calculated
Section titled “How your earnings are calculated”Every node on the Evolving Edge network earns a Performance Index (PI) — a score between 0 and 1 that reflects the real-world value your node delivers to the network. That score directly determines what percentage of your node’s generated revenue you receive each month.
The core principle is straightforward: you are paid for what your node actually delivers, not for the hardware sitting on your shelf. A mid-range machine that runs reliably and completes workloads consistently will out-earn a high-spec node that is unstable or unavailable. Your payout is derived entirely from observed performance during active content delivery.
Scoring is fully automated. The lightweight telemetry agent built into the node software collects metrics continuously from live workloads. There are no manual reports, no forms to submit, and no synthetic benchmark tests to run.
How the math works
Section titled “How the math works”Your payout is calculated in two steps.
Step 1: Your Hardware Baseline determines your Base Tier — the maximum revenue share percentage your node can earn.
Step 2: Your Final PI is applied as a multiplier against that Base Tier, adjusting for how your node actually performed across all five components during real-world delivery.
Final Payout % = Base Tier % × Final PIFinal PI = (Hardware Baseline × 0.20) + (Uptime & Reliability × 0.25) + (Delivery Performance × 0.30) + (Observed Capacity Peaks × 0.15) + (Telemetry Stability × 0.10)Payouts are capped at 25% of the revenue your specific node generated. There is no guaranteed minimum payout; earnings scale directly with the workloads your node performs and the value it delivers. Cash bonuses are awarded for referring node operators to the network, among other achievements.
Base Tier: your hardware sets the ceiling
Section titled “Base Tier: your hardware sets the ceiling”Your Hardware Baseline (detailed below) places you into one of five Base Tiers. This is your earnings ceiling. Your Final PI then determines how close to that ceiling you actually reach.
| Hardware Baseline | Base Tier % |
|---|---|
| 0.00 – 0.35 | 8% |
| 0.36 – 0.55 | 12% |
| 0.56 – 0.75 | 18% |
| 0.76 – 0.90 | 22% |
| 0.91 – 1.00 | 25% (maximum) |
Two nodes in the same Base Tier can earn meaningfully different amounts depending on their Final PI. A node in the 22% tier with a PI of 0.90 earns 19.8%. The same tier with a PI of 0.96 earns 21.1%. Real-world performance matters more than theoretical capacity.
The five components
Section titled “The five components”1. Hardware Baseline (20%) — what your node is capable of
Section titled “1. Hardware Baseline (20%) — what your node is capable of”This measures the theoretical capacity of your hardware — CPU, RAM, and network — normalized against the highest values observed across the entire network. It tells us what your node can do, not what it is doing. Better hardware earns a higher Base Tier ceiling, but it does not substitute for actually showing up and performing.
| Component | How it’s measured |
|---|---|
| CPU | Core count × clock speed (GHz), scaled to the network maximum |
| RAM | Capacity (GB) × bandwidth (GB/s), scaled to the network maximum |
| Network | Upload bandwidth (Mbps), capped at 200 Mbps |
Minimum to participate: 10 Mbps upload. Nodes below this threshold are not eligible for the network.
GPU: If your node has a GPU, its VRAM and TFLOPS are detected and displayed on your operator dashboard. However, GPU specifications do not contribute to your Phase One score or payout. They are tracked for informational purposes and future-phase eligibility.
Example: A node with an 8-core CPU at 4.0 GHz, 32GB DDR5 RAM, and 180 Mbps upload earns a Hardware Baseline of approximately 0.88 — landing in the 22% Base Tier.
2. Uptime & Reliability (25%) — showing up consistently
Section titled “2. Uptime & Reliability (25%) — showing up consistently”This is not simply a binary “online or offline” check. The system distinguishes between types of downtime and applies weighted penalties accordingly, because an ISP outage is not equivalent to rebooting your node mid-task.
Uptime & Reliability = (Total Operational Intervals / Total Possible Intervals) × Weighted Reliability Factor (WRF)| Downtime Cause | WRF Multiplier | What it means |
|---|---|---|
| Planned maintenance | ×1.0 | No penalty — you notified the system ahead of time |
| ISP or power outage | ×0.8 | Partial penalty — outside your control |
| Overheating crash | ×0.5 | Significant penalty — preventable with proper cooling |
| Reboot during active task | ×0.3 | Highest penalty — directly disrupts customer delivery |
Example: A node with 90% raw uptime where 20% of the downtime was ISP-related receives an Uptime & Reliability score of approximately 0.92.
The WRF system ensures you are not heavily penalized for infrastructure failures outside your control, while holding you accountable for factors you can manage — such as thermal stability and avoiding disruptive restarts during active delivery.
3. Delivery Performance (30%) — what you actually delivered
Section titled “3. Delivery Performance (30%) — what you actually delivered”This is the most heavily weighted component in Phase One. It measures what your node actually did for paying customers during active content delivery — not theoretical capacity, not idle availability. During Phase One, the network serves encrypted payloads without on-node decryption or computation; performance is measured strictly by content delivery quality.
Delivery Performance = (Cache Hit Ratio × 0.40) + (TTFB Score × 0.35) + (Request Success Rate × 0.25)| Metric | What it measures | Target |
|---|---|---|
| Cache Hit Ratio | % of requests served from your local cache vs. fetched from origin | >90% |
| Time to First Byte (TTFB) | Latency for a 10KB asset | <25ms |
| Request Success Rate | Completed valid requests as a % of total assigned | >98% |
If ISP throttling is detected, your score is adjusted to reflect your actual deliverable throughput rather than your hardware’s theoretical maximum.
Example: A node with a 92% cache hit ratio, 8ms TTFB, and 99% request success rate scores approximately 0.92 on Delivery Performance.
Phase Two and beyond: When AI inference and general compute workloads are introduced, Delivery Performance will expand to include workload-type sub-scores. During Phase One, all nodes are evaluated on CDN delivery metrics alone.
4. Observed Capacity Peaks (15%) — validating capacity under real load
Section titled “4. Observed Capacity Peaks (15%) — validating capacity under real load”Unlike traditional benchmark tests, this component is derived entirely from actual delivery workloads. The system does not run synthetic stress tests. Instead, it observes your node’s performance during active service and records the 95th percentile of 5-minute sustained windows over a trailing 30-day period.
| Metric | What it measures |
|---|---|
| CPU Throughput | Sustained CPU utilization during active content delivery, retained as a forward-looking placeholder for Phase Three general compute |
| Network Upload | Sustained upload bandwidth achieved while serving real traffic |
| Cache I/O | Read/write performance on the active cache partition during live operations |
New node protection: For the first 14 days of a node’s active lifecycle, the Observed Capacity Peaks component falls back to the Hardware Baseline score. This prevents cold-start starvation — a node cannot demonstrate peak delivery performance until it has received sufficient workloads. After day 14, it transitions to live observed data.
Example: A node demonstrating strong CPU throughput, 170 Mbps sustained upload, and responsive cache I/O during active periods scores approximately 0.88 on Observed Capacity Peaks.
No GPU inference or compute stress tests are run in Phase One. If you have a GPU, it is not evaluated during this phase. The locked “Phase 2: AI Inference” module on your dashboard indicates when inference benchmarks will become active.
5. Telemetry Stability (10%) — keeping your house in order
Section titled “5. Telemetry Stability (10%) — keeping your house in order”This component measures the consistency of your node’s operating environment. Excellent hardware with poor thermal management or excessive host OS resource consumption will show up here.
| Metric | What’s being measured | When it triggers a penalty |
|---|---|---|
| Thermal Throttling Events | Frequency and duration of CPU throttling | Any sustained throttling during active workloads |
| Disk I/O Latency | Average read/write latency | >50ms average |
| Resource Contention | % of RAM and CPU consumed by host OS vs. node software | Excessive host OS consumption |
| Process Isolation | Container stability over the 7-day measurement window | Crashes, unexpected restarts, or container failures |
Example: A node with no thermal throttling, average disk I/O under 10ms, and minimal host OS resource consumption earns a Telemetry Stability score of approximately 0.95.
Payout examples
Section titled “Payout examples”Example 1: High-performance node with consistent delivery
Section titled “Example 1: High-performance node with consistent delivery”| Component | Weight | Score | Weighted Value |
|---|---|---|---|
| Hardware Baseline | 0.20 | 0.92 | 0.184 |
| Uptime & Reliability | 0.25 | 0.96 | 0.240 |
| Delivery Performance | 0.30 | 0.90 | 0.270 |
| Observed Capacity Peaks | 0.15 | 0.88 | 0.132 |
| Telemetry Stability | 0.10 | 0.94 | 0.094 |
| Final PI | 0.920 |
Hardware Baseline 0.92 → Base Tier 25%
Final Payout % = 25% × 0.920 = 23.00%Node generated $50 in revenue → Payout: $11.50
Example 2: Mid-range node with strong reliability
Section titled “Example 2: Mid-range node with strong reliability”| Component | Weight | Score | Weighted Value |
|---|---|---|---|
| Hardware Baseline | 0.20 | 0.78 | 0.156 |
| Uptime & Reliability | 0.25 | 0.99 | 0.2475 |
| Delivery Performance | 0.30 | 0.93 | 0.279 |
| Observed Capacity Peaks | 0.15 | 0.91 | 0.1365 |
| Telemetry Stability | 0.10 | 0.97 | 0.097 |
| Final PI | 0.916 |
Hardware Baseline 0.78 → Base Tier 22%
Final Payout % = 22% × 0.916 = 20.15%Node generated $50 in revenue → Payout: $10.08
This is the example worth studying. A mid-range node with excellent uptime, strong delivery consistency, and reliable observed peaks outperforms its hardware ceiling because of its operational quality. Consistency beats specs.
Example 3: High-spec node with poor operational consistency
Section titled “Example 3: High-spec node with poor operational consistency”| Component | Weight | Score | Weighted Value |
|---|---|---|---|
| Hardware Baseline | 0.20 | 0.94 | 0.188 |
| Uptime & Reliability | 0.25 | 0.74 | 0.185 |
| Delivery Performance | 0.30 | 0.71 | 0.213 |
| Observed Capacity Peaks | 0.15 | 0.68 | 0.102 |
| Telemetry Stability | 0.10 | 0.68 | 0.068 |
| Final PI | 0.756 |
Hardware Baseline 0.94 → Base Tier 25%
Final Payout % = 25% × 0.756 = 18.90%Node generated $50 in revenue → Payout: $9.45
Despite sitting in the 25% Base Tier, this node earns less than the mid-range node in Example 2. Overheating crashes reduced Uptime & Reliability. Inconsistent cache performance dragged down Delivery Performance. Thermal throttling and host OS contention hurt Telemetry Stability. Expensive hardware is not a substitute for a well-run node.
Your performance dashboard
Section titled “Your performance dashboard”Log into portal.3dge.app to see a live breakdown of your five PI components and your current payout percentage. You will find:
- Your current PI score and each component sub-score
- Cache hit ratio, TTFB, and request success rate (Delivery Performance)
- Rolling 30-day Observed Capacity Peaks and your 14-day new-node status
- Thermal and stability event history (Telemetry Stability)
- Uptime & Reliability score with a breakdown of downtime causes
- Your current Base Tier and estimated payout for the billing period
- A read-only hardware inventory showing GPU presence if applicable
- A locked “Phase 2: AI Inference” module visible on all dashboards
Dashboard stats update continuously from live telemetry. Observed Capacity Peak scores refresh as new 5-minute sustained windows are recorded. There are no synthetic 24-hour benchmark cycles.
What changes in each phase
Section titled “What changes in each phase”The five PI components and their weights remain constant across all three phases. What changes is the measurement surface as new workload types come online.
| Component | Phase One (Now) | Phase Two — AI Inference (at GA) | Phase Three — General Compute (at GA) |
|---|---|---|---|
| Hardware Baseline | Active; CPU, RAM, and network scored | No change | No change |
| Uptime & Reliability | Active | No change | No change |
| Delivery Performance | CDN delivery metrics only | CDN metrics remain active | CDN metrics remain active |
| Observed Capacity Peaks | CPU throughput, network upload, cache I/O from active workloads | No change; CPU throughput remains relevant | No change; CPU throughput becomes primary for general compute |
| Telemetry Stability | Active | No change | No change |
| AI Inference Benchmark | Not scored; GPU detected for info only | Activates for GPU nodes | Not applicable |
| Compute Stress Test | Not active | Activates for combined CPU/GPU load validation | Activates for general compute validation |
If you are planning a GPU upgrade ahead of Phase Two, the hardware inventory will reflect it, but your Phase One payout is unaffected by GPU presence. The locked dashboard module indicates when inference capabilities will be evaluated, but no earning potential is projected or guaranteed for future phases.
Common questions
Section titled “Common questions”Why does Hardware Baseline set the Base Tier instead of Final PI? Hardware Baseline is the most stable, slow-moving signal — it reflects the capacity your node brings to the network and does not swing month to month. Using it as the tier anchor makes earnings potential predictable: invest in better CPU, RAM, or network, and your ceiling rises. But you still must perform to realize that potential.
Can a mid-range node hit the 25% maximum? Yes — if your Hardware Baseline is ≥0.91 (Base Tier 25%) and your Final PI is 1.0. Since GPU does not contribute to Phase One Hardware Baseline, reaching the 25% tier requires strong CPU, RAM, and network specs. However, the practical path to maximizing earnings is strong uptime, consistent delivery, and operational stability — not just hardware upgrades.
My ISP had an outage and my uptime dropped. Am I getting penalized? ISP and power outages apply a ×0.8 Weighted Reliability Factor — a partial adjustment, not the severe ×0.3 penalty applied to preventable issues like rebooting during active tasks. The system distinguishes between what is within your control and what is not.
My Delivery Performance score is low but my node is online. What is happening? Delivery Performance measures what you actually delivered during active service, not just availability. If your cache hit ratio is low, your TTFB is high, or you are seeing elevated request failures during traffic periods, that is what drives the score down. Check your dashboard sub-metrics to identify the specific lever to pull.
Will Phase Two change my score? If you are serving CDN-only workloads: no. Your Delivery Performance score continues to be calculated from CDN metrics. If you have a GPU and begin serving AI inference workloads after Phase Two launches, your Delivery Performance will incorporate inference execution metrics based on your workload mix. Observed Capacity Peaks will also begin evaluating GPU inference throughput for qualifying nodes.
Are there separate bonuses? Yes. Uptime bonuses and referral bonuses exist as separate incentive programs. They are not part of the standard Performance Index and are not included in the 25% cap. Details are available in your operator portal.
Getting paid
Section titled “Getting paid”Supported payout methods
Section titled “Supported payout methods”Payouts are issued in U.S. dollars through:
- ACH direct deposit
- Visa and Mastercard debit cards
Minimum payout threshold
Section titled “Minimum payout threshold”You must earn at least $20 before a payout is processed. Amounts below this threshold roll forward to the following month automatically. This keeps transaction costs manageable and allows the platform to maintain competitive payout rates. There is no guaranteed minimum earning floor.
Requesting a payout
Section titled “Requesting a payout”A step-by-step payout request flow is coming soon. This page will be updated when the feature is live.
Payout history and status
Section titled “Payout history and status”Once the payout flow is live, you will be able to track Confirmed, Pending, and Failed requests directly in the portal.
Identity verification
Section titled “Identity verification”Identity verification is required before processing payouts. This is a regulatory requirement that protects both operators and the platform. Full verification instructions, processing times, and troubleshooting guidance are coming soon.