Proposal Process
Phase 1: RFP Idea
An RFP Idea is submitted as an idea via Discourse (community.radiant.capital) and must receive confirmation from the DAO Intake Administrator to ensure it complies with DAO-approved guidelines before it appears to the community.
A minimum of 2500 locked RDNT is required to engage as an RFP Author.
Pursuant to approval, DAO Intake Admin will tag the RFP Idea with the appropriate proposal category and make the post viewable to the public.
The person or people submitting the RFP Idea will be referred to as the “Author” or “Authors”.
Multiple members can work together on an RFP Idea, but it should be submitted only once.
The RFP Idea informally gathers upvotes and/or comments via Discourse interface over a seven (7) day period.
A minimum of one (1) locked RDNT is required to engage as an RFP commenter.
At the end of the seven day cycle, the pending RFP Ideas will be categorized as “Approved to Vote” or “Needs Administrative Review”.
Pending RFP Ideas flagged for Administrative Review must be reviewed by the Council and sub-categorized as “Not Planned,” “Return for Clarification,” “Return for Reconstruction,” or “Approved”.
Phase 2: RFP Draft
Once the seven-day feedback cycle has concluded, the RFP Idea will be archived. Pursuant to approval, a moderator will provide the eligible RFP Author with the appropriate template to submit to the DAO Intake Administrator as a formal Snapshot proposal.
A proposal typically includes:
Abstract - Two or three sentences that summarize the proposal.
Motivation - A statement on why the Radiant Community should implement the proposal.
Rationale - An explanation of how the proposal aligns with the Radiant Community’s mission and guiding values.
Key Terms (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the Radiant Community, and/or industry-specific.
Specifications - A detailed breakdown of the platforms and technologies that will be used.
Steps to Implement - The steps to implement the proposal, including associated costs, manpower, any legal documentation (if applicable) and other resources for each step where applicable.
Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.
Overall Cost - The total cost to implement the proposal.
The Author will fill out the template based on the original RFP Idea, incorporating any feedback provided by the community that helps the idea better serve the DAO, including, but not limited to, lack of specificity in the proposal.
The Author can add additional fields to the template if necessary to fully communicate the intentions, specifics, and implications of the RFP Draft.
Proposals that did not make it through the initial Snapshot governance process and are being resubmitted should also include:
Link to original proposal
Reason it was not approved
Changes that have been made and why it should now be approved
Category Options
Core: Ecosystem Fund Allocation
Core: Ecosystem Fund Allocation (Resubmission)
Core: Brand Decision
Core: Brand Decision (Resubmission)
Core: Principles Core: Principles (Resubmission)
Process
Process (Resubmission)
Informational
Informational (Resubmission)
The Intake Administrator may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made—in order for the RFP Draft to comply with the DAO-approved guidelines and move to the next step.
If the Author does not respond to a moderator’s request to change, update, or make clarifications on the RFP Draft within seven (7) days, the RFP Draft will be automatically rejected as having failed to comply with the DAO-approved guidelines.
When the Intake Administrator confirms that an RFP Draft complies with the DAO-approved guidelines, they assign a number to the RFP for identification purposes throughout the rest of the process. From this point on, the RFP is referred to as “RFP-#: (Name) - (Category)”.
For example, the inaugural RFP set forth to propose this governance structure is titled “RFP-1: DAO Proposal - Process”.
Phase 3: RFP Moderation
The RFP is reviewed by the Intake Administrator, and will either be approved or not approved based on whether it adheres to the DAO-approved guidelines.
If an RFP is approved as complying with DAO-approved guidelines, it becomes a Pending RFP.
If an RFP fails to comply with DAO-approved guidelines, it is eligible for resubmission unless in cases of violation of the law or reasonable suspicion of fraud or other misleading information.
Phase 4: Post-Moderation Tagging
Pending RFPs that have passed RFP Moderation will then either be tagged as “Approved to Vote” or “Needs Administrative Review” as each term is defined and described in this Proposal.
The “Approved to Vote” tag is given for any pending RFP whose costs, content, and implications are considered to be straightforward and of no risk to the well-being of the DAO.
The “Needs Administrative Review” tag is given for any pending RFP whose costs, content, or implications are considered to be complicated or a potential risk to the well-being of the DAO. Any Pending RFP that is tagged as “Needs Administrative Review” must go through Phase 5.
Phase 5: Administrative Review
This phase is only for Pending RFPs that have been tagged with “Needs Administrative Review.”
When an RFP is tagged for review, the Council, serving in an administrative capacity, will determine whether further action is required prior to a Pending RFP proceeding to Phase 6.
Pending RFPs that the Council determines do not require additional action will be tagged as “Approved to Vote” and proceed to Phase 6.
If the Council decides to return a Pending RFP for further clarification or action, they must provide a clear explanation of why and tag it as either “Return for Reconstruction” or “Return for Clarification.”
Reasons to tag as “Return for Reconstruction” or “Return for Clarification” may include but are not limited to:
Cost to implement unclear/not able to be calculated (tagged as “Return for Clarification”)
Proposes to use more than 5% of the Ecosystem Fund (tagged as “Return for Clarification”)
Conflicts with another proposal (tagged as “Return for Clarification”)
Proposal is at odds with the mission/values of the DAO (tagged as “Return for Reconstruction”)
Proposal is at odds with the well-being of the DAO (tagged as “Return for Reconstruction”)
Violations of law, or against advice of counsel for the Foundation (tagged as “Return for Reconstruction”)
Reasonable suspicion of fraud or other misleading information (tagged as “Return for Reconstruction”)
Phase 6: Live RFP
Drafts that have passed their respective approval processes will become a Live RFP on Snapshot (dao.radiant.capital) during the next Weekly RFP Release, which is when new RFPs are released in batches every Thursday at 9PM ET.
Administrators are the only ones that can post RFPs to Snapshot because they must ensure that each one has gone through the correct approvals process.
All RFPs released to vote will undergo a 24hr delayed “warm-up phase,” in which the RFP is submitted to Snapshot for public view, but is not yet committed to the blockchain or eligible for voting. This affords the Author, Council and/or Admin a supervisory window to correct any errata before the proposal details are rendered immutable. The warm-up phase only provisions for typographical or numerical errors and not for significant changes to the RFP content itself.
Once live on Snapshot, Live RFPs are open to voting until Weekly Voting Close, which is when all Live RFPs from a given batch close for voting at approximately 9PM ET on the Wednesday following their release.
The voting options are “In favor,” “Against,” and “Abstain.” Voting “In favor” means the voter is in favor of implementing the RFP exactly as-is. Voting “Against” means the vote is against implementing the RFP exactly as-is — voters may vote “Against” to encourage the Author to resubmit the RFP after making changes. Voting “Abstain” means the votes are counted towards quorum but are neither “In Favor” or “Against” of implementing the RFP.
The quorum requirement for a Live RFP will be 10% of the circulating supply of locked RDNT. Once quorum has been met, a Live RFP may only be passed with greater than 50% of votes cast “In favor”. A Live RFP which has not received greater than 50% of votes cast “In favor” will not be passed. A Live RFP which has met quorum and achieved greater than 50% of votes cast “In favor” will be deemed an Accepted Final RFP.
Phase 7: Final RFP
If by the Vote Close Time the Live RFP has not received any votes or is tied, it will be tagged as “Stalled” and be eligible for Resubmission. In all other cases, after the Vote Close Time, Live RFPs are moved to Final RFPs.
There are two subcategories for the Final RFP status: accepted and rejected. Rejected Final RFPs will have the chance to be resubmitted via the appropriate Resubmission Template if the Author contacts a moderator to initiate this process. Accepted Final RFPs will move into implementation.
Last updated