Skip to main content

Render Network

Render Network — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Render Network — an AI/Compute project (a decentralized GPU compute marketplace), token (symbol: RENDER).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a decentralized marketplace for GPU rendering/compute: requestors buy GPU work from node operators.
  • Who it’s for: 3D/content creators, teams and applications that need GPU compute (including for AI tasks), as well as GPU node operators.
  • Why onchain/token: the token is used to pay for work and to distribute/account for incentives (burn/mint and emissions according to protocol rules).
  • What you can actually touch (Tier‑1): a step-by-step guide to working with the Creator portal (scene preparation → job → review/approve → download).

How it works (very briefly)

  1. The requestor creates a job: specifies the parameters of the render/compute work and the budget.
  2. The network selects executors: GPU providers perform the work offchain, and the result is returned to the requestor.
  3. Payment and accounting — per the protocol: work is paid for via token mechanics (BME: token burn → credits; emissions → rewards to nodes).
  4. Where the blockchain is: onchain records the token mechanics and the settlements/transaction log for BME and governance processes.
  5. Token role: RENDER is needed to pay for compute work and to incentivize/reward GPU providers.

Quick links: AI thesis fit

Project passport

Field Value
Project name Render Network
Also known as (aliases) RNDR (legacy), Render
Logo (logo) ../assets/render_logo.svg
Token symbol (ticker) RENDER
Category AI/Compute | Infra
Primary chain (chain) Solana
Type Appchain
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) 2020-04-27
Project status (status) active
Token (standard) SPL
Token contract —
Token model (token_type) utility (fee-mechanism)
Max supply 536,870,912 (historical RNDR limit; 1:1 migration to RENDER)
Issuance emissions schedule (declining; epoch-based) + burn (BME)
Tokenomics (tokenomics, brief) BME: work is paid for via burning RENDER → Render Credits; emissions are distributed to network participants according to a schedule/epochs.
Governance governance via RNP + votes
Admins/keys —
Audit yes
Bug bounty —
Team (team) Render Network Foundation
Funding (investors/funding) —
AI component (ai_component) GPU compute for rendering + AI tasks
Use‑case (use_case) decentralized GPU compute
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 2 / token_score 3 / evidence_score 3
Last verified 2026-02-03

General project overview

Render Network is a distributed network/marketplace for GPU compute, where requestors buy the execution of rendering (and related GPU tasks) from GPU operators. According to the Tier‑1 knowledge base, the network grew out of OTOY and was spun off into the Render Network Foundation; the protocol and the economic model are described via the whitepaper and the RNP proposal system. In the BME model, payment for work is tied to burning the RENDER token and issuing work credits, while emissions are distributed to network participants.

Features/modules

  • GPU compute marketplace: matching between requestors and GPU providers.
  • BME (Burn Mint Equilibrium): the model for paying for work and distributing emissions.
  • Render Credits: work credits used to submit jobs.
  • RNP governance: protocol changes go through proposals and votes.

Typical scenarios

  • Scenario 1: a creator/requestor buys GPU work → receives the render/compute result.
  • Scenario 2: a GPU node operator joins and performs jobs → receives rewards per emissions/protocol rules.
  • Scenario 3: token holders participate in RNP votes → influence the development of the protocol.
  • Scenario 4 (Tier‑1 “demo surface”): a creator launches a job via the Creator portal (scene preparation → parameters → review/approve → download of the result).

Getting started (wallet/network)

  • What you need: a wallet/account and access to Render Network tools; to pay for jobs — RENDER/credits.
  • Network/chain: Solana (BME and the RENDER SPL token per Tier‑1 docs).
  • Fees: payment for work is implemented via token burn and credit issuance (BME).

Architecture/tech (non‑AI)

  • Components: clients/requestors, GPU providers (node operators), the accounting/payment protocol (BME), the governance process (RNP).
  • Participant roles: requestors, providers, governance participants.
  • Where logic runs: execution of GPU work — offchain; accounting/payment/emissions/votes — onchain/at the protocol level.
  • Dependencies: — (specific integrations and client applications depend on the scenario).

Token/economics (expanded, no forecasts)

  • Token utility: compute work is paid for by burning RENDER in exchange for Render Credits; providers receive emissions.
  • Who pays fees: requestors/job creators.
  • Where fees go: under BME, tokens are burned when paying for work; providers are rewarded via emissions (according to a schedule/epochs).
  • Issuance/burn: described as “Token Burning and Emissions” in the Tier‑1 BME description; the schedule is set/updated via RNP.
  • Security/incentive mechanisms: emissions incentivize GPU providers to meet network demand.

Governance

  • Who makes decisions: the community via the RNP process and votes.
  • How protocol parameters change: RNP proposals → discussion → votes (including with a quorum) → implementation.

Security and incidents

  • Audits: there is a public token audit report (see links_*).
  • Bug bounty: —.
  • Incidents: —.
  • System model: the quality and reliability of offchain work execution, as well as the correctness of accounting, token mechanics and governance processes, depend on the implementation of the corresponding mechanisms.

Project status and timeline

  • Current status: mainnet.
  • Key releases/milestones: the network launch (2020-04-27) and the RENDER launch (2023-11-02) are mentioned in the Tier‑1 knowledge base.
  • Roadmap: publicly set via RNP and the roadmap page (see links_*).

Ecosystem/integrations

  • Integrations: tools/clients for creators and node operators (see docs).
  • Partners: —.
  • Where it’s actually used: in render/compute scenarios, including via generative AI tools (see docs).

