Render Network Proposal (RNP) System

How tangible changes are made on the Render Network

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. The steps an RNP needs to take are as follows:

1. Initial Proposal or Grant

2. Draft Submission

3. Initial Proposal Vote

4. Render Network Team Review

5. RNP Vote

6. Implementation

Initial Proposal or Grant

Members should reach out to an admin or moderator on the Render Network Team to discuss an improvement to the protocol. The Team will help direct if this is a good candidate for an RNP or a Grant. Grant information can be found on the Render Foundation Website. If it is a good candidate for an RNP the admin or moderator will label it as an “Initial Proposal” and create a dedicated channel in the Render Network Discord. Proposals must conform to the Render Network guidelines and use the RNP Template before approval by an admin or moderator.

Draft Submission

The Initial Proposal will then be discussed by the community within its Discord Channel.

During this stage, the author may adjust the Initial Proposal based on feedback received, provided such changes are tracked.

At any time after creation of the Discord Channel, the author may either notify an admin via the Discord Channel that they will be withdrawing the proposal, or can request it be put through to a “Initial Proposal Vote”, at which point the Discord channel will be closed and will no longer accept new comments.

Initial Proposal Vote

Each week on Monday at 12pm PT, the Initial Proposals that are available for 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 12pm PT. The vote will be a simple majority vote and will have no restrictions on total votes, supply, etc.

All RNDR 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 (either Layer 1 or Layer 2) was present in their wallet at the time the Snapshot vote was opened. It is not possible to use RNDR held within a liquidity position on an exchange to vote. If successful, an RNP will be created in GitHub and marked as “In Render Team Review”.

Render Network Team Review

The RNP will then 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 up to 21 days, an internal vote will be taken regarding whether the RNP is ready to proceed to “Open for RNP Vote” status. This review process is critical to the RNP implementation in two ways:

1. It seeks to add more color to the initial RNP in order to give the community more information for voting purposes.
2. 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, 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 its status is updated to "Open for RNP Vote”. 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.

RNP Vote

Snapshot voting for Open for RNP Vote RNPs will be subject to a vote every week commencing at 5pm PT on Wednesday. Voting will be open for 6 days, until 5pm PT on the following Tuesday.

RNP approval will be judged on a majority of 50% of total “Approve” or “Deny” votes cast ratio AND a minimum of 25% of total supply being cast to vote. Any wallet can abstain from the vote and not count for the for or against but count to the total votes cast. For example, if the vote was 80% approve, but only 10,000 tokens were cast for the vote, the RNP would not pass. It would pass if it was the same scenario with 25% of the total supply participating by abstaining in addition to the 10,000 tokens that voted “Approve” or “Deny”.

Implementation

If an RNP is able to garner community approval, its status will be updated to “Approved and on the Roadmap”, and it will then be added to the Roadmap. The network will continue to use GitHub as the basis for communication of implementation status on such approved RNPs providing notice when they move into development by updating their status to “In Development”, and finally “Implemented”, 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 implemented.

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, timelines can be adjusted in order to more urgently implement a community approved proposal. For an emergency proposal, the Draft submission and Initial Proposal Vote can be forgone provided that in such instances, the threshold for RNP approval would be increased to 33% of total supply.

** All RNP statuses can be viewed within Github, where they will be classified as "In Render Team Review", "Open for RNP Vote", "Rejected", "Approved and on the Roadmap", “In Development” and “Implemented”. **

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.

  1. If approved, the Proposal will be tagged "In Development" on Github and the Cooldown Period will commence.

  2. If Rejected, the Proposal will move into an "archived" state for historical purposes.

• Foundation Director Approval: If, following the approval of a Proposal by the Tokenholders, a majority of the Foundation Director(s) acting in the best interests of the Foundation reasonably determine that such a Proposal, if implemented, would:

  1. Compromise the Foundation Director(s) fiduciary duties as they are owed to the Foundation.

  2. 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).

  3. Cause harm (including reputational harm) to the Foundation (as determined in the Foundation Director(s) sole discretion).

  4. Cause the Foundation to be in breach of any contracts, agreements or any other arrangements, such Foundation Director(s) may reject the Proposal within two (2) days following the date upon which Tokenholders have approved such Proposal in accordance with the RNP Process ("Cooldown Period").

  5. Furthermore a majority of Foundation Director(s) may reject a Proposal that has been approved by Tokenholders if the implementation of such a Proposal is not sufficiently specified and detailed, an/or would require the Foundation Director(s) to exercise broad discretion.

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, 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.