Render (RENDER) Price

RENDER is the utility token used by Render Network. Render Network connects node operators with available GPUs to requesters that need GPU rendering or computing work; in its current token flow, RENDER is the foundational asset for obtaining task payment credentials and creating node incentives. It does not represent ownership of GPUs, node operators, or network revenue.

Render Network coordinates demand and supply for GPU computing: requesters submit work that needs processing, while node operators provide GPUs to complete it. The network does not focus on directly exchanging tokens for computing power; rather, it organizes both sides through tasks, payment credentials, and rewards for nodes that complete work. Therefore, whether a task can be processed also depends on task requirements, available nodes, and network rules, not only on holding RENDER.

When requesters need to pay for GPU work, they first burn RENDER equal to the required U.S. dollar value, then receive Render Credits of the corresponding value and use those Credits to submit work. The key point is not that RENDER is transferred directly to a node: token burning and the issuance of Credits constitute the requester-side payment step, while nodes receive RENDER from network emissions after completing GPU work. For example, official documentation uses the example of burning $5 worth of RENDER to obtain 5 Render Credits. This example shows that Credits are denominated by U.S. dollar value; the actual Credits required still depend on the specific work and network pricing rules.

RENDER is a transferable Solana SPL token; Render Credits are non-transferable and non-fungible task credentials issued when work is requested. They are not interchangeable: burning RENDER is a prerequisite for obtaining Credits, while Credits are used to submit the corresponding network work rather than serving as tokens that can freely circulate between wallets. This design separates the U.S. dollar-value credential for task payments from the transferable base token in the market. Therefore, holding RENDER alone does not mean that a user already has Credits that can be used to submit tasks, and obtained Credits do not equal a balance that can be converted back into RENDER.

BME is the “Burn Mint Equilibrium” mechanism: requesters burn RENDER for computing work, while nodes that complete GPU work receive RENDER from network emissions. It places demand-side burns and supply-side emissions within the same economic framework, rather than promising that every burned token will be replenished token-for-token by newly minted tokens. Therefore, BME should be understood by separately considering two variable elements: task demand affects the amount of RENDER burned, while node rewards depend on network emission arrangements determined through governance. The difference between them and changes in that difference cannot be inferred solely from the name “BME.”

Node operators’ RENDER rewards come from network emissions, rather than from requesters directly transferring their payment tokens to nodes. Nodes first provide and complete the GPU work required by the network, and the network then distributes RENDER according to the applicable emission and reward rules; official materials point to RNP-006 for this emission framework and state that it was subsequently updated by RNP-013. Accordingly, “providing GPUs” does not automatically mean receiving a fixed return: eligibility for rewards and their amount depend on task completion and the network rules in effect at the time. Emissions are incentives intended to sustain the supply of GPU capacity, but do not constitute a guarantee of node revenue.

RENDER is burned when a requester exchanges the base token for the Render Credits required for a task: the corresponding RENDER is burned, rather than retained in the requester’s account or held as a transferable reserve backing Credits. The Credits are then used to submit work, so the burn reflects computing demand that has entered this payment flow. A burn alone does not establish which node will necessarily take on a task, nor does it by itself determine how much reward a node receives; node-side rewards are handled by network emission rules. Separating “task payments are burned” from “node rewards are emitted” is necessary to understand this flow correctly.

RNDR was the earlier ERC-20 token, while RENDER is the current SPL token operating on Solana and serving the BME flow. After the community approved BME, the network implemented the mechanism on Solana and upgraded the old ERC-20 RNDR to RENDER SPL; they are therefore asset forms from different stages of the same project, rather than two current network payment assets that can coexist arbitrarily with identical functions. When identifying an asset or handling old balances, use the official upgrade portal and the officially published SPL address. Do not treat any contract with the same name as RENDER based solely on its name or token symbol.

To understand RENDER supply, at minimum distinguish between node network emissions and burns caused by task payments: the former are incentives allocated to nodes that complete GPU work, while the latter arise when requesters obtain Render Credits. Historical supply data for old RNDR should not be directly treated as the basis for current RENDER SPL and BME. Specific emission amounts, timing, and adjustments are not automatically determined by the term “BME”; applicable governance proposals and on-chain data should be used instead. Accordingly, total supply, circulating supply, or net changes during a period require verifiable data for the same point in time and the same asset form; historical ERC-20 metrics must not be added to or interchanged with current SPL data.

The basic path for a requester is to confirm task and network requirements, obtain Render Credits by acquiring and burning RENDER through the process, and then submit work using Credits. Credits are task payment credentials, so simply holding RENDER cannot replace the payment steps required to submit a task before Credits have been obtained. GPU suppliers, by contrast, need to use nodes that meet network requirements to take on and complete work, with rewards settled according to network emission rules. The roles, required software, and qualifications differ between the two participant types; specific onboarding requirements should follow the relevant official operational documentation.

To confirm official RENDER, verify both the network and the address: this asset is the RENDER SPL token on Solana, and the official links page provides official channels and address information for identifying it. A token name, icon, or search result is not sufficient proof that an address is the official asset. Before a migration, wallet signature, or transfer, also enter upgrade resources through official pages and avoid “exchange” portals supplied through private messages, advertisements, or unofficial websites. Transfers to the wrong network or wrong address generally cannot be automatically recovered merely because the project name is the same.

When researching RENDER, first consult the Render Network Knowledge Base for network and operational rules, and the official SPL token description for the relationship among BME, Credits, burns, and node emissions. For old RNDR upgrades or asset identification, cross-check official upgrade resources and the official links page. These materials explain protocol mechanics, but do not replace the specific transaction status of a wallet, node, or third-party service. For time-varying data such as supply, burns, and emissions, additionally verify the statistical methodology and timing in the applicable governance documents and on-chain records.