Enhancing Governance for Omnipools

Introduction: In recent discussions within our Discord community, there has been growing awareness of the need to refine governance rules for Omnipools. As we strive for transparency, clarity, and effective decision-making, it’s essential to address several critical aspects.

  1. Minimum TVL Volume for Pools:
  • Background: The current documentation outlines that any pool “Must Have” a Total Value Locked (TVL) of 10 million to be added to an Omnipool. However, the core team views this as a guideline rather than a strict requirement.
  • Importance: To avoid ambiguity and potential disputes, we propose a DAO vote to establish a specific TVL threshold. This decision will provide clarity for both the community and prospective pool additions in the future.
  • Action: After the DAO vote, we will update the documentation to reflect the agreed-upon TVL level.
  1. Coin Ratio Acceptance:
  • Context: In heavily skewed pools, slippage and pricing loss can occur. Therefore, we should define acceptable ratios for coins within a pool.
  • Proposal: Should we accept 60/40, 70/30, 80/20, or 90/10 pools? This decision impacts pool stability and user experience/loss potential.
  • Dynamic Balance: Additionally, we need to address situations where a pool becomes unbalanced over time. How should we handle deviations from the accepted max ratio?
  • Community Input: We encourage community members to share their suggestions and reasoning regarding these ratios.
  1. Core Team Decisions:
  • Issue: Can the core team unilaterally bypass the TVL and coin ratio guidelines without a DAO vote?
  • Transparency: We believe that significant decisions should involve the community. If exceptions are necessary, we should discuss and document them openly.
  • DAO Oversight: Let’s clarify the process for core team decisions and ensure alignment with community interests.
  1. Core Team Voting Quorum:
  • Scenario: There’s a concern that the core team could potentially influence voting outcomes by having their own voting quorum.
  • Transparency and Fairness: To maintain transparency and prevent undue influence, we should establish clear guidelines regarding the core team’s voting power.
  • Community Oversight: Consider mechanisms to ensure that core team decisions align with the broader community’s interests.
  • DAO Consensus: Ultimately, decisions should reflect the collective wisdom of the DAO, not just a select few.

Feel free to engage in further discussions, propose additional points, or share your insights. Together, we can strengthen our governance framework and foster a more robust ecosystem! :blush::star2:

1 Like

Thank you for sharing this well-written feedback. It would be great to hear the thoughts from more community members on the points mentioned.

1 Like

Thank you blanco. I am not as specialist as you are but will provide feedbacks

  1. Your concern is about having initial price within liquidity pool being wrong and let conic depositors to be arbitrated ?
  2. I would rather prefer a warning and estimation of slippage if that is not too costly. Is the ‘a’ always equal in the pools targeted by Conic ?
  3. Every system has its own limits. Reflexer stablecoin died because core team refused to change the initial idea (collatelarise RAI by ETH and not by stETH - cause staking arrived after the initial implementation). Some devs threatened to leave then. In their case, they were ungoverned, no DAO. So I think that any bypass should be subject to DAO governance. If the intent is economic and benefitial without hidden agenda, everyone should be aligned or able to be convinced. If not then eventually the project dies and everyone looses.
  4. Agree. One wallet one vote rule, weighted by lock time + total lock time since inception, to be applied as long as there are sufficient number of voters and no link between wallets. It would give founders still more weight, but in a non totally decisive way.

1. Regarding deposit thresholds for pools, I offer the following insights:

1.1 Mainnet Considerations:

  • For mainnet pools, I recommend setting a minimum deposit threshold of 5 million. Below this level, deposits may be at risk due to potential sudden withdrawals by a small group of large whales. Maintaining a higher threshold helps safeguard pool stability and safety of deposits.
  • It’s essential to monitor pools closely and consider the impact of large withdrawals on the overall pool composition.

1.2 Sidechains and Lower TVL:

  • On sidechains like ARB, where TVL tends to be lower and individual depositors are not typically large whales, a more flexible threshold could be considered.
  • Adjusting the requirement based on the specific characteristics of each chain ensures a balanced approach.

2. I guess this should be subdivided into 2.

2.1 At what ratios would we consider whitelisting a pool
- When evaluating pools for whitelisting, we should define specific ratios that warrant consideration as large deposits from the Omnipool can severely impact the safety of deposits. I would suggest a whitelisting criteria of 60/40 max ratio initially as to a have a safety buffer for further negative shifts in the ratio.
- It’s essential to strike a balance between diversification and maintaining healthy ratios. For instance, if the Omnipool holds 50 million and a specific pool has 5 million (with a 70/30 ratio), allocating an additional 20% would skew the ratio significantly (potentially to 90/10). This scenario could severely impact the overall safety of deposits negatively.

2.2 When do we start to worry about current deposits in an existing pool when ratios change?
- Mechanism for Max Deposits: Introducing a mechanism that limits deposits as a percentage of current TVL and ratio is a interesting approach. This would prevent sudden imbalances caused by large LAV allocations.
- Addressing Gradual Shifts: An automated withdrawal mechanism during gradual shifts is interesting. While handling flash crashes may be impossible, gradual changes could trigger proactive adjustments to safeguard deposits.

3. - Obviously not in a DAO.

4. Voting Quorum:

  • The existing quorum level seems to stand at 600,000 votes. However, this threshold should be adjusted. Knowing the core team can independently reach quorum, we should raise the threshold to ensure broader participation and given the low average vote count (8-9 votes per session), we might consider a minimum number of votes as well to prevent undue influence from a small group of large holders.

  • Additional Information Needed:

    • Individual team members’ voting power
    • Delegated votes to team
    • Existence of a DAO multi-sig address with voting power and its custodian
    • Total current votes

Considering the above, at a glance, and missing some key information, a minimum quorum of 1,000,000 votes seems reasonable and possibly a minimum amount of votes.

Thank you for posting this discussion. Looking forward to further insights from the community

Thanks for sharing your points.

1. Minimum TVL Volume for Pools:

  • To clarify, the $10m TVL should have been interpreted as a guideline. The main reason for this was to prevent certain exploits when the Omnipool has high double-digit million TVL (this was also discussed with the auditors before launching Conic v2). The main point is that an Omnipool doesn’t control a majority of the TVL held by a Curve pool. With this in mind, we should keep the addition of new Curve pools as is (via a CAP) and not decide on some fixed threshold.

2. Coin Ratio Acceptance:

  • I think this should be discussed when a CAP is proposed on Discourse. If you have concerns about the skew, please voice them in the proposal/discussion. Also, Curve pools are designed to allow for some skew, while keeping the price stable so it’d be difficult to lock in some fixed values for all pools.

3. Core Team Decisions:

  • First of all, coin guidelines do not exist. All new pools go through governance, and there should be sufficient time to address and discuss any concerns before adding any new pool. For the TVL guidelines, this has hopefully been clarified by point 1. If the TVL of a Curve pool changes over time to a point where it becomes a security concern then it can of course be discussed in a CAP on Discourse and the pool can be removed (as has been done in the past, for instance, see the GUSD+FRAXBP Curve Pool discussion).

4. Core Team Voting Quorum:

I’m not sure I fully understand this point, but the core team operates the lfv.conic-dao.eth address. Anyone can delegate to this. At the same time, anyone can become a delegate (perhaps this is something you’d be interested in). You can check this out here: Delegates - Conic Finance