AIP 27: Governance Framework Update
The current proposal is an update to the existing governance framework that implements community feedback and overall improvements collected from more than 2 years of Abracadabra Money DAO operations.
The following proposal rewrites some parts of the current governance framework but also adds new paragraphs and templates to maximize the DAO efficiency while maintaining its decentralization and freedom to operate.
AIP 27: New Framework 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
- Voting and Process Results
III. Templates
- Request For Comment [RFC] Template
- Abracadabra Improvement Proposals [AIP] Template
- Speedlane AIP Proposal [SAIP] Template
IV. Governance Framework Updates
I. Overview:
Governance is responsible for proposals to be created and processed, governing every part of the Abracadabra Money DAO. Proposals aim to change something in the protocol such as adding new cauldrons and collaterals, requesting a replenishment 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 then evolve into a [RFC] Requests For Comment Thread, which are posted and discussed in the RFC section of the forum.
The purpose of the Request for Comment (RFC) thread is to mature an idea into a proposal. It is 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 General Proposals .
The DAO takes every RFC / AIP seriously, so we recommend chatting with other community members informally on Discord or posting your suggestions in the Idea Discussion category first to start a productive discussion and to gather enough traction before posting it as an RFC. Remember that one of our mods/core contributors will need to approve both your RFC and your AIP in order for it to appear on the forum. This helps us avoid spam and keep the forum organized and structured. If your proposal is not yet visible on the forum, reach out to one of our Contributors or Moderators to make it visible!
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.
It is important to know that any part of the Abracadabra Money protocol are ruled by the DAO. For example, any newly minted SPELL, or MIM top ups cannot be executed without an appropriate Governance DAO vote.
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.
Post a [RFC] Requests 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 make it visible 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 gone 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.
Post an Abracadabra Improvement Proposal (AIP) General Proposals
While it is strongly recommended to start a Proposal as an RFC, it is not a strict requirement. It really depends on the subject of the Proposal, if standards or rules have already been set, as well as the time sensitive nature of a proposal.
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 its supporting RFC (if it exists), for ease of reference.
Once you are confident releasing an AIP, post it under the Governance Proposals category and a moderator will review the thread, making sure it follows the correct format. Alternatively, one of our mods may simply move your RFC to 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 SPELL voting power 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.
In some cases, an AIP is already detailed enough to provide the timelines of future snapshots votes related to that given AIP. An example can be found here with AIP 26. In this case, the proposal already outlines how further amendments to the beaming fee will be voted (i.e. with 24 hour snapshot periods, rather than 72 hours ones). If one of your proposals requires flexibility and further DAO votes changes, it is highly recommended to specify how long further votes should be.
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.
Voting and Process Results
Voting is held on Snapshot and an Address voting power is decided by the balance of sSPELL, mSPELL or ETH/SPELL LP tokens held in the wallet at the time of posting of the vote. Casted votes can be changed multiple times until voting is live.
If an AIP has passed through the Snapshot Vote, our core contributors will implement it in a timely fashion.
In order for a vote to pass, it needs to reach a quorum where it meets or exceeds 3 Billion SPELL voting power, and must have a governance forum post attached to it. Further Amendments to the current Quorum can be proposed to the Forum, and get voted on by the DAO, in order to be put in place.
Once a proposal is voted on Snapshot, it can be moved to our “Voted Proposal” Forum Section.
Votes that do not meet the template, do not meet the quorum, or both, will not be considered valid by the DAO.
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.
Once an RFC has been finalised, and it is mature enough, it can be turned into an Abracadabra Improvement Proposal (AIP).
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 and Speedlane Proposals) will be needed before starting the actual snapshot vote, to allow every DAO Member to educate themselves on the [AIP].
Once the discussion has reached an end, the proposal can be posted on snapshot. If you do not have enough SPELL voting power to post the proposal, one of our core contributors will start the snapshot vote for you. 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). Quorum must be reached for the proposal to be considered valid.
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 balance of sSPELL, mSPELL and ETH/SPELL LP tokens held in your wallet.
Speedlane AIP Proposal [SAIP] Template
As a Lending Protocol that is built on top of different and volatile collaterals, the Abracadabra Money DAO sometimes needs to take time-sensitive decisions.
In such cases, it might not be possible to fully adhere to the time constraints highlighted in both the RFC and AIP templates, as well as the 72 hours voting period required on snapshot.
In such cases, a Speedlane Proposal can be initiated, and posted directly in the AIP part of our forum. Similarly, Speedlane Proposals snapshot voting can be initiated 3 hours after the posting on the forum. No discussion period is strictly required, despite being highly encouraged.
SPELL holders can use the Snapshot Voting period to educate themselves on the proposal and vote accordingly.
Speedlane Proposals need to have in their text a clear explanation of why the proposal needs to be speedlaned, why the situation is time sensitive and why it requires immediate actions from the DAO.
Additionally to this, Speedlane Proposals must adhere to the normal AIP template when it comes to contents and consistency. The standard snapshot voting rules still apply, where quorum and simply majority must be met for the proposal to pass.
IV. Governance Framework Updates
As any other part of the Abracadabra Money DAO Operations, the Governance Framework can be subjected to changes and improvements if voted on by SPELL holders.
If the current governance framework wants to be changed, an AIP must be posted on the forum using the following templates AIP #26.X: Governance Framework Update (where X is a progressive number based on the previous updates). Voting for new frameworks must adhere to the previous approved framework templates and rules.
It is recommended to therefore batch Governance Framework updates in large documents that can be properly discussed by the community before being implemented.
AIP 27: Voting
The following proposal will remain as an AIP for 4 days and will then be moved to snapshot voting. Snapshot voting will be lasting 72 hours and have 2 options:
- Yes, Update the Framework
- No, Maintain the old Framework
If the yes option was to pass, the new framework will be implemented and pinned on the forum to allow new members and old to educate themselves on it. Further proposals will need to adhere to the new framework.
Snapshot voting is now live here.
The proposal has passed with absolute majority.
awesome AIP Romy!!!