# RNP-019: Emissions/Rewards for Initial General and AI Compute Network Nodes, a.k.a. the “Render Compute Network”

| RNP # | Title | Category | Authors | Created | Status |
| ----- | --------------------- | -------- | ------------------ | ---------- |------- |
| 019 | Render Compute Network | Network | Render Foundation, Render Labs | 2025-03-31 | Implemented |

# How to Vote
Visit the RENDER FOUNDATION voting page hosted by nation.io. Direct link can be found here https://nation.io/a/RenderNetwork.
You will need to have your $RENDER tokens in a self-custody wallet (i.e. Solflare, Phantom, etc.). 
You will need enough $SOL in your wallet to conduction onchain trasactions (0.1 SOL is more than enough).
Visit the Proposals Page and select the ACTIVE proposal you wish to vote on.
Pick your vote and complete the transaction by signing a message affirming your vote.

# Overview

The Render Network is leveraging the convergence of general and AI compute demand by deploying dedicated GPU nodes, distinct from legacy rendering nodes due to divergent hardware and software requirements. This RNP proposes a sustainable emissions and rewards framework for Open Compute GPU node operators, optimized for these workloads.

This would enable  the Render Network community to drive general and AI compute demand directly to the Network and address customisations directly, using a proven team to manage the distributed compute environment.  

The opportunity is based on demand for various use cases, including AI inference. Examples of potential partners Render would onboard include Manifest and Think Agents. 

Manifest provides enterprise-grade distributed compute nodes with security and IP protections designed to support web3 projects. Their goal is to use the Render Compute Network to architect a distributed LLM framework for clients building AI-powered automated workflows for financial services.

Think Agents is an open protocol for AI agent development. They’ve developed the Think Agent Standard, a framework for builders to create intelligent, onchain AI agents to transact and communicate. It’s a modular, permissionless and composable system that aims to unlock applications across compute, inference, and trusted execution environments. They would run next-generation AI models on the Render Compute Network.

Additional partnership opportunities are expected to emerge upon the launch of the Render Compute Network.

# Selection Process

Initial cohort selection aligns with launch partner specifications, likely including:

* **Location**: Geographically strategic placement.  
* **Hardware**: Approved GPU models (See below).  
* **Bandwidth**: ≥100 Mbps download, ≥75 Mbps upload.  
* **Availability**: Partner-defined uptime thresholds.  
* **Operating System**: Linux-based OS prioritized for Docker stability (Windows/Mac OS deferred to post-launch phase). Initial testing has been on Ubuntu 22.04 and 24.04. Note: Docker is generally faster in Linux since it is virtualised in all other OSs.   
* **Dedicated Nodes**: Segregated from rendering workloads to prevent contention.

The Render Foundation will oversee demand-driven onboarding until a permissionless system is implemented, adjusting emissions accordingly. The long-term vision is a permissionless, scalable compute network.

# Eligibility for Selection and Rewards

Nodes must meet all criteria for selection and emissions eligibility:

1. Deploy GPUs from the approved list, signup URL to be announced.  
2. Onboard via the waitlist, providing a Solana wallet for RENDER deposits.  
3. Be live in the Render Foundation cohort (e.g., Compute Network client deployed and connected).  
4. Sustain bandwidth ≥100 Mbps down, ≥75 Mbps up.  
5. Achieve minimum epoch uptime per launch partner requirements.  
6. Register a wallet pre-reward accrual (prior work ineligible).

# Pricing & Payment Model

Customers fund jobs in fiat (USD) or RENDER, held as credits. Post-job:

* 95% of credits procure RENDER on open markets, burned per the BME model.  
* 5% compensates OTOY for network operations.

Pricing is dynamic, hourly, and benchmarked to industry standards, for example:

* RTX 5090: $0.45–$0.69/hr  
* RTX 4090: $0.35/hr  
* RTX 3090: $0.31/hr

# Node Rewards & Emissions

Compute node operators draw from a reserved tranche of annual RENDER emissions, separate from rendering nodes, with allocations reassessed quarterly or as needed. Rewards initially incentivize availability, transitioning to usage-based as node utilization scales.

