Abracadabra Governance Process 
:
Abracadabra.money is a thriving protocol which, continues to change over time, details of this document may change accordingly.
At the current moment, governance is set up as a multi-step system to engage the community so that we can come together on a decision regarding a specific subject and put it into action.
It is important to understand that certain structures need to be respected so that a proposal is clear, concise, and unambiguous. This will maximize our efficiency as a community and bring our protocol forward.
Below you can find an outline of the initial governance framework. Note that this is a living document and details are subject to change.
Table of Contents
- I. Overview
- II. Governance Process
- Raise a discussion
- Post a Request for Comment [RFC]
- Summarize the RFC
- Post an Abracadabra Improvement Proposal [AIP]
- Start a Snapshot Vote for the AIP
- Process Results
- III. Templates
I. Overview:
Governance is responsible for proposals to be created and processed. Proposals aim to change something in the protocol such as adding new cauldrons and collaterals, requesting a replenish of already existing cauldrons or requesting changes to the protocol itself. They typically originate from a discussion in the 
Idea Discussion Section of our forum and they then evolve into a [Request For Comment] Thread, which are posted in the homonym category and discussed.
The purpose of the Request for Comment (RFC ) thread is to mature an idea into a proposal. It’s where the community works out or rejects a certain topic. If a proposal is worthy to be formally voted on, it transitions into an Abracadabra Improvement Proposal (AIP).
We are taking every RFC / AIP seriously, so we recommend to chat with community members informally on Discord or post your suggestions in the Idea Discussion category first and start a productive discussion about a subject to gather enough traction, then consider posting it as an RFC. Remember that one of our mods/core contributors will need to approve both your RFC and your AIP.
At the end, if you feel that your idea or proposal is worthy of the community’s attention, feel free to post it in the RFC section or in some cases, when the proposal is well defined, clear and unambiguous, directly as an AIP.
In all cases the AIP and RFC both follow a detailed pre-defined layout.
II. Governance Process:
- Raise a discussion
A great place to start a discussion is our Discord Channel where you can informally ask community members their opinions and brainstorm ideas. To create a more static conversation, feel free to post in the Idea Discussion Forum. When you are confident that the discussed topic is relevant to the community and project, you can start a [RFC] thread and contact one of our mods. They will move your idea to the RFC category.
- Posting a [Request For Comment] thread
Requests for Comment (RFC) is the first step towards creating a proposal. While the RFC needs to follow a pre-defined layout, it is not necessary to be fully completed in the beginning, it can evolve into a full proposal. That is the goal of the RFC, to gather attention to a certain subject and amend the RFC towards a full proposal.
When you feel confident that your idea deserves an RFC, submit it in the RFC section of our forum. One of our mods will review the post and then approve it if it sticks with our template. Make sure to follow the layout.
Once the RFC is posted, make sure to actively participate in the discussion, answer questions around your concept, be open to suggestions and use the community to improve your idea. Consider that some topics require more thought and research than others.
Give the community time to comment and grasp your idea. Keeping a discussion around an RFC up for several days before creating the AIP, assures that the community has a clear understanding of the proposal, and the sentiment can be evaluated.
- Summarize the RFC
An important part of the RFC is the ever-changing nature of the original post. Summarizing the discussions when appropriate will help community members better understand where the discussion is heading and the recent adjustments that have been made. It’s a great way to reflect on whether the RFC is ready to be published as an AIP or the community needs to work out more details. The original poster or someone who has been involved in the discussion may summarize the findings in the RFC thread and decide if the proposal needs to be reworked or it can be pushed towards an AIP.
Matured RFC
RFC’s may be accepted if they receive enough support from the community. It means that a topic has went through in-depth discussions to address concerns as well as uncertainties and a large part of the community accepts the idea fundamentally.
Once accepted, the appropriate AIP can be posted in the Governance Proposal Category.
- Posting an Abracadabra Improvement Proposal (AIP)
While it is recommended to start a Proposal as an RFC, it does not always have to be like that. It really depends on the subject of the Proposal and if standards or rules have already been set.
In most cases, an accepted RFC is needed before an AIP can be launched. When an AIP is launched it is important to link back to their supporting RFC, for ease of reference.
Once you are confident to release an AIP, post it under the Governance Proposals category and a moderator will be reviewing the thread, making sure it follows the correct format. Another option is that one of our mods will simply move your RFC in the AIP section.
- Start a Snapshot Vote for the AIP
To give the community enough time to research and discuss the AIP, it should be up for at least 4 days, before an official Snapshot Vote can be submitted.
A snapshot vote does not always need to be posted by the original AIP author, it can be posted by someone else or by the core team in case the minimum threshold of sSPELL is not being met.
When starting a Snapshot, it is important to set the duration to at least 3 days to give the community enough time to cast their vote.
A Snapshot should always have the link to the AIP attached. The parameters of the poll (Yes, No, different options for values) need to mirror the options discussed in the AIP.
- Process Results
If an AIP has passed through the Snapshot Vote, our core contributors will tend to implement it in a timely fashion.
III. Templates:
Request For Comment [RFC] Template
A Request For Comment [RFC] is the second step towards creating a proposal. Before creating an RFC, make sure to discuss your idea with fellow members on both Discord and the Forum. Once an idea is clear, and has passed this initial inception phase, an RFC can be created. Remember that RFCs are fluid by nature, and can be changed multiple times following community inputs.
RFCs are posted into the RFC Section of our Forum with a [RFC] tag and need to respect the following template. Remember that RFCs are living documents, not all of these points need to be nailed right from the beginning, but can be added over time as the RFC matures towards an AIP.
Name: Give your RFC a title that clearly summarizes the main idea. Every RFC will be numbered by one of our core contributors, so that it will be easier for other members of the community to refer to.
I.e: [RFC #0] Adding an xJOE cauldron to Abracadabra Lending Markets.
Summary/Scope: Summarize at the best of your abilities the content of the proposal in a few lines, giving a TLDR is good practice and extremely useful for the rest of the users.
Link to previous [DAO Discussion]: if your RFC was born from a discussion on the forum, make sure to attach it here.
Reference: Provide links and resources for the collateral (or the implementation) you are proposing in this part of the RCF. Reference must include, but are not limited to:
-
Project website
-
Documentation and Wiki
-
Source code for the system(s) that interact with the proposed asset (Github)
-
Audits both procedural and smart contract focused
-
Provide Market and Usage data on the proposed collateral.
-
Communities and socials
As a rule of thumb, the more info you can produce about a project, the easier it will be for community members to educate themselves on it before deciding.
Main Objective: This is the part where you can deep dive into the details of your idea. Explain what your intentions are, why do you think it would be beneficial for the protocol, and what would be required for it to be realized. Feel free to structure this section as you prefer, adding any subsections you think might help better communicate your idea (Motivation, Drawbacks, Risk analysis…) we recommend to divide it in at least a High Level Overview and a Low Level Details description.
In the case of a new collateral proposal, make sure to add a background of the collateral you would like to see added. On a technical point of view, specify what would be required from our developers (i.e if a wrapping contract is required or any other tool).
State any concerns coming from the community here, and address them with feasible and sustainable solutions. Cauldrons are Abracadabra’s main product, and there is a high demand for adding new. As the priority is the security and stability of the protocol, we need to pick only the ones that would be most beneficial, so make sure to explain why and how the Abracadabra user should vote to add your proposed collateral.
While populating this section, if you are proposing a new collateral, try to reply to the following questions:
- What is your relation with the team of the proposed collateral? Are you a team member or a user?
- Cauldrons are Abracadabra’s main product, and there is a high demand for accepting new collateral. As the priority is the security and stability of the protocol, we need to pick only the ones that would be most beneficial. What benefits to our ecosystem will adding the proposed collateral bring?
- What are the main risks of adding your proposed collateral?
- How are those risks mitigated?
Reference to previous RFCs if you want to see some good examples on how to structure this section.
Contracts/Technical Requirements: For [RFC] based on adding new collaterals, provide any relevant token contract and chainlink oracle address the core contributors will need to implement your proposal. In addition to this, add also any official staking contract available for your proposed collateral as well as the most liquid market to allow us to deploy leverage if needed. Specify the chain on where the CDP will be deployed.
Next Steps: State what are the next steps for your RFC. Usually a core contributor will populate this section.
Feel free to discuss with our core contributors and mods, as well as your fellow community members on how to improve this proposal. As mentioned before, don’t hesitate to change your [RFC] if you have a better idea sparked by the discussion. Make sure not to rush it, and address any major concern by the community before finalising your RFC proposal.
Remember that only the most recent version of an RFC will be considered, so make sure that all the past edits are reflected in the final version.
Abracadabra Improvement Proposals [AIP] Template
Abracadabra Improvement Proposals [AIPs] are the final document that will be used as a reference in order to vote on your proposal on Snapshot.
As mentioned before, the main goal is to turn RFC into AIP only when they are completely mature. In this scenario, no more changes are needed to your document, and it can be posted by one of our core contributors in the adequate “Governance Proposals” section of our forum. Practically, our mods will probably need to change the organization, maybe adding your tl;dr and editing the “Next Steps” section. They will not alter the content of the proposal itself.
Needles to say, your nickname and the one of all the contributors who shaped the [AIP] will be included. Similar to [RFC], a number will be assigned to the [AIP] to easily allow community members and voters to keep track of it.
After this, at least 3 days (exception for time sensitive proposals) will be needed before starting the actual snapshot vote, to allow every wizard to educate themselves on the [AIP]. Once the discussion has reached an end, one of our core contributors will start the snapshot vote. You can read more about how the voting process on snapshot is organized here.
A snapshot vote will always have the link to the proposal attached, a summary of the proposal (tl;dr) and the voting options (Yes, No, and any other needed option).
As a voter, remember that voting happens only on Ethereum currently, and that it does not cost gas fees. Your voting power is given by the amount of sSPELL tokens held in your wallet.