mDAO Governance Proposal: Liquidity mining gauges

[dobby]

@gekonn

New optional governable parameter: Cap the MNDE weekly % that can go to a single protocol; initially set to 20%

@gekonn

To not go completely wild, and to establish a healthy metagame on MNDE distribution in a safe(er?) environment, one thing to consider at the start would be to cap the % of votes each gauge can receive to 20% for the first year, or even more gradually start at 20% and rise by 1% every week.

Thinking about this idea a bit more… what if we sync the pace of increases here with that of the 1.5% cap proposed in mDAO Proposal: Voting on validators stake using on-chain gauges through the MNDE token ?

What do we think about increasing this 20% cap by 1% and increasing the 1.5% cap on validator stake by 0.1% every 50 epochs?

[gekonn]

Thanks everyone for the discussion. To nest it into the current DAO structure, the partnership workgroup would correctly be DAO ops WG, where tokenomics currently rests. I suggest to add the following to the proposal:

• allow DAOops WG to optionally boost the weekly liquidity mining budget by up to an extra 25% and direct it manually based on provided rationale shared in Discord.

Notes

• will be used to direct attention towards new protocols, integrations, and developing partnerships
• numbers: assuming a weekly liquidity mining budget of 1M MNDE, up to an additional 250k weekly can be distributed
• optionality means - does not have to be full 250k, does not have to be used at all
• rationale will be likely shared as it happens or with a slight delay to Discord. Will probably warrant a dedicated channel for discussion - maybe one that can cover the whole LM gauges topic.
• in order to be flexible in a manual setting, I think the time decay is a hindrance and not a great controlling tool. It adds an additional complexity that creates a false sense of certainty. I would rather see a proposal to lower the % or remove the power after some time, so I am committing it in the proposal. The same reasoning can be added in synchronizing this to a different system @dobby suggested. While both systems want to use voting gauges, the uses are not the same and the same decays would only create a fake image of similarity.

[vvv]

I agree with not linking to any other proposal (that validator gauges proposal has not finished and was not executed yet) and agree that implementing automatic decreasing might mean more unnecessary development not worth the outcome. So let’s keep DAO wg optional boost manually set and maybe decrease in the future vote

[socrates]

I am for this proposal.

And I would like to anticipate that I think there is a potential dilemma in when selecting which protocols to boost. Please correct me if I am wrong. The dilemma is: decentralization x fostering mSol adoption.

For the decentralization pov, we should support proportionally more the small new, but solid, protocols that have a small TVL;

For mSol adoption pov, we should support more the largest hubs of liquidity in Solana ecosystem, to beat our competitors in rewards providing. And one could also argue that by fostering mSol adoption and beating our competitors, is our main way of defending decentralization.

[brian_smith_0]

I support this proposal as it furthers the project’s decentralization and increases the utility of the MNDE token.

Re: caps on weekly emissions and per protocol limits, I believe both of these are necessary during the initial roll out stages. The governance process is still its infancy. Voter participation and the potential structure or cost of any bribes are complete unknowns. We should have some guardrails to ensure unexpected outcomes don’t happen in the initial stages.

For example, votes could authorize a massive amount of MNDE issuance during a specific week or allocate excess amounts to a small cap pool to benefit specific entities. I trust the governance process will avoid these outcomes once mature but I think it is too risky to allow these currently.

Re: Exec Team carve-out: A ~25% carve-out for discretionary allocation from the core DAO ops team seems fine to me. The exact amount controlled by gauges vs. discretionary can always be adjusted in the future as we see how things evolve.