For \~100 initial nodes, an estimated 8,500 RENDER/month pool reflects near-full capacity operation with typical specs (e.g., RTX 4090 baseline). This is an estimate, not a cap, with no per-node ceiling, as the cap is intrinsically governed by the number of GPUs and the work performed. The Foundation is authorised to increase these rewards by up to 3x as this is trialed with market forces:

* **Availability Rewards**: 2 RENDER/epoch per node, prorated by uptime (e.g., 50% \= 1 RENDER), epochs aligned weekly with rendering nodes.  
* **Job Rewards**: 10 RENDER/epoch baseline for an RTX 4090 at 100% utilization, scaled by Specification Multiplier (Appendices 1 and 2\) and time worked.  
  * Formula: **10 RENDER × Multiplier × (Hours Worked / 168\)**  
  * Example: RTX 4090, upgraded setup, 100 hours \= 10 × 1.8098 × (100/168) ≈ 10.77 RENDER (Appendix 4, Example 2).

The Render Network facilitates post-epoch payments, providing transparent eligibility and rewards communication. 

## Job Allocation Model

Jobs are allocated via:

1. Customer-specified GPU types.  
2. Rotational assignment, prioritizing nodes with lowest epoch workload, adjusted for uptime. Epoch-end rankings set the next epoch’s starting order.

### GPU Model Scores for Distributed GPU Processing

As the most heavily weighted factor, proposed GPU Model Scores are noted here:

| GPU Model | Performance Class | Score | Reasoning |
| ----- | ----- | ----- | ----- |
| NVIDIA RTX 5090 | High-End | 1.7 | Est. 22,000 CUDA cores, Blackwell, \~70% uplift over RTX 4090 (1.7x per adjusted table). |
| NVIDIA RTX 5090D | High-End | 1.65 | Est. 22,000 CUDA cores, Blackwell, 29% AI perf. drop (TOPS), \~5-10% less in distributed compute vs. 5090 (65% uplift). |
| NVIDIA RTX 4090 | High-End | 1.0 | Baseline: 16,384 CUDA cores, 512 Tensor cores, Ada Lovelace, reference point. |
| NVIDIA RTX 4090D | High-End | 0.95 | 16,384 CUDA cores, Ada Lovelace, \~10-15% Tensor perf. drop, \~5% less in distributed compute vs. 4090\. |
| NVIDIA RTX 4080 | High-End | 0.85 | 9,728 CUDA cores, 304 Tensor cores, 60% of 4090’s cores, same arch (0.85x). |
| NVIDIA RTX 5080 | High-End | 1.35 | Est. 15,000–16,000 CUDA cores, Blackwell, 90-95% of 4090 (1.35x). |
| NVIDIA RTX 5070 Ti | High-End | 1.1 | Est. 11,000–12,000 CUDA cores, Blackwell, 70-75% of 4090 (1.1x). |
| NVIDIA RTX 5070 | High-End | 1.05 | Est. 10,000–11,000 CUDA cores, Blackwell, 65-70% of 4090 (1.05x). |
| NVIDIA RTX 4070 Ti | Mid-Range | 0.75 | 7,680 CUDA cores, 240 Tensor cores, 47% of 4090’s cores, same arch (0.75x). |
| NVIDIA RTX 4070 | Mid-Range | 0.65 | 5,888 CUDA cores, 184 Tensor cores, 36% of 4090’s cores, same arch (0.65x). |
| NVIDIA RTX 4060 Ti | Entry-Level | 0.55 | 4,352 CUDA cores, 136 Tensor cores, 27% of 4090’s cores, same arch (0.55x). |
| NVIDIA RTX 4060 | Entry-Level | 0.5 | 3,072 CUDA cores, 96 Tensor cores, 19% of 4090’s cores, same arch (0.5x). |
| NVIDIA RTX 3090 Ti | High-End | 0.9 | 10,752 CUDA cores, 336 Tensor cores, Ampere, 65% FP32, \~90% efficiency (0.9x). |
| NVIDIA RTX 3090 | High-End | 0.85 | 10,496 CUDA cores, 328 Tensor cores, Ampere, 64% FP32 (0.85x). |
| NVIDIA RTX 3080 Ti | High-End | 0.8 | 10,240 CUDA cores, 320 Tensor cores, Ampere, 62% FP32 (0.8x). |
| NVIDIA RTX 3080-12G | High-End | 0.75 | 8,960 CUDA cores, 280 Tensor cores, Ampere, 55% FP32 (0.75x). |
| NVIDIA RTX 3080 | High-End | 0.7 | 8,704 CUDA cores, 272 Tensor cores, Ampere, 53% FP32 (0.7x). |
| NVIDIA RTX 3070 Ti | Mid-Range | 0.65 | 6,144 CUDA cores, 192 Tensor cores, Ampere, 37% FP32 (0.65x). |
| NVIDIA RTX 3070 | Mid-Range | 0.6 | 5,888 CUDA cores, 184 Tensor cores, Ampere, 36% FP32 (0.6x). |
| NVIDIA RTX 3060 Ti | Entry-Level | 0.55 | 4,864 CUDA cores, 152 Tensor cores, Ampere, 30% FP32 (0.55x). |
| NVIDIA RTX 3060 | Entry-Level | 0.5 | 3,584 CUDA cores, 112 Tensor cores, Ampere, 22% FP32 (0.5x). |
| NVIDIA RTX 3060M | Entry-Level | 0.45 | Mobile, 3,072 CUDA cores (est.), lower clocks, \~18-20% of 4090 (0.45x). |
| NVIDIA RTX 3050 | Entry-Level | 0.4 | 2,560 CUDA cores, 80 Tensor cores, Ampere, 15% FP32 (0.4x). |

