As far as I can tell basically just the usual suspect – smart contract risk. I don’t think this is the place to discuss all the details of the potential risks of how Lifinity and Marinade’s smart contracts could go wrong though. I do think this is a common enough risk (applies to literally every protocol ever) that it makes sense to not mention it in the opening post.
Worst case scenario for Marinade: 2M MNDE goes to waste.
Worst case scenario for Lifinity: $1M of assets lose value (mSOL is exploited or we experience a lot of IL) or are stolen (Lifinity is exploited).
Bottom line is that the risks are siloed to within each protocol.
Amounts involved seem reasonable for both parties and as you say Gekonn Lifinity has some skin in the game. Im invested in both Marinade and lifinity.
WRT timeline. Why wait? Lets do it.
I personally went back to SOL from mSOL as I had no real way to trade mSOL effectively. Spreads were way to wide and liquidity not deep enough. Must be lots more in the same boat. This solves that issue along with other benefits outlined.
I have a question though (my ignorance): Do protocols usually give grants for opening an asset-USDC pool? Was it always the case for all the asset-asset pools over the years?
I can’t say how common it is - I’ve seen more market-making arrangements of the type that @Durden originally proposed, which can be more straightforward when there isn’t something like the liquidity gauges.
The way it’s structured, it’s better to see it in terms of an MNDE commitment to kickstart a partnership and not a grant per se.
There is also a governance imbalance risk. Lifinity will get 2M MNDE and will use it to vote for themselves in the gauges.
When a protocol gets MNDE and votes to incentivize their own pools, the MNDE gets distributed among their community members who are the LPs. Some of them are bound to sell, or forget to re-vote on the gauges.
In this case Lifinity is the sole LP, so they will reap all the rewards which they can then use to direct more rewards their way every cycle.
I can’t say how much this will be. The initial liquidity mining gauges distribution closes in three days. I expect we’ll get some last-minute whales voting. Once that’s closed, it’ll be easier to calculate and create a model.
It’s hard to see how a potential imbalance like this one would play out.
On the one hand, it can make Lifinity a dominant player on the liquidity gauges. On the other, it could incentivize other protocols to acquire more MNDE to direct rewards their way.
What’s common is providing liquidity mining incentives for pools. We received feedback from the Marinade community that a grant is more appropriate in this case to match Marinade’s liquidity mining gauges and our need to develop a custom oracle.
Personally, I largely viewed this as a positive for Marinade. I assumed the Marinade community would prefer that MNDE emissions be locked up rather than distributed as rewards to veLFNTY holders since this means less sell pressure. If the community prefers that we distribute the rewards to veLFNTY holders so that Lifinity’s 2M MNDE doesn’t become larger, we can also do that. But I assume this is not the consensus view.
If Curve and Convex are any indication, protocols will tend to continually purchase assets to gain access to future emissions. I think the narrative of a protocol accumulating MNDE would be great for Marinade (think Saber and Sunny a few months ago…MNDE wars, anyone?).
To me it makes sense this way and I understand it much better now. Thanks for your effort @Durden! If the Marinade team finds these terms meaningful - which from my understanding they do so far - I’m in full support and would consider the proposal fine.
Of course the gain of liquidity by this pool is the huge benefit for Marinade of the proposal, still I’d like to understand the gauges part a bit better:
To be sure I understand it correctly, the 2M MNDE and earnings from gauges are fully locked, so also not used by Lifinity for general Marinade and especially gauge voting?
Also does that include that the gauge earnings will also not be available as reward to veLFNTY holders while locked?
What happens with it afterwards is up to the veLFNTY holders - they could also decide to reinvest it into Marinade NFTs to vote for the Lifinity gauge to increase MNDE income or generally participate in the Marinade DAO?
Would there be any potential danger with this gauge gaining too much allocation?
Since pool depositing will be closed for the public, as of now only veLFNTY holders that are also Chefs (like myself) would have an interest to vote for the Lifinity gauge, do I understand it right? The gauge can be seen as an additional benefit/compensation for Lifinity (or “Lifinity Chefs” ).
Maybe not the right question here and now, but does it have any impact on other potential MNDE rewards via Lifinity for marinators?
To be sure I understand it correctly, the 2M MNDE and earnings from gauges are fully locked, so also not used by Lifinity for general Marinade and especially gauge voting?
Locked as in locked via Tribeca, the same way all other MNDE is locked. One of the purposes of locking is to enable voting, so we plan to vote for our own pool.
Also does that include that the gauge earnings will also not be available as reward to veLFNTY holders while locked?
Yes, at least for the first year all MNDE earned by our pool will be locked.
What happens with it afterwards is up to the veLFNTY holders - they could also decide to reinvest it into Marinade NFTs to vote for the Lifinity gauge to increase MNDE income or generally participate in the Marinade DAO?
As mentioned above, the plan is to use them for voting from the start.
Would there be any potential danger with this gauge gaining too much allocation?
Not sure what counts as too much, but as I mentioned in a previous reply, “I assumed the Marinade community would prefer that MNDE emissions be locked up rather than distributed as rewards to veLFNTY holders since this means less sell pressure. If the community prefers that we distribute the rewards to veLFNTY holders so that Lifinity’s 2M MNDE doesn’t become larger, we can also do that. But I assume this is not the consensus view.”
Since pool depositing will be closed for the public, as of now only veLFNTY holders that are also Chefs (like myself) would have an interest to vote for the Lifinity gauge, do I understand it right?
Sounds right to me.
Maybe not the right question here and now, but does it have any impact on other potential MNDE rewards via Lifinity for marinators?
Just curious if there might be other opportunities for marinators to earn MNDE rewards via Lifinity, and if this is somehow related. But I guess not.
As mentioned I support pushing the proposal.
Maybe it makes sense to add the locking → Tribeca → enables gauge voting detail to your proposal? But maybe everyone else is clear on the terminology.
This is intentional. Forum discussions are the point of record for proposals, so we have configured Discourse to disallow edits after a few hours - that way we know that, by the time an onchain proposal is active, the specific points linked to are set in stone.
If you need to update the proposal, just make a “diff” comment.
I’ll start with a disclaimer, I hold some LFNTY tokens. But I can see benefits to this for Marinade and mSOL as a whole, so I personally like this modified proposal. @Durden has both modified the original proposal and answered all related questions gracefully, giving me a good impression. Lifinity also shares the general decentralization ethos with Marinade, which to me is a plus.
Not only do they provide market making + liquidity as a service, they will develop an custom oracle for mSOL that would be open sourced too, which I think is of possible great benefit to the whole Solana defi ecosystem.
In order to effectively market make for mSOL, Lifinity must create a custom oracle. This involves using Pyth’s SOL price feed as a starting point and adding staking rewards to it at the end of each epoch.
The proposed approach works 99.9% of the time but fails to provide accurate pricing data in emergency situations such as a hypothetical mSOL security incident or bank-run with no available instant unstake liquidity.
Even though the maturity mismatch between SOL & mSOL is not as severe as with other LSD, I am not sure if LFNTY POL should treat them as pari-passu. At the very least, there should be ample risk monitoring.
To be clear, we haven’t outlined the precise details of how we plan for our oracle to work in the proposal.
For example, we’ll use Jupiter’s mSOL/SOL rate (i.e. the current market rate) so that if Marinade is hacked and mSOL tanks relative to SOL, for example, our DEX won’t be purchasing mSOL with USDC at elevated prices. Further, the oracle will have a certain price range (expressed as a % of the current price), and whenever it goes beyond that within too short of a time span transactions will not go through.
Lifinity takes on the risk of holding assets, so we agree that proper risk management is paramount! As with all our pools, we test them before actually opening them at scale. The mSOL-USDC pool will be no different, and this testing will inform the exact design of our mSOL oracle and the accompanying safety measures.
Robust mSOL oracle solution would go beyond pricefeeds and include mSOL-SOL true price from Marinade contract and correlate it with SOL-USDC price orcale, maybe discounted by epoch time (=time to unstake).
How “robust” an oracle is really depends on what the oracle is being used for. In our case it’s for market making, so it’s ultimately a matter of inventory management. The market price of mSOL is essentially always lower than Marinade’s staking rate. If we used your version of the oracle and the price of SOL dropped beyond the value of the rewards distributed during that epoch, we wouldn’t be selling when the price falls (as we normally do), resulting in IL.
However, if that version of an mSOL oracle is important to Marinade, we can create and open source two versions of the oracle – ours and yours. This would include:
The smart contract, which is just a simple program to record price data on-chain
Some examples (at least two) of how we can aggregate price and send transactions to the program
(Fyi we will likely be modifying the oracle that we plan to use as we gather actual trading data.)
I agree with you here, my comment was from a position of Pyth having several price failures resulting in faulty liquidations of mSOL collateralized loans, so having this as a backstop would help you
I see. That was likely because mSOL didn’t have much liquidity on CEXs. Again, and I’m sure you understand this, but this is why we need to create a custom oracle based on Pyth’s SOL price feed.
).
Forum discussions are the point of record for proposals, so we have configured Discourse to disallow edits after a few hours - that way we know that, by the time an onchain proposal is active, the specific points linked to are set in stone.