Thanks @gekonn for kicking this off.
In general, I support moving liquidity mining emissions management from the executive team to the DAO, for the reasons you described well in detail.
What’s even better, this feature is already built into the systems used by Marinade for governance (Tribeca) and liquidity mining (Quarry), where Saber has been using it for months in production.
While it’s tempting to fine-tune the existing solution with proposed adjustments, that requires precious build time, and costs resources, and so effectively lowers the value/cost ratio compared to if Marinade tried to stick the closest it can to what’s been already built.
Those custom adjustments per this proposal are:
- 20% voting power excluded from the MNDE tokenholders, and saved for the Marinade executive team
- limit the maximum MNDE allocation per one gauge or a DeFi use case
- build out a custom solution for protocols incompatible with Quarry, the liquidity mining system
Let me add a few topics addressing these to discuss, to see if they are absolutely necessary to go with the first version of this change, moving liquidity mining emissions to the DAO voting:
1. Do we need the executive team power to be reserved 20% voting power from the MNDE tokenholders?
Per the described allocated team allocation distribution rate, the current 9.75% MNDE token supply consists of about 2% team unlocked tokens, and 7.75% community/liquidity mining tokens. That’s 20% voting power sitting on the team already, just through the token supply distribution.
Next, given that the Marinade DAO already distributed about 1/5 of its total liquidity mining allocation, I feel like now that the DAO systems are established it’s appropriate to let the DAO handle the rest of the liquidity mining allocation completely, especially given that the team will effectively oversee around 20% of the total budget.
2. When a hard weekly total MNDE cap is established, do we need to bring in another limitation and introduce additional complexity?
“Cap the MNDE weekly % that can go to a single protocol; initially set to 20%”
“cap the % of votes each gauge can receive to 20%”
is the intent? Is that meant for one protocol such as Orca having 10+ pools to vote on, or for one specific pool? If one pool/gauge, why not another protocol level control?
All in all, I’d rather start lean and optimistic, without these artificial limits, and apply them if absolutely needed learning by observation, by another proposal. As @brian_smith_0 said:
“The exact amount controlled by gauges vs. discretionary can always be adjusted in the future as we see how things evolve.”
What’s the absolute extreme “worst” case we’re talking about here and what must happen for it to happen? If getting bigger amounts of MNDE is already a problem caused by little liquidity and high slippage, aren’t those potential MNDE emission manipulators punished enough? I’d like to understand if this is really worth it, not only to plan, design, and develop the feature, but to explain, document, and support right from the get-go.
3. Do we know more about the Quarry<>Protocol incompatibility problem?
To address this, can we get a breakdown of per-protocol emissions as of now, what % will be incompatible to move to the Quarry system, and what are the solutions/rough estimates of dev resources to adjust to onboard the 80% of use cases to start with and commit to adding the edge cases as we go? Since the MNDE emissions directly benefit to partner’s APY/attractivity, have we considered sharing the effort?
I’d like us to think a bit more about these topics. I have faith that Marinade can build all these custom limitations and tweaks, as with everything it is only a matter of time/resources. If there is an option we’re 80% happy with and that can go live now, rather than 2 months later, and it does not introduce any dangerous security concerns beyond the current level, I’d like Marinade to explore it. And potentially adjust by already having some real-life data to act on within the first few weeks.