The Render Network will facilitate payments and will make best efforts to do so during the epoch following the current epoch.

The Render Network will be responsible for communication, including how to qualify, Rewards earned, and Rewards support.

# Node Utilization & Thresholds

Rewards tie to a dynamic utilization scoring system (availability, uptime, GPU usage), eschewing static thresholds to flag and prune underperformers. A comprehensive scoring model will be published.

# Proof-of-Compute & Hardware Reliability

A proof-of-compute mechanism ensures reliability through periodic cryptographic validation of GPU availability, VRAM, PCIe bandwidth, RAM, thermals, and software integrity, refined via real-world testing.

# Node Staking & Initial Testing Phase

No staking is mandated initially to maximize hardware diversity and accelerate issue detection. Earnings up to $100 are held as an implicit stake, with excess disbursed, balancing onboarding ease with long-term stability.

# Render Network Compute Pool (Optional)

A 0.25%–0.5% RENDER transaction fee could seed a pool for internal workloads (e.g., algorithm simulations, benchmarking, fraud detection) during low utilization (\<80%), bolstering network resilience.

# Testnet Implementation

A Foundation-managed testnet will validate software and nodes pre-launch, ineligible for emissions.

# Stakeholders Impacted

This RNP affects all Render ecosystem participants: current node operators, prospective compute providers, and users.

# Implementation Plan

If the proposal is passed:

* Deploy initial 100-node network.  
* Activate fiat/RENDER payment flow with BME buy-and-burn.  
* Initiate availability rewards.  
* Implement proof-of-compute and utilization scoring.  
* **Scale Node Capacity**: Expand based on metrics: sustained utilization \>80% across nodes, explicit partner capacity requests, or job queue delays \>24 hours.

# Potential Drawbacks

Concurrent rendering and compute workloads risk instability, mandating strict segregation. Initial staking flexibility may yield variable node performance, though it expedites testing and optimization.

# 

# Appendix 1 \- Key Factors for Distributed GPU Processing

**GPU Architecture and Core Count (CUDA Cores / Tensor Cores)**

* **Role**: The GPU’s architecture and core count define the computational power available on each node for parallel processing tasks. CUDA cores enable general-purpose computation, while Tensor Cores (found in consumer-grade RTX GPUs) accelerate specific matrix-based workloads.  
* **Influence**: This factor is foundational because each GPU must handle its portion of the distributed workload efficiently, whether processing independent data chunks or collaborating on a shared task. For instance, an RTX 5090 with \~22,000 CUDA cores offers \~70% more compute capacity than an RTX 4090’s 16,384 cores, factoring in architectural improvements (e.g., Blackwell vs. Ada Lovelace). Network dependencies slightly temper its dominance in distributed systems.  
* **Weighting**: \~36%  
  * Reasoning: As the primary compute engine, it holds the highest weighting. The 36% reflects its critical role in local task execution, moderated by the need for inter-node coordination, which introduces overhead not present in standalone setups.  
* **Minimum Recommended Specs**: NVIDIA RTX 4090 (24 GB, 16,384 CUDA cores) provides a strong baseline for consumer-grade distributed compute, with Tensor Cores boosting efficiency for matrix-heavy tasks. The RTX 5090 (est. 32 GB, 22,000 CUDA cores) offers a significant upgrade.

**VRAM (Video RAM)**

* **Role**: VRAM stores data, intermediate results, and task-specific resources on each GPU. In distributed systems, workloads may be split across GPUs, requiring sufficient VRAM to manage these segments locally.  
* **Influence**: Adequate VRAM capacity and fast PCIe bus speeds (e.g., 16x lanes) are critical for processing large workloads without offloading to slower system RAM or network buffers. For a 140 GB task across four RTX 4090s (24 GB each, 96 GB total), partitioning is needed; 32 GB (e.g., RTX 5090\) reduces this, while higher PCIe bandwidth (not 1x risers) prevents transfer bottlenecks, boosting efficiency. Low VRAM or limited PCIe lanes (e.g., 1x) degrade throughput by throttling data flow.  
* **Weighting**: \~26%  
  * Reasoning: Second to GPU cores, VRAM’s 26% weighting highlights its importance in memory-intensive distributed tasks. It’s slightly less critical than core count due to workload partitioning options, but remains a key limiter for large-scale processing.  
* **Minimum Recommended Specs**: 24 GB per GPU (e.g., RTX 3090 or 4090\) supports typical distributed workloads; 32 GB (e.g., RTX 5090\) is recommended for larger or more complex computations.

**Upload/Download Speeds (Network Bandwidth)**

* **Role**: Network bandwidth determines the rate at which data travels between GPUs across nodes, encompassing both the transfer of data to GPUs (upload) and the retrieval of results from GPUs (download). It plays a vital role in coordinating tasks and consolidating outputs in distributed systems.  
* **Influence**: Network bandwidth is a crucial element in distributed computing, significantly affecting system performance. It acts as a key constraint by dictating how efficiently nodes exchange data, with its impact increasing as tasks require more frequent or larger data transfers between GPUs.  
* **Weighting**: \~15%  
  * Reasoning: Assigned 15%, network bandwidth is essential for enabling effective communication between GPUs, though its contribution is secondary to the local processing and memory capabilities of each node. Its importance scales with the level of task interdependence and the volume of data moved across the system.  
* **Minimum Recommended Specs**: A baseline of 400 Mbps download and 300 Mbps upload supports typical distributed workloads efficiently. A minimum of 100 Mbps download and 75 MB/s upload is viable for smaller or less demanding setups, though it restricts performance.

**Clock Speed (Base and Boost)**

* **Role**: Clock speed determines the rate of local computations on each GPU, reducing processing time for individual tasks or subtasks within a distributed system.  
* **Influence**: Higher clock speeds enhance on-device compute efficiency, directly impacting throughput when workloads fit in VRAM. For example, the RTX 4090’s 2.2/2.5 GHz vs. the RTX 5090’s 2.5/2.8 GHz offers a \~12% per-computation boost, significant for VRAM-resident tasks. If data spills to system RAM, PCIe bandwidth limits gains, but clock speed remains relevant unless off-device network transfers dominate—an order-of-magnitude slower scenario addressed by VRAM optimization.  
* **Weighting**: \~8%  
  * Reasoning: Assigned 8% due to its secondary role in distributed systems, where network and compute capacity dominate. It still aids local performance, warranting a modest weighting.  
* **Minimum Recommended Specs**: 2.2 GHz base, 2.5 GHz boost (RTX 4090\) is the baseline; 1.4 GHz base, 1.7 GHz boost (RTX 3090\) is viable but slower.

**Memory Bandwidth (VRAM Bandwidth)**