AI component of the project

  • What is real AI here? Render positions the network as decentralized GPU compute for graphics and AI tasks; the Tier‑1 docs mention “rendering and AI jobs”.
  • What is truly onchain? the BME token mechanics (burn → credits, emissions) and the governance process (RNP/voting) are implemented onchain.
  • Why is a token needed? RENDER is needed to pay for compute work (via burn) and to incentivize GPU providers (emissions), as well as to participate in governance.
  • Red flags (based on the information found): offchain execution of work: transparent quality criteria and anti-fraud mechanisms are required; confusion between “AI compute” and a “built-in AI module of the protocol”. The Tier‑1 demo (AI_2=1) shows the workflow for launching jobs, but provides no AI quality metrics (AI_3=0).

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity medium 2
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): Tier‑1 describes support for AI tasks as part of the paid work (not just a “plan/intent”).
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
  • Why sufficient / why not (one line): AI is mentioned here as tasks executed by the network, so this is more than roadmap intent.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The network provides GPU compute for AI tasks (and rendering) as a paid service.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/
  • Why sufficient / why not (one line): Tier‑1 describes “rendering and AI jobs” and the positioning of the network as GPU compute.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): The Tier‑1 knowledge base contains a step-by-step guide to working with the Creator portal (from login to launching/checking a job), i.e. a reproducible example of using the compute network.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/getting-started/how-to-get-started
  • Why sufficient / why not (one line): this is a demo/example of the network operating as a compute service; “AI quality” metrics (AI_3) are absent, since the network executes diverse workloads.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://know.rendernetwork.com/
  • Why sufficient / why not (one line): There are no Tier‑1 quality metrics for an AI subsystem; there is a description of the service model.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): There is a description of the token mechanics and the operation of the network, but no technical architecture of an “AI module”.
  • Evidence: Tier‑1 — https://renderfoundation.com/whitepaper
  • Why sufficient / why not (one line): The whitepaper describes a GPU compute/rendering network, not an AI model/model version.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Solana (BME / RENDER SPL)
  • Addresses/identifiers: — (within this card we record the network and documentation; specific addresses depend on the entity)
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token
  • Why sufficient / why not (one line): Tier‑1 explicitly states that BME is implemented on Solana and the token is RENDER SPL.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: the BME payment logic (burn → credits) and a transparent onchain log used for rewards per epoch.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/basics/the-render-spl-token
  • Why sufficient / why not (one line): Onchain is used as part of settlement/accounting and the protocol token mechanics, not just for “token transfers”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the strict necessity of the blockchain (impossibility of replacing it with centralized billing) is not explicitly proven per Tier‑1.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
  • Why sufficient / why not (one line): There are onchain mechanics, but OC_3 requires an explicit “the product breaks without onchain” test in Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, RENDER (SPL).
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token
  • Why sufficient / why not (one line): Tier‑1 docs describe the RENDER SPL token and its role.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): GPU work is paid for by burning RENDER in exchange for Render Credits (BME).
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token ; https://know.rendernetwork.com/basics/burn-mint-equilibrium
  • Why sufficient / why not (one line): Tier‑1 explicitly describes payment for work via burn and credit issuance.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): Providers receive tokens via network emissions as an incentive to serve network demand.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/basics/the-render-spl-token
  • Why sufficient / why not (one line): Tier‑1 describes emissions/incentives and the distribution of rewards.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Governance votes on RNPs rely on participation by RNDR/RENDER holders with a quorum based on total supply.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/about-render-network-governance/render-network-proposal-rnp-system
  • Why sufficient / why not (one line): Tier‑1 describes votes and a quorum based on RNDR+RENDER supply.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The token is deeply embedded in BME payment and emissions incentives, so “replaceability” is not confirmed per Tier‑1.
  • Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
  • Why sufficient / why not (one line): TK_4=1 requires an explicit Tier‑1 statement that “it can be replaced without loss of meaning”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://know.rendernetwork.com/ What Render Network is; the roles of participants; mention of AI compute in the positioning.
Tier‑1 https://know.rendernetwork.com/getting-started/how-to-get-started Step-by-step guide to using the Creator portal (a reproducible example of the network in operation).
Tier‑1 https://renderfoundation.com/whitepaper The purpose of the GPU compute/rendering network and the general model.
Tier‑1 https://know.rendernetwork.com/basics/burn-mint-equilibrium BME: payment for rendering/AI jobs onchain, burn+emissions, epoch allocation.
Tier‑1 https://know.rendernetwork.com/basics/the-render-spl-token RENDER SPL token, BME on Solana, burn → credits, emissions.
Tier‑1 https://know.rendernetwork.com/about-render-network-governance/render-network-proposal-rnp-system Governance: the RNP process and votes (quorum based on RNDR+RENDER supply).
Tier‑1 https://renderfoundation.com/roadmap Roadmap: set via RNP and the public list of RNPs.
Tier‑1 https://renderfoundation.com/upgrade The fact of migration to Solana and RENDER SPL (Nov 2, 2023), the 1:1 RNDR→RENDER upgrade and incentives (RNP‑006).
Tier‑1 https://know.rendernetwork.com/basics/token-metrics-summary Historical minted supply limit of RNDR (536,870,912) and the migration context (for reference).
Tier‑2 https://blog.openzeppelin.com/render-token-audit-2a078ba6d759 Audit report (context: token audit; the tier depends on the status of the source).

No comments to display

Back to top