Re: community input process, I believe a specific discord channel for LM allocation should be opened up as soon as possible. Most Marinators are not accustomed to evaluating these types of decisions. This will give the community time to digest the data and start to understand the process while the voting infrastructure is being setup. I think Lido does a great job of this with their efficiency dashboards and communication around LM allocation (see [reWARDS] May '22 Budget - Lido Governance).

Thanks @gekonn for proposing. I look forward to seeing this idea progress.

[gekonn]

Thanks all

• I added the 25% optinal extra distribution to the proposal body
• Pinged the Build WG for an additional feasibility check over parameters (total, cap) and gauges addition process

If all ok, I think we are ready to bring this to a vote.

[repe]

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%”

or

“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.

[gekonn]

Hello, thanks for the comment

1. extra up to 250k MNDE would remain on manual control - no development required

2. per gauge, not protocol - thanks for the clarification. But it looks like very hard to develop, so I agree to suggest cutting this from the initial scope and adding it if needed.

3. this is the hardest to cover because modeling the liquidity mining shape on what we know today does not necessarily reflect how it will look like in the future and the fake quarry aka relayer is the biggest factor in that. That being said, here’s a sheet showing the current liquidity mining distribution with quarry. Result=72% of MNDE does not go to quarry. My recommendation is to continue asking partners to set up one and before that happens, develop a relayer.

MNDE quarry

[repe]

1. Do we need the executive team power to be reserved 20% voting power from the MNDE tokenholders?

@gekonn

• extra up to 250k MNDE would remain on manual control - no development required

You’re right, it doesn’t require further development, but weakens both of this proposal’s objectives you described in the very first post:

@gekonn

Opening the decisions on where to direct MNDE incentives to all MNDE holders should make biases irrelevant and remove the chance for Chefs’ errors while providing a parametric regulation.

@gekonn

Automation - MNDE can be dispensed automatically from the treasury from a pre-allocated budget. This reduces overhead of multisig coordination on the Chefs’ side, which will also enable cycles shorter than 2 weeks.

I’d argue it would be better for clarity and transparency to have one central place for the MNDE incentives distribution so that the weekly MNDE distribution rate is predictable and not dependent on the Chefs to step in with their 25% extra.

I hear the concerns if the Chefs don’t have enough say in the allocation strategy, but that could be naturally solved by the existing tokenholders split where ~20% circulating supply lies on the Chefs team.

What’s more, we can also establish a transparent public channel to discuss the recommended MNDE emission strategy worked out by the Chefs overseeing tokenomics, and this channel would not be bounding but serve as a place to potentially influence and unite not only the team token holders but also the other Marinators (MNDE holders).

3. Do we know more about the Quarry<>Protocol incompatibility problem?
Thanks for the data. Outside of Lending, Options, and Synths, it looks like 80% of the MNDE incentives are sitting in the Liquidity pools category.

Now given the double rewards already work in Quarry and Marinade used it together with Saber to incentivize the LPs to mSOL-SOL pool both in SBR and MNDE, what’s the tech limitation that doesn’t allow Raydium, Orca, Mercurial, Crema, Atrix or Aldrin users to deposit their LP tokens to a Quarry vault, instead of putting it in their respective platform’s own liquidity mining system?

[gekonn]

1. Yes, it does indeed weaken the points. The question here is not if but when to remove the manual control. I see moving 75-100% of weekly emissions to gauges as a big enough step toward the decentralization. This should telegraph the willingness to give up power with still keeping some ability to course correct. But this is a realm of guessing, a feel for the ecosystem and community.
   But I also see the benefit of having a simple system and moving the steering to a social consensus instead - willing to try it actually.
   @DizzyLizzy and @dobby might provide their take on the problem - you had opinions on this before.

2. (should be 3, but the code is smarter than me here) Framing it as a tech limitation will not get the answers I think. There’s only one tech limitation coming to mind - concentrated liquidity positions being represented as an NFT. But anything can be developed.
   From the discussions I had, some projects see it as breaking their desired UX, some don’t see Quarry as a safe product with a clear strategy, stakeholders and security yet. Marinade needs to take a more active part in changing that.
   And there’s also an upside - new product might be keener in implementing Quarry as they are not yet locked in to a roadmap and UX decisions.
   Either we don’t provide a relayer and make it really difficult to incentivize liquidity pools - which weakens the whole proposal - or we do it and can use a working example as an argument towards protocols to integrate Quarry tightly.

[vvv]

Gm frens Thanks for the discussion.

Liquidity mining gauges should automate most of the decision making, but it might take precious time until new option is added and new allocation is executed. Also we should bear in mind, that some products have exact time of execution and might be considered private by our partners until the reveal and we might want to supply mining allocation from the start immediately.

@repe

I’d argue it would be better for clarity and transparency to have one central place for the MNDE incentives distribution so that the weekly MNDE distribution rate is predictable and not dependent on the Chefs to step in with their 25% extra.

This 25% extra does not have to be used. It is the option for chefs to use this IF they decide they need it and can be removed later. I believe there should be clear way for executive team to have the power to use it (if used fully it would mean only 20% of weekly allocation so it fits your 80% pov). This gives them option to react swiftly to market/ecosystem situation and not to wait minimum 11 days (draft + vote + execution) until voted in governance.

And since there is no programming included and no work regarding this extra allocation required (only option given), I would suggest to keep it there.

[repe]

@vvv

Also we should bear in mind, that some products have exact time of execution and might be considered private by our partners until the reveal and we might want to supply mining allocation from the start immediately.

I don’t understand why we should rush and backchannel this without any discussion at all. I think it’s appropriate to talk about risks in allocating MNDE incentives to new cases. Anyway, see the last point addressing the flexibility of the MNDE voting over emissions.

@vvv

This 25% extra does not have to be used. It is the option for chefs to use this IF they decide they need it and can be removed later.

Check again the existing token supply distribution, the 20% voting power already lies on the team tokens, and could be used as the extra lever as well.

@vvv

This gives them option to react swiftly to market/ecosystem situation and not to wait minimum 11 days (draft + vote + execution) until voted in governance.

Check the previous explanation of the mechanics, the team tokens can react as swiftly as other MNDE holders:

@gekonn

Clarification: Gauges votes could be different than normal votes.
A voter can simply indicate their preference once and the weights can be continuously applied and recounted - no need to revote. Revote only happens when a voter changes their allocation decision. This can go in a separate way to standard voting and does not need to follow 5 days vote time.

[gekonn]

After sleeping on it, I think we should go without the optional extra allocation. The social coordination in supporting new projects and balancing the winners out, if it can be created and developed, is much more valuable long-term. We should start now

[dobby]

It was great catching up on this debate and reading through the comments above. Also appreciate the chefs bringing more data and clarity to the table.

@repe

I’d argue it would be better for clarity and transparency to have one central place for the MNDE incentives distribution so that the weekly MNDE distribution rate is predictable and not dependent on the Chefs to step in with their 25% extra.

I hear the concerns if the Chefs don’t have enough say in the allocation strategy, but that could be naturally solved by the existing tokenholders split where ~20% circulating supply lies on the Chefs team.

What’s more, we can also establish a transparent public channel to discuss the recommended MNDE emission strategy worked out by the Chefs overseeing tokenomics, and this channel would not be bounding but serve as a place to potentially influence and unite not only the team token holders but also the other Marinators (MNDE holders).

^^ this was most impactful for me.

As long as the team retains some control to do what they believe is best for the protocol and there remains a high degree of transparency, I think we should all be happy.

[gekonn]

Hello, I edited a and commented the opening post and I believe we are ready to take it to the vote.

• Dropped: Protocol gauge cap due to development complexity
• Dropped: optional 25% incentives controlled by chefs for opacity

Final proposal summary:

• Switchover the liquidity mining incentives coordination to Marinade governors
• Connect Tribeca pro-rata gauges to Quarry, allowing Marinators to vote on MNDE incentives towards their preferred protocols
• New governable parameter: Cap the MNDE amount to be distributed; initially set to 1.000.000 MNDE (0.1% total supply) weekly

[PlayerOfBits]

Marinators, this proposal is now active for voting on Tribeca: Tribeca - Governance By DAOs, For DAOs

Happy governing!

[dobby]

Happy to see this move to on-chain vote. After all of the discussion above, I think the proposal landed in a really good spot. Will definitely be voting YES here.

[gekonn]

The proposal has passed with 17.7M votes for out of ~17.8. Now the real work starts <3

[gekonn]

Liquidity mining gauges are now implemented. Go ahead and try them governooors: Tribeca - Governance By DAOs, For DAOs

• Weekly rate is 1M MNDE, the voting cycle lasts 1 week.
• Just like validator gauges, vote once and your input will be applied to all the cycles until you change your mind and re-vote.
• Initial setup was done by the Master Chef team based on the previous manual distribution, to provide some anchoring and uninterrupted claim for pools already using Quarry.
• Last manual distribution runs parallel with the first vote.
• Incentives distributed by vote are always claimable the next cycle; the first voted-on incentives will be claimable after 15/7
• Votes added before 15/7 will be applied for incentives claim during 15-22/7.
• All pools where Marinade was providing MNDE incentives now have a gauge. Most of the projects will claim MNDE on their users’ behalf and distribute it themselves.
• Addition of new quarries is not permissionless, anyone interested to add a quarry should submit it here.