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.
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:
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
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.
^^ 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.
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.
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.
Thanks for the discussion.
