Understanding Dispersed: A Comprehensive Overview

Key Insights

• Dispersed is a compute subnet of the Render Network ecosystem that turns a globally distributed set of GPUs into an on-demand marketplace for AI and general-purpose compute. The Render Network Foundation announced Dispersed on Dec. 12, 2025, after governance approval through proposals RNP-019 and RNP-021.
• Dispersed targets a mismatch in the AI economy where demand for accelerated compute is rising faster than hyperscalers can supply it, while 95% of GPUs are underutilized according to Cast AI. Dispersed routes work to GPUs wherever they sit, pairing buyers who need compute with operators who hold spare capacity.
• The marketplace contains two actors. Node Operators register their idle GPUs and earn RENDER for availability and completed work. Service consumers submit jobs specifying hardware and a container image, then rent GPUs to run their AI workloads.
• Early use cases span automation of creative tools for artists, autonomous agents, scientific research, and personal-data infrastructure. Foundational teams use Dispersed for the compute that their agents need.
• Most service consumers pay for compute in fiat, which is added to their accounts as credit. As consumers complete work on the network GPUs, the credit is converted to the RENDER token at the current rate; 5% is paid to the service provider, OTOY; and the remaining 95% is burned, providing a direct value accrual mechanism for RENDER.

Introduction

The AI boom has created a dislocation in the market for computing power. GPUs are in short supply, yet many of those already deployed sit idle. Training and serving modern models burns through accelerators, high-performance chips that are faster and more efficient at mathematical operations used in AI tasks than traditional CPUs, faster than even the largest cloud providers can install them, and the shortage now sets the price. In 2026, AWS raised reserved pricing on its H200 instances, reversing nearly two decades of steadily falling cloud costs, while bottlenecks in high-bandwidth memory and advanced packaging are expected to keep supply tight into 2027. For the developers and enterprises that need computing the most, that means higher bills and waitlists for hardware they still cannot get.

The same market that is short on GPUs is also leaving many of them idle. Much of the capacity already in place goes unused by the owners, even as other buyers compete for more, with average enterprise GPU utilization estimated near 5%. For every dollar spent on silicon, most of it never converts into actual work. That idle capacity exists everywhere companies overbought, spread across hyperscaler data centers, rendering studios, and individual workstations, yet few efficient markets connect that capacity to the people who would gladly pay to use it.

The hyperscaler model cannot solve both at once because the same shortage that is inflating prices is exactly why no team gives back the capacity it controls. Bridging the two requires a different structure: a marketplace that reaches GPUs wherever they already sit, prices their time by job run time to the nearest cent, and pays operators to monetize capacity they would otherwise leave dormant. Dispersed is built this way to resolve the dislocated GPU market, by a team that has been doing the same thing for rendering high-fidelity 3D motion graphics for years.

Background

Dispersed is a distributed GPU compute network that operates as the AI subnet within the broader Render Network ecosystem. It runs independently from the established Render Network while sharing the same onchain token economy, governance framework, and RENDER-based settlement model.

Render Network began in 2017 as a distributed GPU marketplace for 3D rendering and motion graphics workloads. Today, the term Render Network refers both to the original rendering network and to the broader ecosystem of GPU compute networks coordinated through the RENDER token economy. This broader ecosystem currently includes three primary compute networks:

• Render Network: The original rendering subnet for GPU-based 3D graphics and motion graphics workloads.
• Dispersed: The AI subnet for machine learning, AI inference, and general-purpose GPU compute workloads.
• Salad: An independently operated distributed GPU marketplace currently integrating with Render Network’s onchain payments and node reward infrastructure.

Each network operates with its own users, node operators, and service stack. They are connected economically through RENDER and the Burn-Mint Equilibrium model, which routes a portion of network revenue toward token burns and supports token-based incentives for node operators. The Render Network Foundation oversees protocol governance across the broader ecosystem. Salad Technologies Ltd operates the Salad subnet, while OTOY acts as a technology service provider for both the rendering subnet and Dispersed.

This structure is significant because demand for GPU compute continues to accelerate across AI, machine learning, simulation, and graphics workloads, while traditional cloud infrastructure remains constrained by supply bottlenecks, geographic concentration, and high centralized provider costs. Decentralized compute networks offer a complementary model by unlocking underutilized GPU capacity from independent operators around the world. The operational challenge is coordinating supply, demand, and compensation across globally distributed participants without relying on payment rails that introduce settlement delays, stifling transaction costs, credit card fraud, foreign exchange friction, and administrative overhead.

