mDAO Governance Proposal: Liquidity mining gauges

[gekonn]

Hello you beautiful culinary liquid staking enthusiasts!

Problem

MNDE Liquidity mining serves 2 functions in Marinade:

1. it incentivizes staking SOL and using it in DeFi integrations, being a means of acquisition and retention
2. it spreads the ownership of Marinade protocol around in the ecosystem to its users, decentralizing Marinade

Liquidity mining plan for every 2 weeks is currently planned by the Chefs team. While flexible in the beginning, as the Marinade and the space around it matures, this control can (will!) include biases, omissions, and errors.

With Marinade governance online, there is an opportunity to decentralize this part of the DAO by transferring the power to allocate MNDE incentives to the MNDE owners.

Proposal

Hand over liquidity mining planning to the Marinators via on-chain governance

• 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

Rationale

If implemented, this proposal both opens and automates liquidity mining planning.

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

   The expected behavior is for all users to vote the most selfishly for the protocols where they provide the liquidity or want to see growth. Users voting randomly will be slowly diluted by the selfish voters, making their liquidity mining vote less and less relevant. This ensures the users are always incentivized to seek and capture the biggest value for themselves, and thus for Marinade.

2. 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. Shorter cycles, in turn, make it easier to follow and adjust to market conditions.

   Voting via pro-rata gauges allows for vote-and-forget behavior for the selfish voter. They will simply set up their preference once in the gauges UI and won’t be forced to ever readjust them (unless they acquire more NFTs, lock in more MNDE, or change their mind).

Emissions

Founding Chefs originally planned to allocate roughly 1.7M MNDE weekly for liquidity mining with a predictable base rate and some flexibility to increase or decrease it to allow for promotion or remove needless spending. Average after 26 weeks (excluding Milestone bonuses) is almost exactly that: Docs, with the last weeks’ rate bring roughly 1.25M MNDE per week.

The proposed reduction to 1.000.000 MNDE be allocated to gauges is in place to stimulate consolidation of the incentivized channels - a gradual change in a liquidity mining strategy from stimulating ecosystem adoption to selecting the most interesting mSOL uses.

The Chefs’ view is that Solana ecosystem has undergone a dramatic development of core DeFi and NFT protocols, which now largely offer a similar product with a different token on top. To stimulate further improvements and innovation and to make space for exciting new mSOL uses, Marinade stakers - and not only Chefs - should rise up to the responsibility of choosing the best places to use their mSOL. Should the responsibility lies solely on Chefs, then it could potentially lead to biases and a narrower view of the space.

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.

What is the expected positive impact of this change?

Giving true power to the token-holders is scary yet necessary - otherwise tokenized governance would be just a meme. Marinade is on a mission to decentralize Solana and itself (See 2022 roadmap), and where to better start than deciding on where to further give itself away.

In the frame of the mDAO, this proposal seeks to drag in and engage a solid group of tokenomics gourmets, driving the liquidity mining discussion forward, perhaps by providing a recommendation and reasoning to the rest of the Marinators on why vote a certain way.

In the frame of selfish behavior, other protocols and DAOs are expected to use/buy/borrow their MNDE and vote-steer the MNDE incentives for themselves and their allies. While this may be a low way of getting their attention, this attention could be further and more easily steered towards harder-to-digest Marinade values like decentralization by leading by an example in openness, empowering token holders, and reducing bias.

Considerations and Open Questions

Discuss:

• New Gauges: we will need to add a process for voting. This can likely be lightweight or informal since the actual voting towards incentives is what matters, but there is some merit in projects seeking MNDE incentives approaching the community via a public forum post.

• Quarry support: not all protocols support Quarry. Marinade will need to create quarry-relayers, to be funded by treasury and automatically deposit to the protocols’ distribution wallet. devChefs will need to explore the technical design and feasibility.
  // Edit: For protocols that cannot support Quarry easily, private quarries will be created and tokens issued so they can claim on behalf of their users.

• Coordination: We will likely need to create a new Discord liquidity mining channel under mDAO for discussion, reasoning, influence, and coordination. Suggested rights: Read everyone, write only Marinators.

• Bribes (=voting incentivization): bribes come hand in hand with voting and allocations. It’s a reality elsewhere in DeFi (and the world), and architecture should be designed in a way to make the system open to 3rd party interactions like bribes.
  Arguably, exposing the DAO’s bribe attack surface should make the DAO stronger, not weaker. Note: Governing is a responsibility first, and a right second.