* **Role**: Memory bandwidth dictates the speed of data transfer between VRAM and GPU cores on each node, ensuring rapid access to task data and intermediate results during computation.  
* **Influence**: High bandwidth enhances local processing efficiency, particularly for data-intensive tasks. RTX 4090’s 1410 MB/s vs. RTX 5090’s 1800 MB/s (\~28% increase) speeds up memory operations, but in distributed systems, network bandwidth often bottlenecks overall performance more than local VRAM access. It’s significant but not a primary limiter.  
* **Weighting**: \~8%  
  * Reasoning: At 8%, it reflects its importance to local efficiency, balanced against the greater impact of network constraints in distributed setups. It matches clock speed’s weighting due to a comparable secondary role.  
* **Minimum Recommended Specs**: 1410 MB/s (GDDR6X, RTX 4090\) is the baseline; 936 MB/s (RTX 3090\) is acceptable but less efficient.

**CPU (Central Processing Unit)**

* **Role**: The CPU oversees task scheduling, data pre-processing, and network communication across nodes, ensuring effective coordination in distributed compute environments.  
* **Influence**: Depending on the task, a robust CPU (e.g., 16-core/4.5 GHz) improves setup and sync efficiency, slightly more relevant in distributed systems than standalone ones due to multi-node management. However, it’s secondary to GPU and network factors, as compute tasks are GPU-driven. A weaker CPU (e.g., 4-core) may slow initialization but rarely caps runtime performance.  
* **Weighting**: \~4%  
  * Reasoning: Its 4% weighting recognizes its support role, slightly elevated for distributed coordination, but dwarfed by GPU-centric factors that drive the bulk of processing.  
* **Minimum Recommended Specs**: 8-core/16-thread at 3.0 GHz (e.g., AMD Ryzen 7 5700X) is the baseline; 16-core/32-thread at 4.5 GHz (e.g., Ryzen 9 7950X) enhances management efficiency.

**System RAM (CPU RAM)**

* **Role**: System RAM buffers data for CPU operations and handles overflow if VRAM capacity is exceeded, though this is uncommon in optimized distributed setups.  
* **Influence**: Its impact is minimal, as distributed compute tasks typically reside in VRAM or network pipelines. It becomes relevant only in edge cases (e.g., VRAM overflow), where 128 GB DDR5 offers a slight buffering advantage over 64 GB DDR4 for large datasets before GPU transfer.  
* **Weighting**: Not weighted  
  * Reasoning: Excluded from weighting due to its negligible runtime impact, affecting only pre-processing or rare overflow situations rather than core distributed performance.  
* **Minimum Recommended Specs**: 64 GB DDR4 per node ensures functionality; 128 GB DDR5 is recommended for setups with significant buffering or preprocessing needs.

**Storage (HDD/SSD)**

* **Role**: Storage manages initial data loading and logging across nodes, with NVMe SSDs reducing startup times compared to slower HDDs.  
* **Influence**: Its effect is minor during runtime, as distributed compute relies on in-memory data (VRAM). A 1 TB NVMe SSD at 7 GB/s loads a 140 GB dataset in \~20 seconds, vs. minutes for an HDD, but this impacts only initialization or logging, not ongoing task execution.  
* **Weighting**: Not weighted  
  * Reasoning: Omitted from weighting because it doesn’t affect runtime performance, influencing only startup or checkpointing phases, which are secondary to core processing.  
* **Minimum Recommended Specs**: 1 TB NVMe SSD per node (e.g., Samsung 990 Pro) at 7 GB/s read/write is the baseline for efficient loading; higher specs (e.g., 2 TB, 14 GB/s) further minimize startup delays.

# Appendix 2 \- Specs and Performance Multiplier Scale with RTX 4090 and Medium Speed as Baseline

