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!