Prisma Governance Forum Rules and Processes

This forum is dedicated to discussions on Prisma governance. Relevant topics include:

  • Governance Proposals
  • Proposal Discussions
  • Delegation Pitches

This is not the place for:

  • PRISMA and mkUSD price discussions
  • Generic Prisma discussions
  • Prisma support requests
  • Off-topic conversations

If you need technical help, or want a place for more general discussions, we would like to invite you to our official Prisma Discord.

If your signal-to-noise ratio gets too low, you will be banned. Moderators will remove posts that are offensive and otherwise irrelevant to this forum.


Welcome to the official Prisma Governance Forum!

Below we have provided a template on how to structure your Prisma proposals to offer a more comprehensive & efficient deliberation process. The following rules and processes are separate from the collateral onboarding procedure, please use this post as a primer on the Prisma collateral onboarding process.

This framework provides comprehensive guidelines for the Prisma DAO community when creating and voting on PRFC (Prisma Request for Comment) and Temperature Check proposals. It includes a template for creating a proposal and outlines the quorum and voting requirements.

Distinction between PRFC and Temperature Check
Temperature Check proposals serve to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high-level of precision or technicality.

Conversely, PRFCs are precursors to Prisma Improvement Proposals (PIPs). Relevant service providers are formally invited to provide feedback on them and the specification section of the PRFCs should detail how the potential upcoming PIP will impact Prisma protocol smart contracts.

PIP numbers will be assigned to proposals by admins at the time of snapshot creation. The title of newly created proposals should not include a PIP number in the title of PRFC forum posts.

Proposal Structure

  • Title: A concise and descriptive title for the proposal, including the proposal type in a [TAG] format.

  • Author: The name of the author and/or entity creating the proposal.

  • Date: The date the proposal is being made, in the DD-MM-YYYY format.

Body Paragraphs:

  • Summary: A succinct summary of the proposal; no more than 2-3 sentences.

  • Abstract: Introduce and expand on the proposal. Highlight key points on how the proposal will improve stakeholder/tokenholder experience, protocol performance, and the overall implementation process.

  • Motivation: What problems will this proposal address/solve? What’s the value-add? This section can have sub-sections for improved readability.

  • Specification: A comprehensive description of the proposed change, including any relevant parameters or risk considerations. For request for comment proposals, this section should be technical, detailing the specific changes to be made. This section can have sub-sections for improved readability.

  • Benefits (Pros): Provide benefits as to how the proposal implementation will advance the protocol.

  • Downside (Cons): Are there any disadvantages to implementing the proposal?

  • Voting: Define what a “yes” and “no” vote entails. If there are any Snapshot votes or forum polls associated with this proposal, please attach them.

Governance Process

For the sake of transparency, accountability, and consensus we would like to structure a cohesive flow that will assist with the transmission of governance proposals, temperature & consensus checks, and high-traction proposals.

Please, provide TLDR update on the top of your proposal so it is more easily accessible.

Here is a quick outline om how the Prisma governance process works:

Phase 1: Request for Comment (RFC)

Timeframe: Minimum 1 day

Form: Governance Forum Post

The first phase of the governance process is meant to allow the community to digest a proposal, comment, and ask questions about a particular proposal.

To post a RFC, label your post “RFC - [Your Title Here]”. Prior to moving ot Phase 2, give the community at least 2 days to read and comment on the RFC. Please respond to questions in the comments, and take feedback into account in the next iteration of the proposal posted in Phase 2.

Phase 2: Temperature Check

Timeframe: 3 days

Quorum: 30%

Form: Snapshot Poll

The purpose of the Temperature Check is to signal community sentiment on a proposal prior to moving towards an on-chain vote.

To create a Temperature Check:

  1. Incorporate the community feedback from the RFC phase into the proposal.
  2. Create and post this version of the proposal in the Governance Forum with the title “Temperature Check — [Your Title Here]”. Include a link to the RFC post. You will update the post to include a link to the Snapshot poll after you’ve posted that.
  3. Create a Snapshot poll. The voting options should consist of those which have gained support in the RFC Phase. This poll can be either binary or multiple choice but must include a “No change” option. Set the poll duration to 3 days. Include a link to the Forum Temperature Check post.
  4. Update the Forum post with a link to the Snapshot Poll.

At the end of 3 days, the option with the majority of votes wins. 30% of the total vote weight must vote yes to move onto Phase 3. If the “No change” option wins, the proposal will not move onto Phase 3.

Phase 3: Governance Proposal

Timeframe: 7 days, or until 30% quorum is reached; 24h timelock before vote is enacted

Threshold: 1% of the total vote weight

Form: Governance Proposal

Phase 3 is the final step of the governance process. If this vote passes, then a change will be enacted on-chain.

To create an on-chain Governance Proposal:

  1. Incorporate any last iterations to your proposal based on feedback prior to posting.
  2. Create a topic in the Governance Forum titled “Governance Proposal — [Your Title Here]” and link to previous forum posts and the Temperature Check Snapshot poll.
  3. Create your proposal. This can done through an interface on Prisma or through writing the calldata for more complicated proposal logic. This calldata will be executed if and when the proposal passes. If writing the calldata yourself, please review the logic with a qualified Prisma community member prior to posting the proposal.
  4. Ensure that you have at least 1% of the total vote weight on your address in order to submit a proposal.
  5. Once the proposal has been submitted, voting will start immediately. A 7-day voting period begins after the proposal has been submitted. Users who are in favor of the vote can allocate their lock weight toward the proposal. A vote passes once the weight signaling in support exceeds a 30% quorum. There is no concept of a “no” vote, users who are not in favor should abstain from voting.
    24 hours after a vote has passed quorum, the payload can be executed by anyone. The 24 hour delay serves as protection from malicious votes.