Welcome to the Render Network Foundation
The Render Network Foundation is the governance organization for the Render Network, providing a community led decentralized governance framework and process for shaping the future of the Render Network.
Decentralization has been a core tenet of the Render Network since its creation and with the Render Network community rapidly growing - encompassing a wider variety of participants and stakeholders - it is essential for all participants in the community to have a role in shaping the direction of the Network.
The Render Network Foundation is the first step in that direction: a self-governing, decentralized system by which every member of the community - Creators, Node Operators, Liquidity Providers, the Render Network Team, Partners, and Advisors - have the ability to propose and vote on changes to the Render Network.
Below is a living guide that will help you understand how YOU can participate in the Render Network Foundation and contribute to the growth of the Render Network.
Membership
The Render Network Foundation strives to include all participants of the Render Network. It is paramount that active and engaged network participants are rewarded with ownership of the network in order to ensure that the network continues to evolve in the direction that serves its users most effectively.
Stakeholders
Creators
Creators are digital artists, developers and studios who utilize the Render Network to render their digital creations on the blockchain for a fraction of the speed and cost of standard in-house rendering or computation.
Consumers
Consumers constitute a more passive group of creative participants of the Render Network, such as NFT collectors, gamers and fandom communities, who compose and interact with core digital assets, IP and services offered by Creators on the Render Network. NFT’s minted on the Render Network may also enable creators to offer consumers voting power and agency on governance for their specific services and content they offer through the Render Network.
Node Operators
Node Operators are GPU owners who have registered their machines on the Render Network to be used by Creators in order to render their work when not in use, in exchange for RNDR Tokens.
Liquidity Providers
Liquidity Providers are RNDR Token holders who hold RNDR on applicable centralized and decentralized exchanges.
Render Network Team
The Render Network Team are the builders and maintainers of the Render Network. This group includes the Render Network’s team of developers and blockchain engineers, and various other team members who provide services to the Render Network and run the everyday operations of the platform.
Render Network Partners
Render Network is partnered with many groups and individuals in order to improve the capabilities of the platform. This includes companies like Multicoin, NVIDIA, Google, Apple and Microsoft, as well as individuals and key advisory board members such as digital artist Beeple, Ari Emanuel (founder & CEO of Endeavor/WME/IMG) and fellow blockchain projects like Solana and Polygon.
The Render Network Foundation and Tokenholders
Within the framework of the Network, the above stakeholders (ideally all represented under the umbrella of "Tokenholders") would be considered a part of and beneficiary of the Render Network. The relationship between Tokenholders and the Foundation can be summarized as follows:
Tokenholders are represented by the Foundation, which represents the Tokenholders' interests in connection with contractual and legal processes, including regulatory compliance and those other matters set forth in the Foundation articles.
The Tokenholders have the authority to make certain decisions in relation to the Foundation as set forth in these Bylaws and the Foundation Articles. The Foundation retains certain other decision-makers with responsibilities dictated by Cayman Islands Law. To the extent, if there is ever a conflict between the decisions of the Foundation and the Tokenholders, the decisions of the Tokenholders will prevail, unless a different outcome is required under Cayman Islands Law.
The Tokenholders should ensure that the Foundation has sufficient authority and resources, including funding, to execute upon the Foundation’s mandate, meet the Foundation’s obligations under applicable law, and satisfy the Foundation’s contractual obligations entered into in accordance with the Foundation Articles or Bylaws.
The Foundation has engaged with certain third parties to provide services as the Foundation Director(s) and Foundation Supervisor, as required by Cayman Islands Law. In accordance with the terms of the Foundation Articles and Bylaws, and subject to Cayman Islands Law, the Foundation Director(s) and Foundation Supervisor are required to act at the direction of the Tokenholders in respect of certain matters.
The Foundation's Directors are authorized to take any actions reasonably necessary on behalf of the Foundation to give effect to a vote of the Tokenholders, including passing any director resolutions to memorialize such vote(s).
To the extent that there is ever a conflict between the provisions of the Bylaws and the Foundation Articles, the Foundation Articles will prevail.
Foundation Directors are not fiduciaries for the Tokenholders.
The Foundation is helmed by Tristan Relly (Head of Operations), Andrew Hyde (Head of Communications) and Ryan Shea (Foundation Advisor).
Tristan Relly (Head of Operations)
After over two decades of working in financial advisory roles at one of the world’s leading financial service providers and other blue-chip companies, Tristan Relly has taken his skills from an illustrious career and put them towards new directions. Before Render Network, he cut his teeth in DeFi and served as the CEO of the Balancer Foundation (servicers of the Balancer Protocol and ecosystem). Prior to that he helped lead a passionate team to set up an NPO with the purpose of protecting and enhancing natural heritage on Cayman Brac, the most eco-diverse and least protected island in the Cayman Islands chain.
Andrew Hyde (Head of Communications)
Andrew Hyde has a passion for community, writing, travel and startups. He founded Startup Weekend alongside Ignite Boulder, TEDxBoulder, Startup Week as well as many smaller events. He is a co-owner of his favorite cafe in the world in Trident Booksellers and Cafe in Boulder, Colorado. He is the director of Glider.com, a 501c3 nonprofit that throws some amazing community events, and is working to help build up the Render Network Foundation communications and community going forward.
Ryan Shea (Foundation Advisor)
Ryan Shea spent the last three years working at Solana Labs and launched the Solana network and ecosystem. Before that, he collaborated with companies building on Ethereum like Gitcoin and Decentraland. Ryan’s now leading NATION.io, a company building tools for on-chain organizations, and serving in an advisory capacity for the Render Network Foundation.
Trevor Harries-Jones, OTOY's Chief Operating Officer, will be joined by two other independent professional directors on the Foundation's Board of Directors.
Trevor Harries-Jones (Director, Render Network Foundation)
Trevor Harries-Jones brings with him a wealth of experience as a financial director, manager and leader across multiple industries over the last 25+ years. With a start in financial management in one of the Big 4 firms, Trevor began his journey into media with work at OpenTV, quickly rising to an SVP of Finance position, where he oversaw global accounting, treasury allocation and oversight. From there he moved onto Yola.com, a leading SAAS website building company, serving across a number of C-Level positions as both President, COO, CEO and Vice-Chair of the Board of Directors, helping to guide Yola.com through tremendous growth as one of the most affordable and easy-to-use services on the market.
He has since brought that same mentality and experience to the Render Network, serving as parent company OTOY’s COO as he has helped usher in the next phase of development for the Render Network.
Communications Structure
To accomplish the goals of the Render Network Foundation, RNDR Tokens will be used to hold utility in token-weighted governance processes over key protocol parameters and overall direction.
This will begin with the setting up of a working board of governance consisting of community members, the Render Network Team, and Render Network partners, before eventually transitioning to the formation of a decentralized autonomous organization, otherwise known as a DAO. The establishment of the Render Network Foundation is the first step in this process.
Communications
The Render Network maintains a number of community chats across multiple platforms, including Telegram, Twitter, Discord and Instagram. Currently a majority of news from the Render Network team is directly communicated through the Render Network Medium blog, and echoed across our channels like Telegram, Discord, Twitter and Instagram.
In line with other popular crypto projects, Discord will be used as a key source of communication as we believe that it gives our community members the easiest access to other members of the community and the Foundation.
Community Guidelines
Equality: It is important that everyone feels like they have a voice, no matter their background and however small or large they are. The network is working to bring high end 3D graphics and related digital experiences to anyone with a creative vision.
Constructiveness: The network is more than the sum of its parts, and looks for positive contributions to building the future of decentralized GPU computing.
Transparency: Decisions will be publicly communicated openly and communication channels will provide open, publicly accessible forums to debate the future of RNPs.
Dispute Resolution Mechanics
Should a controversy, dispute or claim arise out of or in relation to the Bylaws ("Dispute"), the Foundation, the Directors, the Supervisor or the Tokenholder (as appropriate) must give 30 days' notice of such Dispute to the relevant party/ies (the "Notice of Dispute"). Should the Dispute not be resolved at the expiration of 30 days after service of the Notice of Dispute, the relevant party may commence arbitration proceedings in accordance with the below guidelines. In any dispute involving the actions of the Foundation Directors or the Supervisor, the Foundation, and not the Foundation Directors or Supervisor, shall be party to the arbitration proceedings.
Should the Dispute remain at the expiration of 30 days after service of the Notice of Dispute, the Dispute shall be settled by arbitration administered by the International Centre for Dispute Resolution in accordance with its International Arbitration Rules (the "Rules"). The arbitration shall be seated in George Town, Grand Cayman and governed by Cayman Islands law. The language of the arbitration shall be English.
The arbitration shall be determined by a sole arbitrator to be appointed in accordance with the Rules.
Any award or decision made by the arbitrator shall be in writing and shall be final and binding on the parties without any right of appeal, and judgment upon any award thus obtained may be entered in or enforced by any court having jurisdiction thereof.
No action at law or in equity based upon any claim arising out of or related to these Bylaws shall be instituted in any court of any jurisdiction.
Proposal and Voting Process
RNP stands for Render Network Proposal and will be the format that the community can use to give input and feedback on the direction of the Render Network.
Proposal Process
RNPs are the process by which the community can affect change on the Render Network. Outlined below are all of the steps through which a community member can go from idea to implementation onto the Render Network:
RNP Idea Genesis: An RNP Idea is first submitted as an “Initial Proposal” to an admin or moderator in order to create a pending RNP post on Github and a dedicated channel in the Render Network Discord. There will be a designated Discord channel created for these proposals to be submitted. The RNP must be in .pdf format to be reviewed by an admin.
Proposals will be reviewed for a period of up to 21 days, and must conform to the Render Network guidelines and use the RNP Template before approval by an admin or moderator and becoming a RNP. Once approved, the user that posted the RNP will be notified on Discord.
The RNP idea is then discussed within the community channel for 21 days. The RNP cannot be changed or edited during this time – it is locked as soon as it is posted.
RNP Draft and Submission Once the 21 day feedback window is over, the author of the RNP will have the opportunity to update their submission based on comments, and resubmit their RNP for an additional week of comments. If they elect not to, the Discord channel will be closed and will no longer accept new comments, and the proposal will move on to the next stage. An admin or moderator will send the creator of the RNP the “RNP Template” Form, where they are able to lay out the details of their proposed changes to the Network, and consider any comments made during the community discussion period.
Once the RNP proposal has been finalized, it will be put through a "Community Snapshot vote", where the community can decide to approve or deny the proposal for further review by the Render Network Team. Each week on Monday at 3pm ET, the RNPs that are available for Snapshot vote will be released via an announcement on the Render Network Telegram, Discord and Twitter accounts. The actual voting period will last 72 hours and conclude on the respective day at 3pm ET. The vote will be a simple majority vote and will have no restrictions on total votes, supply, etc.
Voters will need to have tokens present in their Layer 1 or Layer 2 wallet that they have connected to Snapshot in order to vote. All tokens currently held within a liquidity position on an exchange will not be available to be used in a given vote.
If the proposal is approved, the RNP will then be numbered accordingly and officially added to the Pending RNP Database for further processing. All Pending RNPs will be put on Github if they pass through this process.
RNP Overview The RNP Draft will be reviewed and commented on by the Render Network team (made up of core members of the Render Network engineering team, community moderators and infrastructure developers) to make sure that it is economically and efficiently feasible, project costs and review any additional issues or topics that may pose a block to the RNP. After initial discussions, which will last between 1-7 days, an internal vote will be taken regarding whether the RNP draft is ready for approval to “Live Pending” status. This review process is critical to the RNP implementation in two ways:
It seeks to add more color to the initial RNP in order to give the community more information for voting purposes.
It puts some responsibility in the hands of the actual implementation team to perform due diligence on the RNP process.
The review and the comments will be made public by the team on the Discord and Github repo, so that the community can understand the team’s thought process and reasoning.
If the RNP is approved (has been deemed technically feasible without significant roadblocks to development, as listed above), it moves onto the next step and becomes a “Live Pending RNP”. If the RNP is not approved, it can be edited and resubmitted as a new Initial Proposal, so long as the proposal has not been deemed intangible or illegitimate by the Render Network team and moderators.
Live Pending RNP and Snapshot voting RNPs that have passed the overview and initial vote process become Live Pending RNPs and are subject to a Snapshot every week at 8pm ET on Wednesday. Once live on Snapshot, Live Pending RNPs are open to voting for 6 days, until 8pm ET on the Tuesday after release. All RNDR Token holders will have access to voting mechanisms on proposed changes. To participate in the Snapshot vote, users must go through a wallet verification process to confirm RNDR Tokens are present in their wallet. Additionally, user delegation of voting rights will be implemented at a future date via Tally, though voting will still take place on Snapshot.
RNP Implementation RNP approval will be judged on a majority of 50% of total votes cast ratio (i.e. if 100m tokens were cast for the vote, the win threshold would be 50,000,001 or greater) AND a minimum of 25% of total supply being cast to vote. For example, if the vote was 80%, but only 10,000 tokens were cast for the vote, the RNP would not pass.
If an RNP is able to garner community approval, it will then be added to the queue for implementation. The network will continue to use GitHub as the base for RNPs, with the communication coming from Discord. The Render Network Team will be in charge of implementing said changes to the Network. Though RNP changes may not be implemented immediately, all approved RNPs will eventually be addressed and pushed onto the Network.
Emergency Proposal and Voting Protocol This proposal timeline and voting threshold can be adjusted in the case of an "Emergency Proposal and Voting" scenario. In cases where a proposal has been deemed an emergency, for example if action needs to be taken to ensure uninterrupted operation of the Network, minimum voting thresholds and voting timelines can be adjusted in order to more urgently implement a community approved proposal. For an emergency proposal, the community comment window would be shortened to 24 hours, and the voting threshold to move onto review and potential implementation would be increased to 33% of total supply.
** All RNP statuses are classified as “In Review” (Currently being discussed by the community and/or Render Network Team), "Open for Voting" (currently up for Snapshot vote), "Approved" (have passed a community Snapshot vote), "Rejected" (has not passed a community Snapshot vote), "In Render Review" (currently being discussed by the core Render Network team), "Full Approval" (has passed through both community and final Snapshot votes), “In Development” (currently being worked on by the Render Network development team) and “Implemented” (Approved and in use on the Render Network). **
Proposal Phases
The Proposal Process as outlined above is the first of two general phases. They are split into "Tokenholder Approval" (the above) and "Foundation Director Approval".
Tokenholder Approval: Upon expiration of the voting period as defined above, the Live Pending Proposal will either be approved or rejected by Tokenholders.
If approved, the Live Pending Proposal will be tagged "In Development" on Github and the Cooldown Period will commence.
If Rejected, the Live Pending Proposal will move into an "archived" state for historical purposes.
Foundation Director Approval: If, following the approval of a Live Pending Proposal by the Tokenholders, a majority of the Foundation Director(s) acting in the best interests of the Foundation reasonably determine that such Live Pending Proposal, if implemented, would:
Compromise the Foundation Director(s) fiduciary duties as they are owed to the Foundation.
Be in violation of the Foundation Bylaws, the Foundation Articles, the RNP Process, any statutory requirements of Cayman Islands Law (or the laws or regulations of any other applicable jurisdiction).
Cause harm (including reputational harm) to the Foundation (as determined in the Foundation Director(s) sole discretion).
Cause the Foundation to be in breach of any contracts, agreements or any other arrangements, such Foundation Director(s) may reject the Live Pending Proposal within two (2) days following the date upon which Tokenholders have approved such Live Pending Proposal in accordance with the RNP Process ("Cooldown Period").
Furthermore a majority of Foundation Director(s) may reject a Live Pending Proposal that has been approved by Tokenholders if the implementation of such Live Pending Proposal is not sufficiently specified and detailed, an/or would require the Foundation Director(s) to exercise broad discretion.
Live Pending Proposals that are approved by Tokenholders and which are not rejected by a majority of the Foundation's Director(s) during the Cooldown Period will move into a queue for eventual implementation by the DAO manager.
Alternatively, Live Pending Proposals that (i) do not meet the Proposal Threshold, (ii) do not meet DAO Quorum Requirements, (iii) are otherwise rejected during the Voting Period by Tokenholders or (iv) otherwise are rejected by a majority of the Foundation Director(s) during the Cooldown Period, will be archived for historical purposes.
Governance
While the creation, voting and ultimate approval of RNPs is driven by the Render Network Community, there are certain aspects that necessitate the involvement of members of both the central Render Network Team and governing bodies within the Render Network Foundation. In pursuit of clarity, the following will detail: the initial and future processes by which Render Network Foundation boards will be created and selected; how disputes and contradictions within RNPs will be adjudicated; and how grants will be awarded from the Render Network Foundation funds.
Voting Matters
Tokenholders have the authority to engage in the following activities:
Elect Individuals or organizations into the role of director and/or supervisor of the Foundation, and the renumeration of such newly appointed individuals or organizations.
Remove individuals or organizations from the role of director and/or supervisor of the Foundation (provided that the Foundation may not, at any time, be left with no directors and/or no supervisor).
Admit any member(s) to the Foundation or restrict/prohibit the subsequent admission of members.
Provide consent to any proposed changes to these bylaws which amend or remove the rights of the Tokenholders under these bylaws.
Provide consent to any proposed changes to the Foundation's articles which amend or remove the rights of the Tokenholders under the Foundation's articles.
Change the DAO Quorum Requirement.
Perform adjustments to economic parameters with respect to the Token; provided that, in the instance of an Emergency Meeting, the Foundation Director(s) may perform adjustments to economic parameters with respect to the Token pursuant to a majority vote of the Foundation Director(s).
Fund transactions by the Foundation from the Foundation Multisig, including, but not limited to, grants for supporting the development of the Render Network, commercial agreements and employee contracts; provided, however, that the release of any funds from the Foundation Multisig is in accordance with applicable legal and regulatory regimes, included, but not limited to, any know-your-customer (KYC) or other screening and compliance rules as may be applicable from time-to-time.
Director Authorities
Subject to the Foundation Bylaws, the Foundation Director(s) have the authority to engage in the following activities:
Activities outside of the RNP process, at their reasonable discretion, so long as such activities do not contradict the terms set forth (x) by any Live Pending Proposal approved by Tokenholders, (y)these Bylaws or (z) the Foundation articles.
Coordinate emergency operations on behalf of the DAO, Tokenholders or the Foundation.
Make changes to these Bylaws if the Foundation Director(s) believe such changes would improve the Foundation Director(s)' ability to fulfill their obligations (the 'Amendment Authority"). Directors agree in good faith to exercise such Amendment Authority pursuant to the RNP process unless such Amendment Authority must be exercised at an Emergency Meeting as described below.
Call and hold emergency meetings ("Emergency Meetings") to enable the Foundation Director(s) to rapidly respond to an imminent security threat to (w) the DAO, (x) any protocol utilizing the Token, (y) the Tokenholders or (z) the Foundation, and the same rules that apply to Foundation Directors meeting in accordance with the Foundation Articles will apply to Emergency Meetings, except that:
an Emergency Meeting does not need to be convened with reasonable notice to the Foundation Director(s);
there is no Quorum requirement for an Emergency Meeting; and
the Foundation Directors will not publish minutes of an Emergency Meeting until the underlying security threat has been remedied or judged to no longer be a threat, in the Foundation Directors' sole discretion.
FAQs
How do I file a Dispute?
See "Dispute Resolution Mechanics" above.
What were the details around the most recent Partner Token Distributions?
20 partners in total were involved between the two tranches of Partner Distributions.
The first tranche of Partner Distributions commenced in October 2021, with 48m tokens distributed over a 12-month vesting period.
The second tranche of the Partner Distributions commenced in December 2021, with 110m tokens distributed over both 12 and 18 month vesting periods.
As of 1/1/2023, 13.4M tokens remain un-distributed and will be distributed evenly over the first 6 months of 2023.
How many votes does a Token carry?
Each token represents one vote.
How does a "Live Pending" proposal pass?
A Live Pending Proposal will be adopted only if:
The Proposal Threshold is satisfied
The DAO Quorum Requirement is satisfied
‘Yes’ receives the affirmative vote of 50% or more of the Tokens casted for such Live Pending Proposal in accordance with the RNP Process
The Live Pending Proposal is not rejected by a majority of the Foundation Directors during the Cooldown Period
In all other circumstances, the Live Pending Proposal will fail.
What happens to rejected proposals?
Any Live Pending proposals that do not meet the requirements above will be rejected and archived for historical purposes. They will be viewable under the "Rejected" tab in the Github repo.
Additional Links
Render Network Website: https://render.x.io Render Network Knowledge Base: https://know.rendertoken.com Render Network Twitter: https://twitter.com/rendertoken Render Network Telegram: https://t.me/s/rendertoken Render Network Discord: https://discord.gg/rendertoken Render Network Instagram: https://www.instagram.com/rendertoken/
Glossary
Render Network Proposal (RNP): The process by which a community member creates change on the Render Network, which is then voted on by the Community, reviewed by the Render Network team and Foundation review board, and implemented by the Render Network team.
Render Network Proposal Template: The template used to format RNPs, found on Github in RNP-000. Intended to keep all proposals universal in scope and necessary information.
Render Network Foundation: The governing body of the Render Network, comprised of participants from all facets of the Render Network ecosystem.
Decentralized Autonomous Organization (DAO): A body of governance in which authority and decision making is not consolidated within one unit, but spread out across multiple units.
Bylaws: These governing bylaws of the Foundation, as may be amended from time to time.
Cayman Islands Law: The rules, regulations and laws of the Cayman Islands from time to time.
Cooldown Period: provides an opportunity for Foundation Directors to assess the relevant risks and downsides of approved proposals and ultimately reject such proposals if they undermine the fiduciary duty of the Foundation Directors or violate Cayman Islands Law, among other things.
DAO: "decentralized autonomous organization" (See above).
Render Network DAO: collectively, the decentralized community of individuals that own, as evidenced by the Ethereum blockchain, a Token.
DAO Manager: the person or entity elected by the Tokenholders to manage the implementation of proposals or manage other matters as the Tokenholders may direct from time to time.
DAO Quorum Requirement(s): initially 25% of the total circulating supply of the Tokens, or such number of Tokens as is updated from time to time, to reflect any changes as voted on by the Tokenholders in accordance with these Bylaws.
Emergency Meeting: has the meaning given in Section 3(b)(iv) of these Bylaws.
Foundation: The Render Network Foundation.
Foundation Articles: the Memorandum and Articles of Association, as may be amended from time to time.
Foundation Director(s): the director(s) of the Foundation, which have certain powers and duties pursuant to Cayman Islands Law and as further described in the Foundation Articles.
Foundation Multisig: the Ethereum based smart contract address that contains the Foundation’s assets.
Foundation Supervisor: the supervisor of the Foundation, which has certain powers and duties pursuant to Cayman Islands Law and as further described in the Foundation Articles.
Governance Forum: a governance forum page to be designated by the Foundation from time to time in accordance with the governance mechanics set forth herein, which initially shall be on a Discord account page.
Initial Proposal: a proposal for the Render Network put forth by a Tokenholder.
Live Pending Proposal: an Initial Proposal for the Render Network that has been reviewed and affirmed by the Render Network team and is subject to an imminent vote for implementation.
Proposal Threshold: that the Tokenholder putting forth the Initial Proposal must hold at least one (1) Token[2].
Token: the governing token of the Render Network protocol, known as RNDR Token, represented on the Ethereum blockchain.
Tokenholder: any holder of the Token.
Voting Period: a six (6) day period during which the Tokenholders can vote in favor of, against or abstain from voting for a Live Pending Proposal.
Last updated