Welcome to Conic Discourse
Beep boop, beep bop. Welcome to the first Conic Discourse topic. The Conic Discourse is an imperative part of the Conic vision and protocol development. The discussions held here by the community will carve the path of Conic’s Omnipool future. If you’re new here, get caught up on Conic Discourse and read the FAQ (FAQ - Conic Finance)
The Conic Governance Model
Conic governance can be broken into two separate categories: Omnipool liquidity allocations and Conic improvement proposals (CIP). The Conic team will always act in the best interest of the long term sustainability and efficiency of the protocol and therefore has established stricter parameters on the governing model for Omnipool liquidity allocations.
CNC holders can directly control liquidity on Curve through Omnipool liquidity allocations. These are subject to a bi-weekly vote that determines how liquidity is allocated (the allocation weight of each Curve pool).
The vote will take place every other Thursday on Snapshot.
To prevent malicious liquidity allocations, emergency multi-sig signers can always veto proposed allocations from the bi-weekly vote.
The framework for Conic Omnipool liquidity allocation is out of scope for this Discourse topic.
General proposals
We propose that general governance proposals shall follow a more optimistic model, of which is defined by the following parameters:
A 48 hour voting period for all proposals
A required balance of 10,000 vlCNC to make a proposal
The emergency multi-sig is able to veto any updates to the protocol
Quorum of 200,000 vlCNC for snapshot votes to pass
This model will assist in Conic governance reaching quorum while optimizing for community consensus and conscientious decision making. At this time, the framework for general proposals has yet to be finalized. If you have any thoughts on this proposed framework or suggestions for improvements, please share below. A finalized outline of the Conic governance model will be added to the Conic docs in the coming future.
(2) I don’t think any deadline should be needed. If using a tool like Snapshot, it would just be based on the current vlCNC balance of the voting user.
The emergency multi-sig will essentially be able to veto any parameter updates. For example, the DAO could introduce a fee to be charged on CVX and CRV rewards. Another example would be the whitelisting of Curve pools to be eligible to be part of an Omnipool. All these “updates” could get vetoed.
The 5% veto threshold has been removed. It really shouldn’t have been included and would have added redundancy to Conic governance. All vetoing will be done through the emergency multi-sig.
If you have a different suggestion for quorum, please share.
IMO, a fixed number like 200,000 seems too rigid and would require frequent tuning, especially if the amount of vICNC goes up over time. What about setting quorum as a percentage of the total vICNC at the start time of the snapshot?
I think the scope of the veto multi-sig is quite wide and can potentially be controversial. For example, vICNC holders votes in favour whitelisting a UST pool, while the multi-sig takes the opinion that it should not do so in the interests of user safety. Giving the multi-sig such a wide mandate may therefore potentially cast a shadow over the value of vICNC in governance.
Perhaps the scope of parameter updates subject to the veto multi-sig can be described in more detail, with a few illustrative examples. In relation to the whitelisting of Curve pools, we may want to consider a more nuanced approach like Lido’s proposed dual governance. Specifically, allowing users with stablecoins deposited in Conic to have a veto instead of the multi-sig. In the above example, I would argue that depositors are the better and most-incentivised party to decide on the safety of the pools and any resulting veto from this group would also be more palatable. IMO, the more well-defined and restricted the parameter updates subject to the veto multi-sig are, the greater the value of CNC as a governance token.
This is a fair point, a static 200,000 vlCNC is rather simplistic. Like you suggested, a % of the total vlCNC at time of snapshot could be more reasonable and allow Conic governance to more efficiently reach scale.
I think some of your points here are valid. However, part of the Conic vision is to help scale Curve. The emergency multi-sig signers were carefully selected and are core members of the Curve community. Their actions as Conic veto multi-sig signers should be well within the best interests of the Conic and Curve community. Additionally, some of your points on dual governance, or LP voting power, have been addressed here: V2 Locker Proposal
Who implements the parameter changes? Voting takes place on Snapshot and the way I understand the system it doesn’t directly affect the current smart contract or does it?
e.g : The Dao votes to change the platform fee from 1% (not a real number) to 0.5%. How would this happen in practice? I mean, one of the devs would have to modify the parameter wouldn’t he?
You’re right, snapshot votes do not directly affect the smart contract. The admin of the contracts is the Conic Multisig, and so once a vote passed it would be executed by the Conic Multisig as per the result of the governance vote.
Later down the line we could look to transition to fully on chain governance, where votes will directly update the contracts. But this will not be in place for launch.
Thank you for the clarification.
May I offer some suggestions I had in mind?
The general proposal right now is that someone with 10k vlCNC can launch a proposal on Snapshot which in itself is a good thing.
However rarely any proposal is perfect from the beginning and pretty much always subject to discussions from the community. Or at least it should be.
So, to prevent unnecessary cluttering and confusion on Snapshot I suggest that any proposal must at least be published 24-36h prior to the launch on Snapshot.
That way any logical fallacies or even worse, straight-up disagreements from the Multi-sig, can be prevented by giving everyone the possibility to voice his concerns beforehand.
A consensus doesn’t need to be reached prior to the vote but at least a fair warning is given to the person/entity launching the proposal that votes might not turn in his favor.
It might seem a bit redundant given that the emergency sig can veto anything but it is a healthy habit to first lay out a proposal before it is put up to a vote, especially once voting has a direct effect on the smart contract.
It also allows the emergency multi-sig to give prior notice of their intentions and concerns instead of letting a vote on a proposal happen and then suddenly jump in to veto it. This lets the governance process keep its value and there won’t be any “bad surprises” and community complaints.
Of course, no one can prevent a person or project with 10k CNC to bypass all of this but, and I say this after re-reading the Mochi-debacle, with such a rule in place you have the moral highground. Shady proposals can be shut down instantly (figuratively) just by telling them they didn’t respect the procedure by bypassing the pre-voting phase.
This suggestion ensures a better PR (optics matter), gives everyone a fair chance to voice his opinion, ensures you have the moral high-ground in case of an emergency shutdown and avoids clutter and confusion on Snapshot.
I agree with this point. Similar to how on gov.curve.fi you have a template in the “Proposals” category for new posts, it could be very beneficial to Conic governance to employ a similar structure/approach.