Render’s RENDER token economy and Burn-Mint Equilibrium (BME) model provide a shared incentive and settlement layer for these networks. Dispersed builds on that framework beyond rendering into AI and general-purpose compute, while Salad’s proposed integration would further prove out how Render can serve as a broader economic layer for independently operated GPU networks.

Dispersed connects two groups: Node Operators who contribute GPU-equipped machines, and Service Consumers who rent that hardware by run time to run compute-intensive workloads. The Render Network Foundation, the governance organization behind the broader Render Network ecosystem, announced the platform on Dec. 12, 2025, after governance approval through Render Network Proposal (RNP) RNP-019, later expanded through RNP-021.

Dispersed sits directly in the gap between scarce demand and idle supply. It is designed to aggregate distributed GPUs into a single platform that developers, researchers, and enterprises can rent from without the vendor lock-in, opaque APIs, or premium pricing of incumbent clouds. Operators get rewarded for putting to use hardware that would otherwise sit idle, and users access high-performance GPUs while retaining control of their models and data. The platform supports AI workloads and general compute alike, from model training and inference to image generation, scientific simulation, big-data analysis, and stress testing.

Technology

How Dispersed Works

Dispersed coordinates job execution through a matching and isolation layer. Service Consumers submit jobs with hardware requirements, container images, and execution parameters, while registered nodes receive assignments and run workloads in isolated Docker containers.

Node Operators that have registered a GPU-equipped machine, called a node, by running the Dispersed client on it, can complete jobs. The lifecycle is consistent across every job. A Service Consumer then submits a Job: a work request specifying the hardware it requires (e.g., GPU, RAM, and storage), along with a Docker image and parameters. The network matches that Job to an available Node and hands off execution.

The node runs the job inside an isolated Docker container that packages the application and its dependencies, ensuring consistent behavior across any machine on the network. Each execution creates a job run, and a single job can produce multiple runs if it is retried or distributed across nodes. When a node performs compute work on the network, the operator earns RENDER job rewards based on GPU utilization (i.e., time worked during the epoch) and a specification-based multiplier that reflects the node's hardware. Operators also earn availability rewards for keeping their nodes online and available to accept work.

Node Operators

A Node Operator contributes GPU compute power to the network and earns RENDER for completed work. The role suits anyone with capable hardware and a stable internet connection, from individuals with a single gaming GPU to enterprises running racks of accelerators.

Prerequisites

Operating a Node requires hardware and software that meet the network’s baseline. In addition to the GPU, an operator needs a machine with an NVIDIA GPU, with the RTX 3000 series or newer recommended, and at least 1 TB of disk space, or similar specifications. At the time of writing, supported operating systems are Ubuntu 22.04 or 24.04 for Linux and 64-bit Windows 10 or 11 for Windows. The machine must run Docker (engine version 25.0 or higher) and the Dispersed client, disNet. A fast, stable connection with at least 300 Mbps download and 100 Mbps upload keeps the node eligible for job assignments. OTOY is Render Network’s technical services provider, maintaining the software that matches nodes to service consumers in exchange for a 5% fee. As such, all node operators must create an OTOY account that ties the node to its owner.

Registering a Node

Registering a node takes three steps. First, the operator creates an API key with compute node permissions. Second, the operator installs the prerequisites and registers the machine. Third, the operator reviews how rewards are calculated before going live, including setting up a Solana wallet for receiving RENDER.

API key creation runs through the Dispersed Console. After signing in with an OTOY account, the operator navigates to the API keys section, selects “Create API Key,” configures the key with the necessary permissions, and confirms. The Console returns two credentials: a public key (prefixed ‘pk_’) and a secret key (prefixed ‘sk_’). The secret key generates the HMAC signature that authenticates each request, so the operator must save both credentials at creation time.

With a key in hand, the operator registers the machine using ‘disNet’, the Dispersed client. The client handles registration, receives job assignments, and manages the containers in which jobs run. Four behaviors define an operating node: it registers with the network through ‘disNet’ and an API key, stays online to receive assignments, executes jobs in isolated Docker containers, and earns rewards based on uptime and completed work.

Security and Isolation

‘disNet’ is a zero-trust client, meaning a job can access anything the host machine can access over the network or disk. Containerization with Docker provides process isolation, but it does not buffer the host’s internal network. The documentation strongly recommends running nodes inside an isolated network or a DMZ. This subnetwork separates public-facing services from private infrastructure, preventing jobs from reaching the local LAN. Operators are responsible for their own infrastructure security, and this isolation is a practical safeguard against unauthorized access to local resources.

Monitoring Nodes

Operators can run multiple nodes and track them all through the Dispersed Console. The Console reports each node’s status, and operators with node operator keys can monitor it programmatically via the API.

