Question
Provide a concise narrative that clearly states each of (a)–(e) below.
Response
Render publicly describes the network as decentralized GPU infrastructure that connects creators, artists, and machine-learning developers with idle GPU capacity supplied by node operators for rendering, AI, and other compute workloads.
(Source: Render Foundation Press Resources, Render Foundation FAQ, Render Network Whitepaper)
Public materials state that the Foundation facilitates the Render Network Proposal system, oversees burn-and-mint-equilibrium operations, handles node-operator onboarding as needed, and manages foundation grants and ecosystem growth initiatives. Public materials also describe the network as expanding from rendering into AI and general compute use cases.
At a high level, the cited public sources describe Render as an off-chain rendering and compute network paired with blockchain payment and escrow layers. Under the current burn-and-mint-equilibrium design, creators or compute clients pay for work by converting value into RENDER, Render Credits track work on the network, and node operators receive rewards for providing compute capacity and completing work.
(Source: Render Network Whitepaper, RNP-001, RNP-006)
The public record supports three primary token functions for RENDER. First, RENDER is the payment-denomination and settlement surface for work on the network. Second, users burn RENDER in exchange for network work, while node operators and other approved recipients receive RENDER emissions and rewards under the BME model. Third, RENDER is used for governance participation in the RNP process. Legacy RNDR was previously used before the Solana upgrade, but voting and governance now occur with RENDER on Solana, and RNDR voting on Ethereum has been deprecated.
(Source: Render Network Upgrade Portal FAQ, How to vote in RNPs, RNP-001, RNP-006, Render Network Proposal (RNP) System)
Public sources describe the Render Network Foundation as the governance organization for the network and describe RNPs as the primary mechanism for significant protocol changes. The same public record shows that governance currently depends on a Foundation-facilitated proposal process with an initial 72-hour vote, a 6-day final vote, and quorum thresholds, while a separate freeze authority remains in place as a safeguard against upgrade-portal smart-contract risk.
(Source: Render Foundation Press Resources, The Render Network Foundation, Render Network Proposal (RNP) System, Render Foundation FAQ)
Question
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Response
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
Jules Urbach | Labs | Founder of Render Network; Founder and CEO of OTOY | Public Foundation materials state that Jules Urbach founded the Render Network, and that OTOY, led by Urbach as CEO, founded the network in 2017. Foundation press materials further state that Render Network was first conceived in 2009 by OTOY, Inc. founder and CEO Jules Urbach, held its first public token sale in October 2017, entered a private sale period from January to May 2018, and launched publicly on April 27, 2020. |
Trevor Harries-Jones | Labs | Chief Operating Officer, OTOY | |
Tristan Relly | Foundation | Head of Operations | Public reporting identifies Tristan Relly as Head of Operations at the Render Foundation. Public sources do not provide further prior-experience details. |
Ryan Shea | Foundation | Head of Product | Public Foundation team materials identify Ryan Shea as a Foundation team member. The team-provided correction identifies his current title as Head of Product. No further public prior-experience details were identified. |
Trevor Harries-Jones | Foundation | Render Network Foundation Board Member | |
Silvia Lacayo | Foundation | Head of Marketing and Communications | Public reporting states that Silvia Lacayo joined the Render Foundation as Head of Marketing and Communications in April 2025. The same report states that she brings more than 15 years of experience across blockchain, SaaS, and consumer goods, including prior marketing leadership roles at Chainalysis and Bitstamp. |
Luke Duncan | Foundation | Community and Governance Manager | Public reporting states that Luke Duncan was promoted to Community and Governance Manager in April 2025. The same report states that he had been part of the Render Network community for four years and had contributed significantly to the network’s moderation team before his promotion. |
Sunny Osahn | Foundation | Ecosystem & Adoption Lead | Team-provided information identifies Sunny Osahn as Ecosystem & Adoption Lead. No further public prior-experience details were identified. |
Not applicable as Render does not have a DAO. | DAO | N/A | N/A |
Blockworks note: No separate Labs/DevCo legal entity is identified by name. The closest public development-company surface is OTOY, which public Foundation materials say founded Render Network and remains a network partner operating rendernetwork.com. |
Question
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
Response
Not applicable as Render does not have a DAO.
Not applicable as Render does not have a DAO. The public governance process is instead the Render Network Proposal system. Public governance materials describe RNPs as the primary mechanism for significant protocol changes, ecosystem initiatives, and governance decisions. RNP-000 states that RNPs should be reserved for significant initiatives affecting the Render Network’s core functionality, governance, or strategic direction, including changes to rendering infrastructure, the economic model or token mechanics, new network features or services, and the governance process itself. The RNP process includes an initial draft phase, community discussion, coordination with the Render Foundation to determine whether a proposal falls within the mandate of protocol improvements, an initial proposal vote, a final vote, and implementation of approved proposals. RNP-000 states that an RNP may be submitted to the Render Network Foundation team for dissemination or submitted as a pull request to the RNP repository, and that a dedicated Discord channel is created to facilitate community discussion and feedback. Current RNP voting is conducted using RENDER SPL tokens on Solana through Nation.io. Render’s voting FAQ states that RNP voting “leverages Nation for RENDER SPL Token voting” and previously used Snapshot for RNDR ERC-20 voting. It also states that, with the Solana upgrade, the Foundation introduced a Solana voting system for RNP governance, enabling community members who upgraded to RENDER SPL tokens to participate. The RNP voting thresholds are described in both the Knowledge Base and RNP-000. The initial proposal vote lasts 72 hours, is decided by simple majority, and has no quorum requirement. If it receives majority support, the proposal proceeds to a final RNP vote. The final vote lasts 6 days and requires at least 50% approval of total votes cast and a quorum of at least 15% of the total combined RNDR and RENDER token supply. Emergency proposals may omit the initial vote phase and elevate the quorum requirement to 20% of the total Render token supply. Approved RNPs are incorporated into the Render Network development roadmap and implemented by core Render Network contributors, with status and progress tracked by the Render Foundation team and in the designated GitHub repository.
(Source: Render Network Proposal (RNP) System, RNP-000, How to vote in RNPs)
Not applicable as Render does not have a DAO. The public governance record instead describes voting through RENDER token snapshots. Render’s voting FAQ states that tokenholders wishing to participate in governance voting need to hold RENDER in an onchain self-custodial wallet in order to connect to Nation and vote. The same FAQ states that Nation calculates eligibility after a blockchain snapshot is taken before the voting round, and that voting impact is directly correlated to the amount of RENDER in the tokenholder’s onchain self-custodial account at the time of the snapshot.
(Source: How to Vote in RNPs)
The voting FAQ also describes a hardware-wallet delegation feature. It states that vote delegation allows users to assign voting power for specific tokens to another wallet address, allowing the delegate wallet to vote on their behalf while the original tokenholder retains ownership of the tokens and can remove or change delegates through profile settings.
(Source: How to Vote in RNPs)
Not applicable as Render does not have a DAO. Publicly described tokenholder rights sets are limited to governance participation through the RNP process. Current governance occurs with RENDER on Solana. The upgrade FAQ states that voting and governance occur with RENDER on Solana, and that voting with RNDR on Ethereum has been deprecated. It also states that the community voted to build the network on Solana through RNP-002, that RENDER was created when the new Solana token was minted, and that the Foundation’s support going forward is focused on RENDER.
(Source: Render Network Upgrade Portal FAQ)
The upgrade FAQ further states that the old RNDR token still exists, but RNDR on Ethereum is no longer maintained by the Foundation and cannot be used on the Render Network; it also states that RNDR on Polygon has been deprecated and will no longer be supported by the Foundation for network use.
(Source: Render Network Upgrade Portal FAQ)
Not applicable as Render does not have a DAO.
Blockworks note: Not applicable as Render does not have a DAO. Governance and community participation are instead handled through the Render Network Proposal system, which is facilitated by the Render Network Foundation and voted on by RENDER tokenholders. For governance and community participation, the relevant public process is the RNP voting process, including the Foundation’s published guidance on how to vote in RNPs.
(Source: Render Network Proposal (RNP) System, Understanding Render Network Governance)
Question
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist.
Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
Response
Public sources describe the Render Network Foundation, formed in 2023 after OTOY contributed stewardship, as the governance organization for Render and describe it as a Cayman Islands foundation company.
(Source: The Render Network Foundation, Privacy Notice)
Public Foundation materials indicate the Foundation owns or controls the core Render Network protocol code and brand. The Foundation's launch announcement states that, as part of the creation of the Foundation, the founding group transferred control of the core Render Network repositories and the Render Network brand to the Foundation as a step toward decentralization. RNP-003 describes the Foundation as the sole proprietor of the protocol repositories and major assets crucial to the operation of the network. The Knowledge Base states that the Foundation, spun out of OTOY in 2023, oversees governance of the protocol and strategic initiatives. A registered RENDER NETWORK word mark also exists in the public trademark record, though the current registrant of record was not confirmed in public sources.
(Source: Announcing the Render Network Foundation, RNP-003, Render Network Knowledge Base, RENDER NETWORK Trademark)
Public sources state that the Render Network Foundation provides the governance framework for Render, facilitates the strategic vision for the network, oversees the RNP system, implements and operates the burn-and-mint-equilibrium model, conducts node-operator onboarding as needed, and manages grants. Public Foundation materials further state that the Foundation’s role and mandate include growing network adoption and usage through strategic, marketing, communications, partnership, development, and community engagement initiatives. The FAQ states that the Foundation’s core ecosystem responsibilities include facilitation of the RNP system; implementation and operational oversight of BME, including token burns, emissions, and node-operator rewards; node-operator onboarding as needed to maintain compute capacity; management of Foundation grants; and growth of ecosystem partners building applications and infrastructure that make the Render Network accessible to end users. Public RNP materials state that RNPs are the primary mechanism through which the Render Network community can propose, debate, and implement protocol changes. RNPs are intended for significant initiatives affecting the network’s core functionality, governance, or strategic direction, including changes to rendering infrastructure, token mechanics, new services, and governance processes. Current RNP voting occurs through Nation for RENDER SPL token voting, while Snapshot was previously used for RNDR ERC-20 voting. Tokenholders need RENDER in an onchain self-custodial wallet to participate in Nation voting.
(Source: The Render Network Foundation, Render Foundation FAQ, Render Network Proposal (RNP) System, RNP-000, How to Vote in RNPs)
No public data indicates that the Foundation holds formal authority over OTOY's internal decision-making. The documented relationship runs primarily in the other direction. Public Foundation materials state that OTOY founded the Render Network in 2017, announced the formation of the Foundation in 2023, and contributed stewardship of the network to the Foundation, including transferring the core protocol repositories and brand. OTOY remains a partner and the largest service provider on the network through rendernetwork.com, and Messari states that the 5% protocol fee funds ongoing network operations via OTOY as the primary service provider. The two entities also share individuals, with Jules Urbach as OTOY founder and CEO and the founder of the Render Network, and Trevor Harries-Jones as OTOY COO and a Foundation board member. Public sources do not disclose any mechanism by which the Foundation can direct OTOY as a private company, so any influence appears to run through this partner and service-provider relationship and through overlapping personnel rather than through corporate control.
(Source: Render Foundation FAQ, Announcing the Render Network Foundation, Messari Overview)
Public Foundation materials state that the freeze authority for the RENDER token contract remains in place as a safeguard mechanism against potential smart-contract risk within the upgrade portal. The FAQ states that, for now, there are no plans to change this position, though the Foundation is continuously reviewing it. Public governance materials also show that the Foundation facilitates the proposal process used for significant protocol changes through RNPs. The RNP process includes an initial proposal vote, final RNP vote, and implementation of approved proposals by core Render Network contributors. Emergency proposals may omit the initial vote phase and require an elevated 20% quorum threshold.
(Source: Render Network Proposal (RNP) System, Render Foundation FAQ)
Public sources provide partial disclosure. Public Foundation materials state that the Foundation discloses aggregate Foundation spend and treasury, but not individual compensation. Public Foundation materials describe two primary categories of BME emissions allocation: rewards for node operators in exchange for supplying compute power, and Foundation operations. The FAQ states that Foundation operations include day-to-day business and compliance operations, marketing and growth initiatives, partnership initiatives, grants, research, development, and other administrative processes. It also states that the amount of token burned is directly tied to usage of the network, and that the network charges a 5% fee on completed jobs, with net fiat receipts used to purchase RENDER that is then burned together with any net RENDER receipts received directly for jobs. Public RNP materials add two bounded public details. RNP-006 states that 50% of monthly year-one emissions were allocated to the Render Foundation, and RNP-006 references a 4.5M RNDR loan facility from OTOY to the Foundation as set forth in RNP-004.
(Source: RNP-006, RNP-004, Render Foundation FAQ, Render Foundation FAQ)
Question
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist.
Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
Response
Public Foundation materials identify OTOY as the founder-side entity and Jules Urbach as OTOY’s CEO, but the public sources do not provide a clear jurisdiction or legal-form disclosure for OTOY in this filing context. The FAQ states that OTOY, led by CEO Jules Urbach, founded the Render Network in 2017, announced the formation of the Render Network Foundation in 2023, and contributed stewardship of the Render Network to the Foundation.
(Source: Render Foundation FAQ)
The FAQ also states that RenderLabs is a partner of the Render Network and was created in early 2025 as a for-profit organization to pursue commercial opportunities related to AI applications that could be built for or supported by distributed compute, specifically the Render Network. Because RenderLabs was created in 2025, it should not be treated as the launch-era primary DevCo unless separately supported by nonpublic information.
(Source: Render Foundation FAQ)
Public sources indicate OTOY owns and controls its own proprietary rendering software and technology, which is distinct from the on-chain Render Network protocol. OTOY's IP includes the OctaneRender GPU rendering engine, the ORBX interchange and media format, and LightStage scanning technology, among other tools. Messari describes OTOY as the network's primary service provider that develops the core infrastructure and user-facing tools for the network. The core Render Network protocol repositories and the Render Network brand were transferred from the founding group to the Foundation in 2023, so those assets sit with the Foundation rather than OTOY. The Render Network terms reference a Render Network and OTOY Property Agreement, which indicates a defined property and IP arrangement between the two entities, though its specific terms were not identified in public sources.
(Source: OTOY OctaneRender, Messari Overview, Announcing the Render Network Foundation, Render Network Terms and Conditions)
No public data found for formal OTOY powers over DAO governance, treasury actions, protocol-controlled resources, token administration, or reward parameters. Public Foundation materials state that OTOY remains a partner of the Render Network and operates rendernetwork.com, while Messari describes OTOY as a for-profit company that provides rendering services and develops core infrastructure and user-facing tools for the Render Network.
(Source: Render Foundation FAQ, Messari Overview)
No public data found for formal OTOY powers over Foundation decision-making. Public Foundation materials state that OTOY announced the formation of the Render Network Foundation in 2023 and contributed stewardship of the Render Network to the Foundation. The same FAQ states that OTOY remains a partner of the Render Network.
(Source: Render Foundation FAQ)
No public data found for OTOY pause, upgrade, governance-executor, or similar contract/admin authorities. Publicly described contract/admin authority is instead associated with the SPL RENDER token freeze authority, which Foundation materials state remains in place as a safeguard against potential smart-contract risk within the upgrade portal.
(Source: Render Foundation FAQ)
Public Foundation materials state that OTOY remains a partner of the Render Network and operates rendernetwork.com, which Foundation materials describe as the current largest service on the network. Messari states that a 5% protocol fee is applied per job to fund ongoing network operations via OTOY, which Messari describes as the network’s primary service provider maintaining core infrastructure and user-facing tools for AI and 3D rendering. The public sources do not provide a detailed schedule of token, fee, or treasury distributions to OTOY or any other DevCo entity.
(Source: Render Foundation FAQ, Messari Overview)
Blockworks note: Public sources do not clearly identify a separate primary DevCo legal entity involved in the original token launch. The closest public founder-side development-company surface is OTOY. Public Foundation materials state that OTOY, led by CEO Jules Urbach, founded the Render Network in 2017; announced the formation of the Render Network Foundation in 2023; contributed stewardship of the Render Network to the Foundation; and remains a partner of the Render Network operating rendernetwork.com, which Foundation materials describe as the current largest service on the network. Messari’s commissioned overview similarly describes OTOY as the network’s largest ecosystem partner and as a for-profit company that provides rendering services and develops core infrastructure and user-facing tools for the Render Network.
(Source: Messari Overview, Render Foundation FAQ, Render Foundation Press Resources)
Question
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
Response
The launch token was RNDR, an ERC-20 token on Ethereum. The original September 2017 token sale plan specified a total of 2,147,483,648 RNDR with no additional tokens to be generated. In March 2018 the team announced that the total minted supply would instead be 536,870,912 RNDR, and that the oversupply of 1,610,612,736 RNDR on the old contract would be burned. The 536,870,912 figure is the canonical legacy minted supply.
First-party sources do not publish a precise locked-versus-unlocked split as of the exact token generation moment. The original plan allocated supply across a public sale bucket, a team and advisor bucket with a lock-up, and a development fund, and later summaries describe a large share held in reserve and escrow rather than circulating at launch. The amount actually sold in the public sale was far smaller than the public allocation bucket, with most supply held back.
Recipient categories & use of funds: The September 2017 sale details set out the original launch allocation framework against the then-planned 2,147,483,648 supply. Later summaries describe the same three-way split applied to the 536,870,912 supply, though the bucket labels are reported inconsistently across sources.
(Source: RENDER Emissions and RNDR Metrics (Legacy) Summary, Render ICO (ICO Drops), RNDR Token Sale Details, Render Token (crypto.com), RNDR Token Metrics Deep Dive, RNDR Token (IQ.wiki))
Recipient categories & use of funds: Public sale participants — Roughly 25% allocation bucket. 4,650,922 RNDR reported actually sold in the October 6 to 12, 2017 public sale at 1 RNDR = $0.25 equivalent (1,150 RNDR per ETH), with a 20% genesis bonus. Use of funds: Sale proceeds intended to fund the costs outlined in the whitepaper Use of Funds section.
Recipient categories & use of funds: Private sale participants — January 2018 through May 2018 at 1 RNDR = $0.25 equivalent, with a 2.5% to 30% bonus range. No first-party token count is disclosed. A third-party tracker reports roughly $4.02M raised in Q2 2018, implying about 16M RNDR before bonuses, which conflicts with other trackers. Use of funds: No first-party use-of-funds disclosure identified.
Recipient categories & use of funds: Advisors, team members, partners and providers — 10% allocation bucket in the original September 2017 plan. Use of funds: Allocated to contributors actively developing the network and to providers working alongside OTOY.
Recipient categories & use of funds: RNDR Reserve and escrow / Render User Development Fund — Described in later summaries as roughly 10% RNDR Reserve and 65% escrow, and in the September 2017 plan as a 65% Render User Development Fund. Use of funds: Reserve and escrow tokens flow into the ecosystem over time for user acquisition, node-operator bonuses, airdrops, and supply and demand modulation, held in third-party custody and escrow.
Both the public sale and the private sale used a fixed 1 RNDR = $0.25 USD-equivalent price. This was a fixed-price sale rather than a liquidity bootstrapping mechanism or auction. The public sale used an ETH to RNDR rate of 1,150 RNDR per 1 ETH, set from a 30-day weighted average of the ETH price at the start of the sale. The token-metrics page describes a 20% genesis bonus on the public sale and a 2.5% to 30% bonus range on the private sale.
(Source: RENDER Emissions and RNDR Metrics (Legacy) Summary, RNDR Token Sale Details)
The launch ticker was RNDR on Ethereum. The token was later bridged to Polygon and then upgraded to RENDER on Solana, which is the currently supported token. The old RNDR token still exists, but Foundation support going forward is focused on RENDER.
(Source: Render Network Upgrade Portal FAQ, RNDR Token Metrics Deep Dive)
Supply is not fixed. The original September 2017 plan specified 2,147,483,648 RNDR. In March 2018 the minted supply was reset to 536,870,912 RNDR and the 1,610,612,736 oversupply was scheduled to be burned. Under the current burn-and-mint-equilibrium model adopted in RNP-001, the emissions schedule adds a theoretical 107,374,182 tokens, implying a maximum theoretical supply of 644,245,094 before burns. Emissions follow a declining schedule and are offset by tokens burned for completed network work, so the regime is inflationary with an offsetting burn rather than a fixed cap.
(Source: RNDR Token Sale Details, RNDR Token Metrics Deep Dive, Render Network Whitepaper, RNP-001)
Initial vesting / release schedules: First-party sources state the public sale had no vesting and the private sale had no vesting. The original September 2017 sale details applied a 6-month lock-up to the 10% advisor, team, partner, and provider allocation. Reserve and escrow tokens were not placed on a fixed public vesting schedule but were held back in third-party custody to flow into the ecosystem over time. The RNDR-to-RENDER upgrade is separate from the original launch schedule. RNDR can be upgraded to RENDER at a 1-to-1 ratio, the upgrade assistant stays open indefinitely, and governance now occurs with RENDER on Solana while voting with RNDR on Ethereum has been deprecated.
(Source: RENDER Emissions and RNDR Metrics (Legacy) Summary, RNDR Token Sale Details RNDR Token Metrics Deep Dive, Render Network Upgrade Portal FAQ)
Initial vesting / release schedules: 6-month lock-up per the September 2017 sale details.
Initial vesting / release schedules: Held back from circulation rather than vested on a fixed public schedule.
Question
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
Response
No airdrop planned or conducted: The project’s public safety guidance states THERE IS NO AIRDROP. Public sources do not identify a public TGE airdrop schedule or a per-address airdrop allocation source.
(Source: Important Safety Information)
Question
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Response
Blockworks note: No market maker agreements for RENDER were found in public disclosures. This reflects the absence of publicly available information and is not a confirmation that no such arrangements exist. Any market maker arrangements, if any were ever entered into, have not been publicly disclosed.
Question
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Response
Blockworks note: No centralized or decentralized exchange agreements for RENDER were found in public disclosures. This reflects the absence of publicly available information and is not a confirmation that no such arrangements exist. Any exchange listing or liquidity arrangements, if any were ever entered into, have not been publicly disclosed.
Question
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Response
Blockworks note: (Source: RENDER Emissions and RNDR Metrics (Legacy) Summary, Render Foundation Press Resources)
Question
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself.
If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
Response
On July 18, 2025, the Foundation announced the deprecation of legacy RNDR on Polygon after identifying unauthorized access to an inactive wallet connected to one of the legacy Polygon RNDR contracts.
A public incident report describes the issue as unauthorized access to an inactive wallet connected to a legacy Polygon RNDR contract.
The same report states that the event had the potential to affect about 1.4 million RNDR on Polygon, representing less than 0.3% of circulating supply, and also states that no funds were lost.
Public incident materials state that the Foundation deprecated the bridge between RNDR on Polygon and Ethereum Mainnet, released a direct bridge at polygon.rendernetwork.com to support a 1:1 upgrade to Solana-based RENDER, and worked with the Polygon Council and an external third-party auditor.
The Foundation publicly described the risk as mitigated through the bridge deprecation and migration response.
Question
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
Question
Identify to the best of your ability the token's current deployments across chains, including project-issued deployments, project-endorsed representations, and, if possible, documented third-party wrapped or bridged representations.
For each entry, provide:
Multiple entries on the same chain are permitted.
Definition: A protocol-level asset is an asset whose balances and transfers are handled directly by the blockchain's core rules, rather than by a token smart contract. For protocol-level assets without a token contract address, enter "No contract address" and identify the asset and chain.
Response
Token Contract Address or Onchain Asset Identifier | Chain | Deployment Type | Project Relationship | Supporting Source |
|---|---|---|---|---|
0x61299774020da444af134c82fa83e3810b309991 | Polygon POS | Direct token issuance | native-token | |
0x6de037ef9ad2725eb40118bb1702ebb27e4aeb24 | Ethereum | Direct token issuance | native-token | |
rndrizKT3MK1iimdxRdWabcF7Zg7AR5T4nud4EkHBof | Solana | Direct token issuance | native-token |
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.
See the official Foundation incident announcement.
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
Response
(a) Impact of regulatory change on TGE and listings
The Render Foundation’s privacy notice states that it may process personal data for AML/CTF checks, sanctions screening, and regulatory/tax authority requests. The Foundation’s privacy notice says it conducts AML and counter-terrorist-financing checks, sanctions screening, and may share information with authorities such as the Cayman Islands Monetary Authority and the Tax Information Authority.
(Source: Privacy Notice)
(b) Entity-level regulatory impact
Public sources describe the Render Network Foundation as a Cayman Islands foundation company and a governance organization for the network. Public sources identify the Foundation as a Cayman Islands foundation company and governance organization.
(Source: Privacy Notice, The Render Network Foundation)
(c) Tokenholder tax treatment
No public documentation found providing detailed public tokenholder tax guidance.
(Source: Privacy Notice)
(d) Jurisdictional & user access restrictions
Public sources do not provide a jurisdiction-by-jurisdiction public access matrix. Public readers therefore should not assume that listing availability, token access, or service availability will be uniform across jurisdictions based on the cited sources alone. Foundation bounty terms do, however, show at least one public compliance perimeter: participants in that program cannot reside in jurisdictions subject to sanctions that prohibit participation, are responsible for taxes on rewards, and are responsible for complying with laws and regulations regarding the holding and trading of rewards. The upgrade FAQ also states that RNDR trading and migration support can vary across centralized exchanges over time.
(Source: Privacy Notice, The Render Network Bounty Program Terms and Conditions, Render Network Upgrade Portal FAQ)
(a) Bugs and design flaws
Public materials show that Render depends on bridge, upgrade, and contract infrastructure that can create operational and security risk. The Foundation FAQ states that the freeze authority for the SPL RENDER token contract remains in place as a safeguard mechanism against potential smart-contract risk within the upgrade portal, and that the Foundation has no current plans to change this position while continuing to review it.
(Source: Render Foundation FAQ)
The July 18, 2025 Polygon incident also shows that legacy bridge and wallet surfaces can require emergency mitigation. In that incident, the Foundation announced the deprecation of the legacy Polygon implementation after unauthorized access to an inactive wallet connected to one of the legacy Polygon RNDR contracts.
(b) Security measures and their limitations
Public technical materials describe privacy/security controls such as end-to-end encryption, hashing, virtualization, secure centralized storage, and state that frames are watermarked prior to download to ensure payment before scenes are downloaded. Those measures reduce some privacy, payment, and content-protection risks, but they do not eliminate the possibility of failures in bridge logic, wallet handling, contract implementation, or other network components.
(Source: Render Network Whitepaper)
(a) Critical economic assumptions
Render’s current public token-economics model depends on continued demand for network work. Under the BME model, creators pay by converting fiat into RENDER, the corresponding RENDER is burned, and node operators and other participants are compensated through scheduled emissions. If network demand, burn activity, or node participation underperform, the intended balance between burn and emissions can weaken.
(Source: Burn Mint Equilibrium, RNP-001, RNP-006)
(b) Governance control over monetary policy & rewards
Public governance materials show that tokenholder voting can affect economic parameters. RNPs are the primary mechanism for significant protocol changes, including adjustments to the economic model or token mechanics. Final RNP votes require at least 50% approval of total votes cast and a quorum of at least 15% of the total combined RNDR and RENDER token supply, while emergency proposals may omit the initial vote phase and elevate the quorum requirement to 20% of the total Render token supply. Governance-controlled changes could alter reward distribution, burn-emission balance, token mechanics, and other tokenholder economics.
(Source: Render Network Proposal (RNP) System, RNP-000)
The public record also shows supply-transition and migration risk. Public sources state that the original minted RNDR supply was 536,870,912 and that RNP-001 adds a theoretical 107,374,182 tokens before burns. The RNDR-to-RENDER upgrade assistant remains open indefinitely, but the upgrade FAQ states that governance and voting occur with RENDER on Solana and that voting with RNDR on Ethereum has been deprecated. It also states that the upgrade is compulsory for governance but not mandatory for holding.
(Source: RENDER Emissions and RNDR Metrics (Legacy) Summary, RNP-001, Render Network Upgrade Portal FAQ)
