Prisma Governance Collateral Onboarding Processes

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

Asset onboarding proposal structure
Each proposal Must include the following:

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

References:

  • Name of the project
  • Whitepaper
  • Documentation
  • Source code for the system(s) that interact with the proposed asset
  • Ethereum addresses contracts
  • List of Oracle data sources
  • Audits both procedural and smart contract-focused
  • Communities

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.

Additional questions for collateral onboarding:

  • Explain the positioning of the asset in the Prisma ecosystem. Why would it be a good collateral asset?
  • Provide a brief history of the project and the different components: DAO (is it live?), products (are they live?). How did it overcome some of the challenges it faced?
  • How is the asset currently used?
  • Token (& Protocol) permissions (minting) and upgradability. Is there a multisig? What can it do? Who are the signers?
  • Market data (Market Cap, 24h Volume, Volatility, Exchanges, Maturity)
  • Social channels data (Size of communities, activity on Github)
  • Contracts date of deployments, number of transactions, number of holders for tokens
  • List any possible oracle data sources for the proposed Collateral type.
  • (Optional) List any parties interested in taking part in liquidations for the proposed Collateral type.

Asset Onboarding 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: Prisma Request for Comment (PRFC)

Timeframe: Minimum 1 day

Form: Governance Forum Post

The Prisma Protocol can support many different LSTs as collateral. Each collateral operates as a segregated risk pool, with the addition of each new asset influencing the overall risk of the protocol.

For each new asset to be added as collateral on Prisma, the proposal and subsequent discussion should cover:

  • Increased insolvency risk of the onboarded collateral
  • The potential to expose Prisma to a single point of failure.
  • The risks associated with collateral
  • The benefits of protocol/asset diversification

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. In addition to the regular PRFC process, a risk analysis performed by Prisma’s independent risk team @PrismaRisk is needed to understand the underlying risks and assess risk parameters for integration, which the community will review and on which the community can comment.

In parallel, a smart contract review is needed to understand the code and how it fits within Prisma’s architecture.

Following the Risk Analysis it is important to share with the Prisma community what risk parameters and interest rate curves are considered.

To post a PRFC, label your post “PRFC - [Your Title Here]”. Prior to moving to 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:

Incorporate the community feedback from the PRFC phase into the proposal.

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 PRFC post. You will update the post to include a link to the Snapshot poll after you’ve posted that.

Create a Snapshot poll. The voting options should consist of those which have gained support in the PRFC 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.

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:

Incorporate any last iterations to your proposal based on feedback prior to posting.

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.

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.

Ensure that you have at least 1% of the total vote weight on your address in order to submit a proposal.

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.

1 Like