How Node Operator Rewards Work

Operators earn RENDER, the network's native token, by contributing compute. The protocol distributes rewards in weekly cycles called compute epochs, each running from Sunday 00:00 UTC to the following Sunday 00:00 UTC. Weekly rewards combine three components:

• Availability: Rewards the time the node was kept online and ready to accept jobs.
• Job Execution: Rewards for completing computational work.
• Preparation: Rewards for time spent getting ready for jobs, such as downloading images and setting up.

Two factors scale the payout. The availability reward tops out at 6 RENDER per week at 100% uptime. The job execution reward depends on job run time worked and the hardware’s compound multiplier, a performance factor benchmarked so that an RTX 4090 has a multiplier of 1.0. Stronger hardware earns a higher job run time rate, which rewards operators who supply faster GPUs.

Four levers raise an operator’s earnings: higher uptime boosts availability rewards, higher-performance GPUs increase the multiplier, faster, more reliable connections improve job assignments, and more disk space qualifies the node for more job types. Once earned, RENDER can be spent back on the network to buy compute for the operator’s own projects, or transferred to a wallet to stake, sell, or trade on exchanges such as Binance, Coinbase, and KuCoin.

Service Consumers

A service consumer is anyone who needs serious computing without owning the hardware to produce it. Anyone, from individuals, hobbyists, researchers, scientists, developers, and enterprises, can be a service consumer because the only thing that defines them is having a workload to run. Instead of buying expensive GPUs upfront, a service consumer rents them at a prorated length to the millisecond, runs the work, and releases the hardware, paying only for the time used. That model fits anything that benefits from parallel GPU power, whether the consumer wants raw SSH access to a remote machine or a managed environment for training, inference, simulation, or data analysis.

Most service consumers pay for compute in fiat, which is added to their accounts as credit. As consumers complete work on the network GPUs, the credit is converted to the RENDER token at the current rate; 5% is paid to the service provider, OTOY; and the remaining 95% is burned, providing a direct value accrual mechanism for RENDER.

Getting Started

Like Node Operators, a service consumer needs an OTOY account to access Dispersed. SSH access additionally requires an SSH key pair, and programmatic access requires an API key authenticated with HMAC signatures. The fastest path to a running machine is the Console; the most flexible is the API.

Two Ways to Launch a Job

Once a service consumer funds their account, they can launch work either from a job recipe or directly through the API. Upon account creation, there is a library of job recipes, which are preconfigured templates that bundle validated hardware requirements and container settings, allowing a consumer to launch a common workload by providing minimal inputs, such as an SSH key.

Users can also create their own job recipe template. Recipes suit any workload that runs more than once: they re-launch without resubmitting a full configuration, support fast iteration, and can be forked into customized versions with different hardware, images, or pre-filled inputs. Available recipe types include Base, for Linux environments with SSH access such as Ubuntu or Debian; Inference, for generative-AI environments such as ComfyUI, PyTorch, or OpenClaw; and Training, for fine-tuning and reinforcement learning environments such as Unsloth or Jupyter. Dispersed also supports specialized recipes for emerging GPU-native workloads, including Pearl mining.

The direct API path is best for one-off workloads or cases that require full control. A consumer specifies exact hardware, configures a custom Docker image, and sets container parameters directly. If you are a consumer who finds themselves resubmitting the same payload, you should probably convert it into a recipe.

Job Types: Batch versus Persistent

Every job is either batch or persistent, and the choice determines both lifecycle and billing. A batch job runs until completion or timeout, requires a ‘max_timeout_run_ms’ value, and bills for actual execution time. It fits finite tasks such as rendering, data processing, and inference, and it stops automatically when the container exits or the timeout is reached. A persistent job runs indefinitely until the consumer stops it, must set ‘max_timeout_run_ms’ to null, and bills the job runtime to the millisecond. It fits SSH access, development environments, and long-running services. Because a persistent job keeps billing until canceled, consumers stop their jobs when finished.

Launching a Job and Connecting to an Instance

Through the Console, a consumer goes from recipe to running machine in a few steps. After signing in, the consumer opens “Run” in the sidebar, selects a job recipe (or customizes one), and chooses a GPU that fits the budget and workload. The configuration modal collects the required inputs, which for an SSH instance are the SSH public key and the allowed IP ranges that may connect. Submitting the job opens the job detail page.

The job then moves through three stages. “Pending” means the network is searching for a node that matches the specs. “Assigned” means a node has been selected and is preparing the container. “Running” means the container is live and ready for connections. Once a node is assigned, the network automatically creates a job run, which can take from a few seconds to a few minutes, depending on the availability.