| Factor | Weighting | Baseline Recommended Specs (Multiplier \= 1\) | Performance Multiplier Scale | Explanation of Scale |
| ----- | ----- | ----- | ----- | ----- |
| **GPU Architecture/ Cores** | 36% (0.36) | NVIDIA RTX 4090 (24 GB, 16,384 CUDA cores) | \- 1.7: RTX 5090 (est. 32 GB, 22,000 CUDA cores)  \- 1: RTX 4090  \- 0.5: RTX 3060 (12 GB, 3,584 CUDA cores)  \- 0: GTX 1650 (4 GB, 896 CUDA cores) | \~1.7x reflects 60-80% uplift (cores \+ efficiency); 0.5 \~1/3 performance; 0 is minimal. |
| **VRAM** | 26% (0.26) | 24 GB per GPU (Minimum per spec) | \- 1.33: 32 GB (e.g., RTX 5090\)  \- 1: 24 GB (RTX 3090/4090)  \- 0.5: 12 GB  \- 0: 4 GB | 32/24 ≈ 1.33x capacity; linear scaling; below 24 GB violates spec. |
| **Upload/Download Speeds** | 15% (0.15) | 400 Mbps down, 300 Mbps up (Medium Speed) | \- 4: 1600/1200 Mbps (Ultra High)  \- 1: 400/300 Mbps (Medium)  \- 0.25: 100/75 Mbps (Low)  \- 0: \<100/\<75 Mbps (e.g., 50/25 Mbps) | 1600/400 \= 4x throughput; 100/400 \= 0.25x; below 100/75 Mbps impractical. |
| **Clock Speed** | 8% (0.08) | 2.2 GHz base, 2.5 GHz boost (RTX 4090\) | \- 1.12: 2.5/2.8 GHz (est. RTX 5090\)  \- 1: 2.2/2.5 GHz  \- 0.68: 1.4/1.7 GHz (RTX 3090\)  \- 0: 0.8/1.0 GHz | 2.8/2.5 ≈ 1.12x; 1.7/2.5 ≈ 0.68x; linear latency scaling. |
| **Memory Bandwidth** | 8% (0.08) | 1410 MB/s (GDDR6X, RTX 4090\) | \- 1.28: 1800 MB/s (est. GDDR7, RTX 5090\)  \- 1: 1410 MB/s  \- 0.66: 936 MB/s (RTX 3090\)  \- 0: 224 MB/s | 1800/1410 ≈ 1.28x; 936/1410 ≈ 0.66x; scales data flow. |
| **CPU** | 4% (0.04) | 8-core/16-thread, 3.0 GHz (Minimum per spec) | \- 1.5: 16-core/32-thread, 4.5 GHz (Ryzen 9 7950X)  \- 1: 8/16, 3.0 GHz (Ryzen 7 5700X)  \- 0.5: 4/8, 2.5 GHz  \- 0: 2/4, 1.5 GHz | 16/8 cores \+ 4.5/3.0 GHz ≈ 1.5x; 4/8 ≈ 0.5x; orchestration scaling. |
| **System RAM** | N/A | Minimum: 64 GB DDR4 | Not weighted; 128 GB DDR5 recommended for premium tasks. | Minimal runtime impact. |
| **Storage** | N/A | Minimum: 1 TB NVMe SSD, 7 GB/s | Not weighted; 2 TB NVMe, 14 GB/s recommended for faster loading. | Negligible runtime impact. |

# Appendix 3 \- Formula

## Generic Weighting Formula for Distributed GPU Processing

The **Compound Multiplier (CM)** quantifies the overall performance of a distributed GPU processing system relative to a baseline configuration. It is calculated as the sum of the products of each factor’s weighting and its performance multiplier:

CM \= Σ (W\_i × M\_i)

Where:

* **W\_i**: Weighting of factor (i) (as a decimal, e.g., 36% \= 0.36), representing its relative importance to overall system performance in distributed compute tasks.  
* **M\_i**: Performance Multiplier of factor (i), a normalized score indicating how a specific specification compares to the baseline (e.g., 1 \= baseline, 1.7 \= enhanced, 0.5 \= reduced, 0 \= minimum viable).  
* **Σ**: Summation over all weighted factors.

Factors and Their Weightings  
The system includes six weighted factors, based on their contribution to distributed GPU processing, with System RAM and Storage excluded due to minimal runtime impact:

1. **GPU Architecture and Core Count (W\_GPU)**: 0.36  
   * Logic: The primary driver of local compute power, critical for parallel task execution across nodes.  
