Core definition
Render, represented by the RENDER token, is a decentralized GPU-compute network and tokenized marketplace. It connects creators, developers, and organizations that need graphics or artificial-intelligence computation with node operators that supply idle or underused GPU capacity.
The project began as RNDR on Ethereum, focused primarily on distributed 3D rendering. It later migrated toward RENDER on Solana, expanding into generative AI, machine learning, inference, and broader GPU-compute workloads.
Its central proposition is to make GPU capacity more accessible, scalable, and potentially less expensive than relying exclusively on centralized render farms or cloud providers. The network is best understood as a combination of:
- A decentralized GPU marketplace.
- A rendering and compute coordination layer.
- A token-based payment and incentive system.
- A developing DePIN, or decentralized physical infrastructure, network.
The underlying blockchain does not perform the actual rendering or AI computation. GPU work takes place off-chain across participating machines, while the blockchain records token transfers, payments, burns, emissions, and related network activity.
Core technology and blockchain architecture
Decentralized GPU marketplace
Render has two primary participant groups:
| Participant | Role | |
|---|---|---|
| Creators and compute requesters | Submit rendering or GPU-compute jobs and pay for completed work | |
| Node operators | Contribute GPU hardware, process assigned jobs, and receive rewards |
A large workload can be divided across multiple geographically distributed GPUs. This allows a creator to access elastic capacity without purchasing or maintaining a private render farm.
The network’s software stack is closely associated with OTOY’s OctaneRender, a GPU-accelerated rendering engine. Render also supports or is expanding support for other production environments, including:
- OctaneRender.
- Redshift.
- Blender Cycles.
- Cinema 4D workflows.
- Generative-AI and machine-learning applications through compute clients and APIs.
This application-specific orientation differentiates Render from general-purpose decentralized cloud platforms. Users can submit jobs through creative tools and integrations rather than manually configuring raw blockchain infrastructure or cloud containers.
Ethereum, Polygon, and Solana
The project has existed across several blockchain environments:
| Network | Role and status | Contract or token address | |
|---|---|---|---|
| Ethereum | Original RNDR ERC-20 deployment | 0x6de037ef9ad2725eb40118bb1702ebb27e4aeb24 | |
| Polygon | Additional ERC-20 deployment | 0x61299774020da444af134c82fa83e3810b309991 | |
| Solana | Primary environment for the newer RENDER SPL token | rndrizKT3MK1iimdxRdWabcF7Zg7AR5T4nud4EkHBof |
A community vote in March 2023 supported the move to Solana. The Solana-based RENDER token launched on November 2, 2023.
The migration was intended to provide:
- Lower transaction costs.
- Faster settlement.
- Better support for frequent, smaller payments.
- More efficient automated emissions and burn operations.
- A more suitable environment for high-volume GPU-job coordination.
Legacy RNDR remains associated with Ethereum for holders who have not migrated. Render documentation states that migration remains open indefinitely, with a historical migration limit of 536,870,912 tokens. Supply figures should therefore be interpreted carefully, because some sources count Solana RENDER, some account for unmigrated Ethereum RNDR, and others use different aggregation methods.
Primary use cases
3D rendering and visual effects
Render’s original and most established use case is distributed GPU rendering for:
- Animation.
- Film and television visual effects.
- Motion graphics.
- Architectural visualization.
- Product design.
- Game development.
- Virtual and augmented reality.
- Metaverse environments.
- Digital-art production.
- High-resolution and immersive media.
Instead of waiting for a local workstation or renting a centralized render farm, a creator can distribute portions of a scene or project across available network GPUs. Completed frames or computational outputs are then returned to the requester.
OctaneRender workflows
OctaneRender is a key part of Render’s technical identity. Because the network developed alongside OTOY’s rendering ecosystem, it is designed around actual production workflows rather than simply providing generic GPU instances.
This can reduce configuration complexity for artists and studios. The creator can work through familiar tools while Render handles the distribution of jobs to node operators.
Blender and other creative software
In April 2024, OTOY and Render announced an initiative to bring Blender’s Cycles rendering engine to the network. This is strategically important because Blender is widely used by independent artists, production studios, educators, and developers.
Broader engine compatibility may expand the addressable user base and reduce reliance on a single proprietary rendering environment. Render also identifies Blender and Cinema 4D among its supported or integrated creative workflows.
Artificial intelligence and machine learning
Render is expanding from visual rendering into GPU-intensive AI workloads, including:
- Model inference.
- Model training.
- Fine-tuning.
- Generative-AI image production.
- AI-assisted content creation.
- Spatial-computing applications.
- Machine-learning experimentation.
- General-purpose GPU computation.
The network’s compute-client framework provides APIs that allow external developers and businesses to access GPU capacity programmatically. Public materials reference support or integrations involving tools and platforms such as Runway, Black Forest Labs, Luma Labs, and Stability AI. These relationships connect Render’s established graphics market with rapidly growing generative-media demand.
General-purpose decentralized compute
RNP-019, created on March 31, 2025 and subsequently marked as implemented, established the framework for the Render Compute Network. This is a general and AI-compute subnet designed to operate alongside the original rendering network.
The proposal described:
- An initial deployment of approximately 100 nodes.
- Availability rewards.
- Proof-of-compute mechanisms.
- Utilization scoring.
- General and AI workloads.
- Customer payments in fiat currency or RENDER.
- A buy-and-burn settlement model.
Under the proposal, 95% of job credits would be used to procure RENDER on open markets and burn it, while 5% would compensate OTOY for network operations.
Founding team and project history
Jules Urbach and OTOY
Render was conceived by Jules Urbach, founder and chief executive officer of OTOY. Urbach began developing the concept in 2009, with the goal of making high-end rendering power available through a distributed network instead of requiring every creator or studio to purchase expensive hardware.
OTOY remains closely associated with Render’s technology, particularly OctaneRender. The Render Network Foundation was later established as a separate Cayman Islands-based nonprofit organization responsible for governance and strategic initiatives, while OTOY continues to provide important technology and operational connections.
Major historical milestones
| Date | Development | |
|---|---|---|
| 2009 | Render concept developed within OTOY | |
| October 2017 | First public token sale | |
| January to May 2018 | Private-sale period and early RNDR beta-testnet onboarding | |
| April 27, 2020 | Public network launch | |
| March 2023 | Community vote supporting the Ethereum-to-Solana transition | |
| November 2, 2023 | Solana-based RENDER token launched | |
| April 2024 | Blender Cycles integration initiative announced | |
| March 31, 2025 | RNP-019 created for the Render Compute Network | |
| 2025 | General and AI-compute subnet development expanded | |
| March 2026 | RNP-023 proposed Salad Network integration as an additional Render subnet |
The overall strategic evolution is from a specialized distributed-rendering marketplace toward a broader decentralized GPU-compute platform.
Tokenomics
Current market snapshot
The supplied market data reports the following figures:
| Metric | Value | |
|---|---|---|
| Price | $1.4453 | |
| Market capitalization | $749.76 million | |
| Fully diluted valuation | $771.09 million | |
| 24-hour trading volume | $29.03 million | |
| Market-cap ranking | #117 | |
| Circulating supply | 518,772,101 RENDER | |
| Total supply | 533,532,275 RENDER | |
| Decimals | 18 | |
| 1-hour change | +0.44% | |
| 24-hour change | +3.8% | |
| 7-day change | -5.34% | |
| Reported risk score | 54.30 |
The circulating supply is close to the reported total supply. The difference is approximately 14.76 million tokens, or about 2.8% of total supply. The relatively small gap between market capitalization and fully diluted valuation also indicates limited remaining dilution compared with many newer tokens, although the supply can still change through the network’s emissions system.
The supplied data does not include verified all-time-high or all-time-low figures, so those values cannot be stated reliably here.
Historical supply
The original token supply was established at 536,870,912 RNDR, equal to 2²⁹ tokens. Historical documentation records:
- A public sale in October 2017.
- An approximate public-sale price of $0.25 per RNDR.
- A 20% genesis bonus associated with the historical sale process.
- No public-sale vesting under the legacy token-metrics summary.
These historical figures do not fully describe the current token model because the project later introduced the Solana migration, emissions, burns, and multiple subnet-specific reward structures.
Burn-Mint Equilibrium
Render uses a Burn-Mint Equilibrium, or BME, model. Its basic flow is:
- A creator submits a job with a dollar-denominated cost.
- The required amount of RENDER is calculated at the time of payment.
- The tokens are burned.
- The creator receives non-transferable, non-fungible Render Credits, sometimes described as coupon tokens.
- The credits are consumed as the job is completed.
- Node operators receive RENDER through emissions or applicable reward reserves.
This structure is designed to separate the creator’s service cost from short-term token-price volatility. A rendering customer is effectively purchasing a dollar-priced amount of compute, while token demand is generated when the network acquires and burns RENDER to settle that service.
BME is not automatically deflationary. The net effect depends on the relationship between:
- Tokens burned through actual network usage.
- New tokens emitted to node operators.
- Foundation and ecosystem allocations.
- Governance changes to the rewards schedule.
- Demand across rendering, AI, and other compute subnets.
If burns exceed emissions, supply can decline. If emissions exceed burns, supply can increase.
Emissions
RNP-006 specified first-year emissions totaling 9,126,804 RENDER, equivalent to approximately 760,567 RENDER per month. Under the initial allocation described in that proposal:
- 50%, approximately 380,284 tokens per month, went to the network.
- 50% went to the Render Foundation.
The schedule was designed to decline over time. Solana Compass reported a second-year allocation of 5,905,580 RENDER, lower than the first-year amount. Later proposals, including RNP-013, RNP-015, and RNP-018, refined elements of the emissions and reward structure.
A major implication is that token economics depend on real utilization. A growing node network without corresponding demand could increase emissions pressure, while rising rendering and AI usage could increase burns and support a more balanced supply profile.
Reported burn activity
A Messari analysis reported that monthly RENDER burns increased from approximately:
- 20,452 RENDER in January 2025
- To approximately 120,929 RENDER in September 2025
The analysis reported average month-over-month growth of approximately 28.8% during the period studied.
This indicates increasing token activity associated with network usage, but burn growth alone is not enough to determine whether the system is net deflationary. Emissions, reserve releases, and future subnet rewards must also be considered.
Consensus and network security
Proof of Render
Render uses Proof of Render, or PoR, as a work-verification and job-coordination mechanism. PoR is not a separate blockchain consensus mechanism like proof-of-work or proof-of-stake.
Under PoR:
- Node operators commit GPU resources.
- The network assigns rendering or compute work.
- Nodes produce the requested output.
- Results are checked or validated.
- Rewards are determined using job completion, output quality, reputation, utilization, and related measurements.
The purpose is to verify that useful computation was actually performed. This is particularly important because a decentralized compute network must distinguish between available hardware, completed work, poor-quality output, and unreliable operators.
Solana settlement security
The Solana-based RENDER token relies on Solana’s validator network and proof-of-stake-based consensus architecture, including Proof of History for event ordering and coordination.
Render’s security model therefore has several layers:
| Security layer | Function | |
|---|---|---|
| Solana blockchain | Secures token transfers, program state, and settlement transactions | |
| Application-level verification | Checks whether rendering or compute jobs were completed correctly | |
| Economic incentives | Rewards useful work and discourages unreliable or dishonest participation | |
| Reputation systems | Help identify dependable node operators | |
| Utilization scoring | Measures hardware availability and productive use, particularly in compute subnets |
Solana does not render video frames or execute AI models. It provides the settlement and accounting layer, while computation occurs across off-chain GPU machines.
Ecosystem integrations and partnerships
OTOY and OctaneRender
OTOY is the foundational technology relationship behind Render. OctaneRender supplies the original GPU-rendering technology, while Render supplies distributed access to GPU capacity.
This connection gives the network a specialized workflow and an established graphics-industry identity.
Solana
The Solana transition improved the economics of frequent network interactions by offering lower transaction costs and faster settlement. These characteristics are particularly relevant to microtransactions, automated emissions, and burn operations.
Blender
The Blender Cycles initiative announced in 2024 is intended to bring a major open-source rendering ecosystem onto the network. It could help Render reach a wider group of independent artists, studios, educators, and developers.
AI and creative applications
Render’s public materials identify or reference integrations and workflows involving:
- OctaneRender.
- Redshift.
- Blender Cycles.
- Runway.
- Black Forest Labs.
- Luma Labs.
- Stability AI.
- Spatial-computing and immersive-media workflows.
- API-based machine-learning and generative-imaging applications.
Claims involving Apple, Nvidia, Google, Filecoin, or other major technology companies should be interpreted carefully. The available official materials establish Render’s relationships with OTOY, Solana, Blender, and the listed creative and AI tools more clearly than they establish formal direct commercial partnerships with every company sometimes mentioned in third-party coverage.
Salad Network
RNP-023, marked “Approved + Roadmap,” proposed integrating Salad Network as an exclusive Render subnet.
The proposal described:
- Salad becoming a third Render subnet alongside the original rendering subnet and Dispersed.
- Salad payments and node rewards moving toward on-chain RENDER transactions.
- Salad’s network operating across more than 180 countries, according to Render’s published ecosystem material.
- A revenue split for certain Salad Container Engine revenue in which 60% would enter the BME burn process, 35% would go to Salad, and 5% would go to the Render Foundation.
- A separate Gateway Service split in which 35% would enter BME, 60% would go to Salad, and 5% would go to the Foundation.
Public reporting around RenderCon 2026 described the potential addition of approximately 60,000 GPUs through the Salad integration. That figure represents potential Salad capacity and should not be confused with Render’s existing active rendering-node count.
Current development and roadmap
Render Compute Network
The most important recent development is the expansion into general and AI compute through RNP-019. The initial plan called for approximately 100 nodes, with mechanisms for:
- Proof-of-compute.
- Availability rewards.
- Utilization scoring.
- General GPU workloads.
- AI inference and training.
- Fiat or RENDER payments.
- Buy-and-burn settlement.
RNP-019 estimated emissions of approximately 8,500 RENDER per month for initial nodes operating near full capacity, using an RTX 4090-type baseline as an example.
Enterprise-grade GPU support
RNP-021 proposed expanding the compute subnet beyond consumer GPUs such as the RTX 4090 and RTX 5090 to include enterprise hardware such as:
- NVIDIA H100.
- NVIDIA H200.
- NVIDIA A100.
- AMD MI300-series processors.
Enterprise-grade support matters because advanced AI workloads often require high memory capacity, predictable availability, and specialized hardware. Consumer GPU aggregation can be useful for inference and smaller jobs, but large-scale model training generally places greater demands on memory, networking, reliability, and orchestration.
Dispersed compute subnet
By late 2025, Render had introduced or was developing a separate subnet known as Dispersed, aimed at AI inference, AI training, and general compute rather than traditional frame rendering.
Messari reported that Dispersed supported more than 600 open-weight models for use cases such as:
- Inference.
- Generative-AI pipelines.
- Document processing.
- General AI applications.
Separate subnets allow Render to use different hardware requirements, scheduling systems, rewards, and validation rules for creative rendering and AI workloads.
API access and compute clients
Render’s compute-client program is intended to let businesses and developers provision GPU capacity through APIs. Target applications include:
- Machine-learning training.
- Inference.
- Fine-tuning.
- Generative-AI imaging.
- Spatial computing.
- Advanced 3D production.
- AI-agent-driven creative workflows.
The roadmap therefore goes beyond selling raw GPU time. Render is attempting to embed decentralized computation into applications used by creators and AI developers.
Agentic AI and creative workflows
2026 ecosystem materials emphasized integrations involving AI agents and creative software. Model Context Protocol integrations were reportedly being introduced for Blender, OTOY Octane, and Disperse.
If developed successfully, this could allow AI agents to interact directly with creative applications and decentralized compute services. That would position Render as an application-integrated infrastructure layer rather than only a marketplace for hardware capacity.
Reported network activity
The Render Foundation dashboard reported approximately:
- 79.2 million total frames rendered
- 5,600 total nodes since inception
These figures indicate meaningful operating history, but “total nodes since inception” is not equivalent to the number of simultaneously active nodes. The metrics are cumulative and can change over time.
Competitive landscape
Render competes with several decentralized compute networks, although each emphasizes a different market.
| Network | Primary focus | Typical workloads | Main distinction | |
|---|---|---|---|---|
| Render | GPU rendering, AI, and expanding general compute | 3D rendering, visual effects, generative imaging, inference, selected AI workloads | Purpose-built creative workflows, OctaneRender and Blender support, token-linked settlement | |
| Akash | General-purpose decentralized cloud | Containers, web hosting, CPU workloads, GPUs, AI applications | Broad infrastructure marketplace and flexible deployment | |
| Golem | General distributed computation | Arbitrary computational tasks and application-specific workloads | Open, flexible distributed-compute model | |
| io.net | Decentralized GPU aggregation for AI | AI training, inference, multi-GPU clusters | Emphasis on assembling geographically distributed GPU clusters | |
| Gensyn | Decentralized machine-learning infrastructure | Distributed AI training and model computation | Focus on machine-learning coordination and verification | |
| Salad | Consumer-compute and distributed infrastructure | Containerized workloads, AI applications, distributed services | Large consumer-device network and potential Render subnet integration |
Render’s strongest advantages
Purpose-built creative infrastructure
Render is more specialized than general cloud marketplaces. Its integration with established tools can reduce the configuration burden for artists and studios.
Existing rendering history
The reported 79.2 million cumulative frames and 5,600 total nodes since inception indicate more operational history than a purely theoretical GPU marketplace. However, these figures do not establish current utilization or profitability.
Token-linked usage
The BME model gives RENDER a direct connection to service consumption. Users burn tokens for rendering or compute credits, while providers receive emissions and rewards.
Expansion into AI
AI, generative media, and inference provide a much larger potential market than traditional 3D rendering alone. Dedicated subnets, enterprise-GPU proposals, and API access are intended to capture that demand.
Workflow integration
Render’s strategy is not limited to aggregating GPUs. Integrations with creative tools and AI applications may create user lock-in and make decentralized capacity easier to access.
Competitive limitations
Render’s specialization can also limit it:
- Akash may be more suitable for general cloud infrastructure, containers, databases, and web services.
- io.net may be better suited to customers needing coordinated multi-GPU AI clusters.
- Golem offers broader task flexibility for arbitrary computation.
- Gensyn is more narrowly focused on distributed machine-learning training.
The key operational challenges include:
- Heterogeneous and potentially unreliable consumer hardware.
- Data-transfer costs and bandwidth limitations.
- Privacy and confidentiality requirements for sensitive AI workloads.
- Compatibility with specific CUDA versions, drivers, libraries, and orchestration systems.
- Shortages of high-memory, enterprise-grade GPUs.
- Difficulty distributing tightly synchronized AI-training workloads.
- Competition from centralized cloud providers with established reliability and networking.
Rendering jobs are generally easier to divide across independent nodes than tightly synchronized AI training. Consequently, Render’s AI expansion broadens its opportunity but also introduces more demanding technical and competitive requirements.
Overall assessment
Render is a decentralized GPU marketplace that started with professional 3D rendering and is evolving into a broader AI and general-compute network.
Its main differentiators are:
- The OTOY and OctaneRender technology base.
- A creator-focused rendering workflow.
- Support for Blender Cycles and other creative tools.
- A distributed supply of GPU capacity.
- Solana-based token settlement.
- The BME system connecting usage with token burns.
- New rendering, AI, enterprise-GPU, and consumer-compute subnets.
- Governance through Render Network Proposals.
The central economic question is whether real demand for rendering and AI computation can grow faster than emissions and operating costs. Rising burns would indicate increasing token use, but burns must be evaluated alongside emissions, node rewards, subnet activity, and the quality of actual GPU utilization.
Render’s strongest established niche remains specialized, GPU-intensive media computation. Its longer-term opportunity is to use that foundation to become a broader decentralized GPU layer for generative media, inference, machine learning, and selected general-compute workloads. The success of that strategy will depend on reliable job verification, competitive pricing, access to high-quality GPUs, application integrations, and sustained customer demand.