When the job shows “Running”, the consumer opens the job run in the “job runs” section and reads the connection details under Node URLs, specifically the hostname and port. For an SSH recipe, the connection takes the form:

ssh -i ~/.ssh/dispersed -p <port> duser@<hostname>

The job run page updates as status changes. The Ubuntu-with-SSH recipe creates a persistent job, so the consumer stops the job from the Jobs view when the work is done to end billing.

Monitoring Jobs

Consumers track job status, view logs, and manage active runs through the Dispersed Console. The same job detail and job run pages that surface connection information also serve as the operational view for work in progress.

Risks

While Render Network has proven benefits, including lower costs than competitors that use higher-cost traditional payment providers and value accrual to the RENDER token via the BME model, it is not without risks. There are three key risks worth highlighting:

• Supply-side fragility: Job completion requires enough GPU capacity from node operators. If node operators do not supply enough GPUs to meet demand from service consumers, the marketplace can fail as service consumers leave the network for other, more reliable (even if more costly) alternatives. In this scenario, the BME value-accrual mechanism for RENDER breaks down, because few or no jobs are completed and therefore little or no RENDER is actually burned.
• Market risk: Dispersed operates in a market environment shaped by extraordinary, and potentially unsustainable, levels of AI investment and demand. Dispersed’s long-term viability depends heavily on continued developer appetite for GPU compute; should the current AI boom prove to be more of a speculative bubble than anticipated, a sharp contraction in demand could materially undermine network utilization.
• Execution risk: Execution risk boils down to whether Dispersed can be competitive as a GPU marketplace playing against centralized cloud providers and other decentralized GPU networks. While Dispersed's architecture offers distinct advantages for certain workloads, including those better suited to consumer GPUs than data center hardware, users may still prefer competing platforms based on factors such as existing relationships.

Case Studies

As of launch, supply depth for Dispersed is unproven, although there is a long-standing waitlist of GPU operators hoping to join on the rendering subnet. On the demand side, the case studies below represent an early signal. Four early deployments since the December 2025 launch show Dispersed running production workloads across use cases such as generative art, autonomous agents, scientific research, and personal data infrastructure.

MHX: Autonomous Generative Art from Bitcoin Data

Muhammet Altun, the 3D artist known as MHX, built Bitmap, a system that selects one Bitcoin block every 24 hours and grows its transaction data into a unique animated 3D sculpture. A Bitcoin block is capped at roughly 4 MB, about the size of a high-quality JPEG. Still, it acts as a high-density seed: a single block averages about 3,000 transactions, and the algorithm expands that metadata into a sculpture of thousands of individual cuboids. The expansion creates heavy processing overhead from a tiny input.

The project faced a hard constraint. On a high-end local workstation, expanding one block into a 4K sculpture took about 35 hours, exceeding the 24-hour window required by the daily series and causing it to fall further behind each day. Running it locally would have turned a personal computer into an always-on server and a single point of failure, while traditional clouds such as AWS would have added DevOps overhead and cost.

MHX split the work across two layers of the Render ecosystem. Dispersed handled the computation, running his Houdini pipeline (orchestrated by Houdini’s Procedural Dependency Graph) to construct the geometry, while the Render Network API handled parallel frame rendering. He packaged Houdini and OctaneRender into a Docker image and reported 1:1 parity between his local environment and the Dispersed nodes, which made testing and deployment straightforward. A lightweight Cloudflare Worker triggers the pipeline daily, submitting a signed job request to the Dispersed API for a node with 16 CPUs, one GPU, 32 GB RAM, and 16 GB VRAM.

The architecture reduced generation time from 35 hours to 15 minutes and eliminated the need to manage infrastructure. MHX estimates compute cost at a few cents per sculpture on Dispersed, compared to $8 per piece on traditional clouds, representing a reduction of over 95%. Bitmap launched on Jan. 1, 2026, and has run autonomously since, producing one sculpture per day without manual intervention.

Manifest Network and Sarson Funds: GPU Infrastructure for AI agents

At RenderCon 2026, Sarson Funds and Manifest Network demonstrated AI applications that source GPU power programmatically from Dispersed as workloads appear, rather than reserving cloud compute permanently. Sarson Funds approaches the space as an investor in decentralized physical infrastructure networks (DePIN), and Manifest Network supplies the layer that connects applications to decentralized compute.