2. **VRAM (W\_VRAM)**: 0.26  
   * Logic: Essential for storing data and task segments locally, supporting efficient processing without excessive offloading.  
3. **Upload/Download Speeds (W\_Network)**: 0.15  
   * Logic: Governs inter-node data exchange, a key bottleneck in distributed coordination.  
4. **Clock Speed (W\_Clock)**: 0.08  
   * Logic: Influences local computation speed, secondary due to network and throughput focus.  
5. **Memory Bandwidth (W\_MemBW)**: 0.08  
   * Logic: Enhances local data access efficiency, less dominant than network bandwidth in distributed setups.  
6. **CPU (W\_CPU)**: 0.04  
   * Logic: Supports orchestration and preprocessing, minor compared to GPU-centric factors.

Total weighting sums to 1.0 (100%):

**W\_GPU \+ W\_VRAM \+ W\_Network \+ W\_Clock \+ W\_MemBW \+ W\_CPU \= 0.36 \+ 0.26 \+ 0.15 \+ 0.08 \+ 0.08 \+ 0.04 \= 1.0**

Explicit Formula  
Substituting the specific weightings:

**CM \= (0.36 × M\_GPU) \+ (0.26 × M\_VRAM) \+ (0.15 × M\_Network) \+ (0.08 × M\_Clock) \+ (0.08 × M\_MemBW) \+ (0.04 × M\_CPU)**

Multiplier Scale Logic

* **M\_i \= 1**: Baseline spec (e.g., RTX 4090 with 16,384 CUDA cores, 400/300 Mbps network), standard performance.  
* **M\_i \> 1**: Enhanced performance (e.g., RTX 5090 at 1.7 for GPU, 1600/1200 Mbps at 4 for Network), reflecting proportional gains.  
* **M\_i \< 1**: Reduced performance (e.g., RTX 3060 at 0.5 for GPU, 100/75 Mbps at 0.25 for Network), still above minimum.  
* **M\_i \= 0**: Minimum viable spec (e.g., GTX 1650, \<100/\<75 Mbps), below which functionality is impractical.

Unweighted Factors

* **System RAM**: Minimum spec (e.g., 64 GB DDR4) ensures basic operation but doesn’t significantly affect runtime performance, thus unweighted.  
* **Storage**: Minimum spec (e.g., 1 TB NVMe, 7 GB/s) impacts load times, not runtime throughput, so unweighted.

# 

# Appendix 4 \- Examples

**1\. Baseline Setup (All Multiplier \= 1\)**

* **Description**: A standard configuration with an RTX 4090 and Medium Speed network, operating at baseline capacity for distributed GPU processing.

| Factor | Weighting | Spec | Multiplier | Weighting × Multiplier |
| ----- | ----- | ----- | ----- | ----- |
| GPU Architecture/Cores | 36% (0.36) | RTX 4090 (24 GB, 16,384 CUDA cores) | 1 | 0.36 × 1 \= 0.36 |
| VRAM | 26% (0.26) | 24 GB per GPU | 1 | 0.26 × 1 \= 0.26 |
| Upload/Download Speeds | 15% (0.15) | 400/300 Mbps (Medium Speed) | 1 | 0.15 × 1 \= 0.15 |
| Clock Speed | 8% (0.08) | 2.2 GHz base, 2.5 GHz boost (RTX 4090\) | 1 | 0.08 × 1 \= 0.08 |
| Memory Bandwidth | 8% (0.08) | 1410 Mbps (RTX 4090\) | 1 | 0.08 × 1 \= 0.08 |
| CPU | 4% (0.04) | 8-core/16-thread, 3.0 GHz (Ryzen 7 5700X) | 1 | 0.04 × 1 \= 0.04 |
| System RAM | N/A | 64 GB DDR4 | N/A | Not weighted |
| Storage | N/A | 1 TB NVMe SSD, 7 GB/s | N/A | Not weighted |

* **Compound Multiplier (CM)**: 0.36 \+ 0.26 \+ 0.15 \+ 0.08 \+ 0.08 \+ 0.04 \= **0.97** (\~1.0)  
* **Reward Calculation**: For 100 hours worked in a 168-hour epoch:  
  **10 RENDER × 1.0 × (100 / 168\) \= 10 × 0.5952 ≈ 5.95 RENDER**  
  ---

