Thanks for the proposal, @Durden.
Marinators, there’s currently a live discussion going on in the governance chat channel. I expect some of those questions and notes will end up making it over here, but you may want to catch up with the status on the channel for now.
(Moving some of my notes from the Discord here)
There are a couple of things that make this proposal harder to evaluate against the liquidity mining gauges.
As @gekonn mentioned on Discord, it’s performance-based around volume - the liquidity mining gauges do not distribute MNDE in the same way.
Evaluation gets further complicated by the fact that liquidity mining gauges now distribute a certain fixed amount of MNDE per month, whereas this proposal expects a certain amount of USDC value.
At first blush, this has two potential side effects:
Neither of these are necessarily knocks against the proposal, but they make it non-trivial to do an apples to apples comparison against the current approach.
I do realize the proposal is for USDC rewards, and not MNDE. However, Marinade’s current budget for partnerships and liquidity mining is from the MNDE treasury. I have to assume that the USDC on the treasury is already spoken for by the workgroup budgets.
Therefore, in order to pay out USDC for a partnership, I’d expect Marinade would need to liquidate MNDE from the treasury.
@Durden had some comments on it on Discord, but I’ll let him post and elaborate himself.
Basically just going to copy paste my reply from Discord 
We understand that it’s a non-standard model, and also explained this in the proposal. On the other hand, we do think basing it on volume makes the most sense and also explained why we think that’s the case.
That said, it’s not a deal breaker for us – paying a fixed amount for a fixed amount of stable liquidity provided also works. But that also wouldn’t work with the LM model. The difference is that we are able to provide stable liquidity, so we would expect stable rewards, whereas in standard LM the liquidity provided is constantly fluctuating.
Or another idea would be to receive a certain amount of MNDE but Lifinity promises to locks up the MNDE and vote for our own pool through the LM gauges, and we only continue receiving MNDE from Marinade until the amount received through the LM gauges equals the amount we were directly receiving from Marinade (i.e. the rewards become self-sustaining based on our locked MNDE).
I’m sure there are other ideas too. The bottom line for us is that there is definitely a way to work together that is mutually beneficial, and to a greater degree than what Marinade gets out of standard LM!
It makes sense to have Lifinity market-making assets for Marinade Finance. More efficient pools and moaar MSOL adoption, as well as true value accrual for users.
Make it happen.
Hey all
Ive been researching Lifintiy since late December. Ive used SRM and RAY since day 1. Most of you know me as ive been on Marinade since the beginning.
Traditional LM based Dex structure is already outdated. Its simply unsustainable and by its nature cannot last long term. Witness race to the bottom on fees to just try grow TVL.
POL / Concentrated Proactive AMM is the present and the future. Pyth and Jump are 100% committed to Oracle driven stock exchanges and have very deep pockets. Lifintiy is the closest thing right now to that and most resembles a tradfi MM. I wrote a piece in January which explains why Lifintiy is different.
I invested in lifinity initially in tte flares and then at IDO. I follow them daily. I have Witnessed the team deliver and the culture & execution.
Bottom line is they delivered on everything they said they would. The oracle driven POL works extremely well and has done for largest defi pool on solana Sol Usdc for many months.
To me this is a no brainer. Its a better solution than what we currently have in place in every way and its moving with the times. Its much cheaper and more efficient.
Also anyone try trade mSOL on FTX? I have and the spread is terrible…actually discourages SOL folks from holding mSOL.
Hello Durden, thanks for the post. I have a few questions that came to me while reading your proposal.
First of all, your proposal contains the creation of a custom oracle feed for mSOL. Nonetheless, the true mSOL price, taking into account the rewards at the moment where they arrive (in both SOL and USDC) can be obtained directly on chain, as explained here. What would be the purpose of an additional oracle rather than using this solution?
I also wanted to mention the very recent integration of our SDK into Jupiter aggregator. As people on Jupiter are able to stake or unstake directly through Marinade when it’s the best route, I believe that liquidity will be increased and slippage reduced. Won’t this lessen the need for Lifinity’s proposal of providing liquidity?
Adding this to the fact that this solution is not compatible with the Liquidity Mining gauges that are planned, and that the deal is based on USDC and not on MNDE, it makes me doubt that this proposal fits Marinade’s current needs.
Happy to hear your thoughts on those points though 
Hey, thanks for the questions!
Regarding the need for a custom oracle, we actually used to have an mSOL-USDC pool on our DEX a few months ago. That pool used Pyth’s mSOL-USDC price feed. Unfortunately, due to a lack of sufficient mSOL trading volume on CEXs, its price feed was not able to provide us with much of an edge over CPMMs and CLMMs, which is what enables our DEX to reduce or reverse impermanent loss (IL). (Happy to explain this in more detail if you want.) We therefore decided to close the pool. You can read more about this here: DEX Performance Post-Jupiter Integration | by LIFINITY Protocol | Medium
Therefore, in order to create an oracle that is able to significantly reduce or reverse IL, we need to triangulate Pyth’s SOL-USDC oracle (which has robust trading volume) with the SOL-mSOL rate provided by Marinade, resulting in a mSOL-USDC oracle. As the liquidity provider and the one taking on the price risk of holding the assets in the pool, profitability is paramount to motivate liquidity provision, and it is this custom oracle which makes the whole endeavor worthwhile.
Glad to see the Jupiter integration! Practically speaking, this doesn’t really change the day-to-day liquidity profile of mSOL-USDC all that much. First off, Marinade’s routes are for a different pair (SOL-mSOL). However, it is still possible to improve mSOL-USDC trades indirectly, e.g. mSOL → SOL → USDC. However, this type of route will be quite rare in practice. You can see for yourself on Jupiter by typing in 1, 10, 100, and so on for SOL-mSOL to see the size at which trades start to be routed through Marinade. I checked a couple days ago and just now as well, and it was at 100k SOL ($3M+). That is a huge trade size that is rarely seen in practice. If you are converting from mSOL to SOL, you will be much better off by unstaking rather than trading (saving ~260 SOL). If you are converting from SOL to mSOL, you are better off converting small chunks gradually to take advantage of the superior liquidity on DEXs. So in addition to the fact that people generally should not be making trades of this size (for their own self-interest), they also rarely happen.
Therefore, this integration does not meaningfully improve mSOL-USDC’s liquidity. You can confirm this for yourself by checking Marinade’s volume on Jupiter (currently $0 in the past 24h, only ~$6k in the past week). This is despite having zero slippage and no fees for staking. Why is this the case?
SOL → mSOL
mSOL basically always trades at a discount to the rate you get for staking SOL on Marinade. This is because if the staking rate is cheaper than the market rate, it can be immediately arbitraged by staking SOL for mSOL and selling it on the market. So this route is only used when there’s a sudden surge of demand for mSOL.
mSOL → SOL
There is no arbitrage that is possible from the other side. To convert mSOL to SOL at the best possible rate, you have to wait for the unstaking period to conclude (of course, this is separate from Jupiter). Otherwise, all you have is the market rate. Marinade’s mSOL → SOL “unstake now” rate isn’t great because it charges a 0.3% fee, which is huge (0.001% is the norm for other DEXs).
What the integration does do is direct people to stake SOL on Marinade when that is better than trading SOL for mSOL. This is a relatively rare occurrence, but it does nevertheless help more SOL get staked through Marinade, because not everyone was checking the Marinade rate and Jupiter rate to see which was better, and not all arbitrage bots had Marinade’s staking integrated.
So the integration is great! But, again, it barely increases liquidity. This proposal will enable Lifinity to not only increase mSOL liquidity by providing more accurate pricing but also increase the amount of SOL staked on Marinade (see the explanation in the proposal).
Regarding compatibility with liquidity mining gauges, I was personally assured by the team that this would not be a problem, which is what I am referring to in this sentence: “Thankfully, Marinade also has the Quarry relayer for projects such as ours that are not integrated with Quarry, so our proposed model can be implemented through this mechanism.” This mechanism was also outlined by others in the proposal for liquidity mining gauges.
Also, the proposal is based on MNDE, not USDC. “The payment would be made in MNDE, using the USDC value of MNDE at the time of payment to calculate the amount.”
Sorry this became so long, but I hope it answers all your questions!
hello,
sorry for a delayed comment. My single point of opposition is against this:
I believe this should be addressed by building an mSOL-SOL pool, not mSOL-USDC pool 
That being said, I think having a tight spread and liquidity for mSOL-USDC is valuable for Marinade and MNDE holders. Let’s approach the proposal from the liquidity mining perspective and explore both solutions proposed here:
The solution that comes to mind would be for Marinade to fund a one-time fixed MNDE grant to Lifinity for building and open-sourcing the oracle. With the oracle in place, opening the pool would be up to Lifinity, and the deposits could be open to its users to mitigate or remove the risk of mSOL or USDC position. It would be up to Lifinity’s users to negotiate with the platform to keep or release the MNDE awarded by the gauges.
On top of that, we can try to coordinate with chefs (=voters, recent rebranding of marinators, everyone who has NFT is a chef) to vote in gauges to vote-allocate some portion to Lifinity via gauges after the pool launches, but this can not be guaranteed.
I believe there’s also a case to approach the proposal from a market-making perspective. While it looks like the liquidity is provided and is being bought,
it’s really an enabler, as pricing is in volume. Marinade can raise the same $1M in mSOL-USDC liquidity or as stated above, source it from the users depositing to the pool. What would the process looks like if Marinade has the $1M to deposit?
Thanks for taking the time gekonn!
Regarding my “mSOL holders can convert their mSOL to SOL at a better rate”, I meant to write mSOL to USDC 
Although a mSOL-USDC pool does also marginally improve mSOL-SOL liquidity.
Regarding the incompatibility with gauges, didn’t Marinade plan to have a portion of MNDE set aside to be directed wherever the team deemed most appropriate? The proposal for gauges talks about this for projects that are not compatible with Quarry and LM gauges, along with the rationale for it.
I agree a MNDE grant could also work, and we’d be happen to open source the oracle. Any idea about how big this grant would be? Also, would you happen to know how much MNDE is voting on gauges each week?
If Marinade went the MMaaS route, it would be relatively straightforward – we create the oracle and pool, and Marinade deposits the liquidity. Done!
Hey @Durden
Will any lending protocol implement Lifinity oracle?
Typically they use well known oracles which provide price for many assets.
Are they ready to spend resources for Lifinity integration?
The only intended use for this oracle will be our own. Lending protocols don’t need their oracle to be as precise as we do for our DEX (liquidations and trading are very different use cases), which is why Pyth or Switchboard’s mSOL oracle suffices for their purposes.
First of all I find it very cool that @Durden proposed this partnership directly to the DAO, thank you!
I see the benefits but also see potential issues, by Marinade reg. Gauges?
I honestly feel that I lack both the necessary knowledge and data/insights to make a rational vote, of course I also don’t want to make a subjective vote (which - on a side note - tend toward yes since I love both projects here).
Eventually I’m not the only one with this feeling. Therefor would it maybe be more feasible and straight to move forward if Lifinity and Marinade come to terms regarding a partnership that both sides find beneficial and then propose together to let the DAO vote?
On a very side note I also like @gekonn s demand for the oracle to be open-source
Yeah. The spread on FTX sucks literally. Lifinity bringing about really tight spreads improves the MSOL price discovery significantly.
Absolutely! As ive stated above. We need deep liquidity and tight spreads which lifinity will bring.
Looks like Lido has got a jump on us now as per announcement with lifinity.
I think its time to MOVE forward and vote on this…
Hello you beautiful people
Let me sum up the discussion and propose the following frame how to work with Lifinity and the next steps:
Goal:
Observations:
Constrains:
Proposed Solution
This approach narrows the risks and incentives for both platforms, because
Next steps
Thread locked as Lifinity have made an updated proposal here mDAO Proposal - Market Making Partnership with Lifinity (Modified)