Two applications illustrated the model. Agent1, an encrypted multi-model AI assistant, splits each user query into three distinct GPU jobs: an embedding step that converts the prompt into vectors, or numerical representations of text that models use to compare meaning and retrieve relevant context; an organization step that routes context and tools; and an inference step that generates the response. Dispersed lets each step run on a different GPU tier, so a lightweight embedding workload can run on a lower-cost GPU such as a 3060 Ti while high-performance inference scales to a 5090. Suma, a crypto portfolio analysis tool, runs an analyst model and a Markov regime classifier side by side, executing the workloads in parallel and selecting cost-efficient hardware for each.

The presentation framed the shift in a single line: “The agent stops being a chatbot. It becomes a buyer of compute.” It highlighted three GPU tiers per query, access to more than 12 NVIDIA GPU classes, hourly pricing starting around $0.26, and elastic scaling without idle overhead. Through OpenClaw-compatible tooling, an agent can dispatch jobs directly to Dispersed in real time, turning compute into a liquid, programmatically accessible resource.

Evidence.guide: Predicting Scientific Replicability at Scale

Paul Litvak and the Robyn Dawes Institute built evidence.guide, an AI pipeline that reads scientific papers and predicts whether their findings will replicate. The problem is large and expensive: the 2015 Reproducibility Project: Psychology, run by the Open Science Collaboration, replicated only about 40% of 100 psychology studies, and replication failure costs an estimated $28 billion annually in US preclinical research alone. Prediction markets reach roughly 73% accuracy but depend on scarce domain experts and cannot scale. Evidence.guide aims to match and surpass the 10,000 paper baseline at a fraction of the cost across hundreds of thousands and eventually millions of papers.

The pipeline moves a paper through several compute-intensive stages. GROBID extracts structured data at about 80% baseline accuracy. Large language models such as Gemini and Mistral improve table extraction by processing tables with image models, reflecting the fact that accurate transcription and semantic interpretation are distinct problems.

A partnership with Refine.ink runs an automated peer-review pass on study design, and a suite of forensic statistical tests (p-value calculation, GRIM, DEBIT, and p-curve and z-curve analysis) checks the reported numbers for inconsistency and p-hacking. An XGBoost model trained on roughly 4,000 replicated studies turns those features into a replicability score and the evidence behind it.

Running multiple AI layers across tens of thousands of papers makes traditional cloud infrastructure prohibitive for a nonprofit with one full-time staffer. Dispersed runs the extraction and scoring steps in parallel across multiple nodes at significantly lower cost than hyperscalers, and the partnership added compute credits and a grant-funded integration engineer, support that AWS or Google Cloud do not offer a lean team. Evidence.guide currently covers about 10,000 psychology papers, with a roadmap through development economics and clinical medicine toward every published randomized controlled trial.

Omniscient: A Sovereign Memory Layer for AI

Omniscient, led by CEO Hannah Barris, builds a persistent context engine that sits between users and the AI models they already use. Its premise is that today’s assistants are stateless: every conversation starts fresh, and the intelligence built from a user’s data is owned by someone else. Omniscient aggregates user-owned sources, such as emails, notes, voice data, and documents, into a continuously evolving memory that grounds AI outputs in real, personal context. Barris framed the thesis at RenderCon 2026 as “Whoever owns context wins,” arguing that model quality is converging and that context is the durable advantage.

Omniscient runs on composable decentralized infrastructure, including Manifest Network and Dispersed, using portable, containerized workloads that move across providers without vendor lock-in. Dispersed lets the platform deploy workloads dynamically across decentralized resources while preserving portability, governance flexibility, and data control, which the company treats as foundational to user sovereignty rather than as an application-layer privacy setting. Barris summarized the goal as “Your data. Your context. Your AI.”

Closing Summary

Dispersed extends a network that already proved decentralized GPUs can coordinate real work at scale, and points that capability at the part of the compute market under the most strain. The wager is that AI demand and idle supply will not reconcile inside the hyperscaler model, and that a marketplace settling in RENDER can clear the difference: operators monetize hardware that would otherwise sit at single-digit utilization, and consumers reach professional accelerators without the price or lock-in of incumbent clouds.

The early deployments already show the value proposition working in practice. Across creative pipelines, autonomous agents, scientific research, and personal data infrastructure, the same pattern holds: professional-grade GPUs turn workflows that were too slow, too costly, or outright impossible into workflows that run on demand. There are no scale minimums or institutional requirements; if you have a workload, you have access. That puts independent artists and lean nonprofits on the same footing as enterprises, across everything from model training and image generation to scientific simulation and agent orchestration. How far Dispersed scales from here, from pilot customers and its first 1,000 enterprise accelerators toward a default option for AI compute, will depend on how deep its supply of high-end GPUs grows and how reliably the network matches demand to that supply.