**2\. Mixed Upgraded Setup (Mix of Higher Multipliers)**

* **Description**: An enhanced setup with an RTX 5090, Ultra High Speed network, and upgraded CPU, optimized for high-capacity distributed compute tasks.

| Factor | Weighting | Spec | Multiplier | Weighting × Multiplier |
| ----- | ----- | ----- | ----- | ----- |
| GPU Architecture/Cores | 36% (0.36) | RTX 5090 (est. 32 GB, 22,000 CUDA cores) | 1.7 | 0.36 × 1.7 \= 0.612 |
| VRAM | 26% (0.26) | 32 GB (RTX 5090\) | 1.33 | 0.26 × 1.33 \= 0.3458 |
| Upload/Download Speeds | 15% (0.15) | 1600/1200 MB/s (Ultra High Speed) | 4 | 0.15 × 4 \= 0.6 |
| Clock Speed | 8% (0.08) | 2.5 GHz base, 2.8 GHz boost (RTX 5090\) | 1.12 | 0.08 × 1.12 \= 0.0896 |
| Memory Bandwidth | 8% (0.08) | 1800 MB/s (RTX 5090\) | 1.28 | 0.08 × 1.28 \= 0.1024 |
| CPU | 4% (0.04) | 16-core/32-thread, 4.5 GHz (Ryzen 9 7950X) | 1.5 | 0.04 × 1.5 \= 0.06 |
| System RAM | N/A | 128 GB DDR5 | N/A | Not weighted |
| Storage | N/A | 1 TB NVMe SSD, 7 GB/s | N/A | Not weighted |

* **Compound Multiplier (CM)**: 0.612 \+ 0.3458 \+ 0.6 \+ 0.0896 \+ 0.1024 \+ 0.06 \= **1.8098** (\~1.81)  
* **Reward Calculation**: For 100 hours worked in a 168-hour epoch:  
  **10 RENDER × 1.81 × (100 / 168\) \= 10 × 1.81 × 0.5952 ≈ 10.77 RENDER**  
  ---

**3\. Mixed Lower Setup (Mix of 1 and Lower Multipliers)**

* **Description**: A cost-effective setup with an RTX 4090, reduced network, clock, and bandwidth specs, still above minimum requirements for distributed processing.

| Factor | Weighting | Spec | Multiplier | Weighting × Multiplier |
| ----- | ----- | ----- | ----- | ----- |
| GPU Architecture/Cores | 36% (0.36) | RTX 4090 (24 GB, 16,384 CUDA cores) | 1 | 0.36 × 1 \= 0.36 |
| VRAM | 26% (0.26) | 24 GB (RTX 4090\) | 1 | 0.26 × 1 \= 0.26 |
| Upload/Download Speeds | 15% (0.15) | 100/75 MB/s (Low Speed) | 0.25 | 0.15 × 0.25 \= 0.0375 |
| Clock Speed | 8% (0.08) | 1.4 GHz base, 1.7 GHz boost (RTX 3090\) | 0.68 | 0.08 × 0.68 \= 0.0544 |
| Memory Bandwidth | 8% (0.08) | 936 MB/s (RTX 3090\) | 0.66 | 0.08 × 0.66 \= 0.0528 |
| CPU | 4% (0.04) | 8-core/16-thread, 3.0 GHz (Ryzen 7 5700X) | 1 | 0.04 × 1 \= 0.04 |
| System RAM | N/A | 64 GB DDR4 | N/A | Not weighted |
| Storage | N/A | 1 TB NVMe SSD, 7 GB/s | N/A | Not weighted |

* **Compound Multiplier (CM)**: 0.36 \+ 0.26 \+ 0.0375 \+ 0.0544 \+ 0.0528 \+ 0.04 \= **0.8047** (\~0.80)  
* **Reward Calculation**: For 100 hours worked in a 168-hour epoch:  
  **10 RENDER × 0.80 × (100 / 168\) \= 10 × 0.80 × 0.5952 ≈ 4.76 RENDER**