• Lack of flexibility for the Partnership and Growth workgroup to support new integrations: perhaps allocate optional extra, up to 10% of the total weekly MNDE to partnership WG to allow directing attention towards new protocols, integrations, and developing partnerships.
  // Edit: dropped from a proposal. For an approachable and transparent, this will need to be achieved via social consensus.

[octo]

Don’t have much input on the proposal except to declare my full support!

[vvv]

@gekonn

• Lack of flexibility for the Partnership and Growth workgroup to support new integrations: perhaps allocate optional extra, up to 10% of the total weekly MNDE to partnership WG to allow directing attention towards new protocols, integrations, and developing partnerships.

I want to definitely suggest to have this as an integral part of the proposal.

Reasoning:

Executive team that runs Marinade is negotiating with various protocols around solana on daily basis and might have informations that cant be public and therefore be discussed and voted on chain. Every vote takes 5 days and the vote should be done after the discussion here on forum (this is something we want to encourage). So a lot of time can be lost (including moment of surprise) if every collaboration and liquidity mining is voted via on-chain gauges before it is started.

This might also be the way to allocate some MNDE for new partner before this protocol implements quarry (or any other supported way of receiving mining allocation).

Having this buffer for execution team will help Marinade move fast and grow week by week.

[c2yptic]

I agree. Personally, I think it should be more than 10% initially, perhaps 25%. This gives the executive team the option to be strategic in line with what you wrote @vvv.

Say the first iteration is a alpha stage. Then after some time when this has matured, we’ll enter the beta stage and then full on mDAO driven LM incentives as per the proposal. So basically step by step decrease in exec team influence.

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

That being said, I agree with your reasoning.

[DizzyLizzy]

Good points - I like the suggestion of a 10-25% allocation to this space.

It’s also worth acknowledging that would without it, the odds are stacked even more heavily against emerging protocols. It’s already difficult for them to gain attention from major protocols for partnerships and bribing will mostly exacerbate this issue. They won’t be in a position to buy votes, meaning they’ll have to try and win a popularity contest against teams with huge communities.

As established protocols in Solana, I think we should be helping to facilitate innovation/growth. Beyond this, I think that also reserving allocations for the projects that prioritize integrations and help to further the Marinade mission is a good idea. This shouldn’t be a big % but you’ve got to back those who have your best interests at heart IMO.

[thedamnswan]

Big fan of this idea. Will put some more time into my thoughts/questions later this week.

[Cerba]

I would agree on finding a good value between 10 and 25% controled by the Partnership workgroup to incentivize new and emerging protocols that do the effort of integrating mSOL! I would probably be on the side of a lower value than 25%, probably between 10 and 20% would be a sweet spot in my opinion, with it being a governable parameter that can get modified through a vote so it can be adapted to the ecosystem status.

I also bring my full support to this proposal overall, as I believe MNDE holders should be able to direct Liquidity Mining towards the protocols that they care for and use. This would also bring added utility to MNDE which will have a net positive on its decentralization, as influencing the rewards on other protocols may lead new interested members of the community to acquire, lock and use MNDE and start actively participating in all aspects of Marinade governance.

[vvv]

I understand about the vote. But acquiring enough votes for a new protocol will be definitely harder to get mining liquidity. And as DizzyLizzy said, if some protocol enables Marinade to fulfil its goals, executive team should have tools to interfere.

We can start by programmatically setting that executive team will have control over 25% of liquidity and every two weeks lower the share by 1% until reaching 10-15%.

[c2yptic]

I’d even dare to say start on 30% or more for exec team and then lower it to 0% over time, based on certain agreed integration/mSOL use milestones.

[vvv]

I can second this. Starting at 30% and lowering 1% every 2 weeks makes it go to zero in 15 months. Starting from 25% its around 1 year.

[dobby]

Love the proposal to activate protocol governance here and let the DAO determine where MNDE liquidity mining rewards are to be distributed.

Totally agree that the executive team / Partnerships team should retain the ability to act quickly and do their job efficiently - at least for the foreseeable future. I also agree with the points that @DizzyLizzy made above. It’s important to find the right balance.

For that reason, I am in favor of setting aside ~ 25% to be controlled by the Partnership group, as long as there is transparency into what this group is promoting. Even if the notification comes after the fact, I think it’s important for the community to have clarity around this process and an insight into the rationale for boosting liquidity mining rewards on a particular quarry.

[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