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.
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.
Big fan of this idea. Will put some more time into my thoughts/questions later this week.
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.
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%.
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.
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.
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.
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?
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:
Notes
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
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.
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.
Thanks all
If all ok, I think we are ready to bring this to a vote.
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:
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.
Hello, thanks for the comment
extra up to 250k MNDE would remain on manual control - no development required
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.
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.
1. Do we need the executive team power to be reserved 20% voting power from the MNDE tokenholders?
You’re right, it doesn’t require further development, but weakens both of this proposal’s objectives you described in the very first post:
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?
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.
(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.
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.
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.
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.
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.
Check the previous explanation of the mechanics, the team tokens can react as swiftly as other MNDE holders:
