mDAO Proposal - Market Making Partnership with Lifinity

Introduction

Hey chefs!

This is Durden from Lifinity. I would like to propose a partnership between Lifinity and Marinade.

tl;dr
・Lifinity creates a custom oracle for mSOL, opens a mSOL-USDC pool, and provides the assets for market making
・Marinade compensates Lifinity with 0.05% of the total volume generated on mSOL-USDC with a cap of $100M per month

Let’s start with a brief overview of Lifinity.

What is Lifinity?

Lifinity is a proactive market maker designed to improve capital efficiency and reduce impermanent loss (IL). It is able to accomplish these goals by:

  1. Concentrating liquidity
  2. Proactively market making using an oracle
  3. Implementing a rebalancing mechanism

Notably, Lifinity provides a unique market making architecture that combines lazy liquidity provision, concentration, and IL reduction. This sets it apart from both constant product market makers (no concentration or IL reduction) as well as concentrated liquidity market makers (no lazy liquidity provision or IL reduction).

Since its launch in January, Lifinity has performed over $1B in trading volume with only $5M in available liquidity.

For a deeper dive on Lifinity, please check out our:

・Documentation: https://docs.lifinity.io/
・Litepaper: https://lifinity.io/litepaper

How Lifinity can Benefit Marinade

Lifinity is the most capital efficient DEX on Solana (as measured by volume / TVL). This will likely be the case for an mSOL-USDC pool as well. In other words, Lifinity’s liquidity will be able to provide Marinade with the greatest bang for its buck.

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. Other DEXs do not take staking rewards into account; their price of mSOL is purely determined by the current supply and demand for mSOL. As a result, the market price of mSOL is cheaper than the rate you get for staking SOL on Marinade’s website (i.e. you are better off using your SOL to buy mSOL rather than staking it) the vast majority of the time.

By adjusting prices according to Pyth’s SOL price and the staking rewards accrued, Lifinity’s custom oracle will bring mSOL’s market rate to be as close as possible to the staking rate (the amount of mSOL you get for staking SOL on Marinade’s website). This is ideal for Marinade for two reasons:

  1. mSOL holders can convert their mSOL to SOL at a better rate. The ability to immediately exit with minimal loss of the SOL contained in the mSOL means a greater willingness for users to acquire mSOL.
  2. The closer the market rate of mSOL is to the staking rate, the easier it becomes for the market rate to fall below the staking rate, which will be arbitraged by staking SOL for mSOL and then selling it on the market for SOL. This increases the total amount of SOL staked through Marinade and, consequently, Marinade’s revenue.

Let’s consider how this would work in practice through an example.

Suppose there is 1 hour left until the end of the current epoch, and the price of mSOL on Lifinity and other DEXs is the same. After 1 hour passes (assume no trading has taken place for simplicity), Lifinity will have adjusted its mSOL price higher, adding 1 epoch’s worth of staking rewards. Since other DEXs still have the same price from an hour ago, there is an arbitrage opportunity. Users can buy mSOL cheaply from other DEXs and sell it on Lifinity for a profit. The net effect is for the price of mSOL to increase on other DEXs (i.e. become closer to the rate you get from staking SOL for mSOL). In the absence of Lifinity, supply and demand would be the only forces influencing the price, these arbitrage trades would not take place, and the price of mSOL would adjust much more slowly. Thanks to Lifinity providing more accurate pricing, arbitrage becomes possible, the market price of mSOL is adjusted upwards, and this brings about the benefits mentioned above. Put differently, Lifinity will on average be a more willing buyer of mSOL compared to other DEXs.

In summary, in addition to the benefit of deepening liquidity, Lifinity’s custom oracle will help price mSOL more accurately, which benefits Marinade by improving mSOL’s conversion rate and increasing the amount of SOL staked through Marinade.

In the future, we may adjust our oracle to price mSOL as if staking rewards were distributed at a linear rate rather than all at once. In reality, rewards are distributed at the end of each epoch rather than continuously. However, mSOL at 2 days before an epoch’s rewards accrue is less valuable than mSOL at 2 seconds before an epoch’s rewards accrue; neither actually has the rewards at that moment, but the latter will receive them much sooner, and ideally this time component should be factored into their prices. Testing is needed to determine whether this market making strategy is feasible, but if it is it would cause additional upward pressure on the market price of mSOL, further enhancing the beneficial effects mentioned earlier.

Partnership Details

We recently published an article introducing two new services that we began offering to other protocols: Introducing Market Making & Liquidity as a Service | by LIFINITY Protocol | May, 2022 | Medium

Article tl;dr
・Market Making as a Service (MMaaS) – Marinade provides the assets for market making and retains the market making profit (MMP), while Lifinity keeps the trading fees
・Liquidity as a Service (LaaS) – Lifinity provides the assets for market making, and Marinade compensates Lifinity for the risk

We believe LaaS is currently the better option for Marinade as it more closely matches the model that Marinade is currently utilizing with other DEXs, where liquidity is incentivized through MNDE emissions.

We propose building a custom oracle for mSOL, opening a mSOL-USDC pool, and depositing $1M worth of Lifinity’s protocol-owned liquidity (POL) to market make for the pair. In exchange, Marinade would provide 0.05% of the total volume generated on mSOL-USDC with a cap of $100M per month (i.e. the maximum paid on any given month would be $50k). (Note: In the future, we can also consider adding a mSOL-USDT pool with similar terms.) The payment would be made in MNDE, using the USDC value of MNDE at the time of payment to calculate the amount. The MNDE will be distributed pro-rata to our thousands of veLFNTY holders, expanding the MNDE holder base. The 0.05% figure is comparable to Marinade’s subsidies for Raydium and Orca’s mSOL-USDC and mSOL-USDT pools (i.e. when calculated as if they were paying per unit of volume, although in reality they are not). The cap provides Marinade with a layer of protection in case our pool is “too successful”.

As explained in the article, we believe charging based on the volume generated makes the most sense as this properly aligns incentives and Marinade essentially only pays for whatever utility is realized from Lifinity’s liquidity provision. This is different from Marinade’s other liquidity mining programs in that, instead of specifying a fixed amount of MNDE from the start that will be shared among LPs, the amount of MNDE to be paid is variable and determined only after the period of liquidity provision has ended. An additional benefit of this model is that the liquidity provided is stable rather than fluctuating as it is when it is dependent on mercenary liquidity providers.

This proposed model is incompatible with the standard liquidity mining model employed by Quarry, which is utilized for the recently accepted proposal for Marinade’s liquidity mining gauges (https://forum.marinade.finance/t/mdao-governance-proposal-liquidity-mining-gauges/). And this is for good reason: unlike other DEXs, our pool requires the development of a custom oracle for mSOL and the rewards are not fixed but rather based on volume. 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.

Conclusion

This proposal will:

・Improve liquidity for mSOL
・Provide more accurate pricing for mSOL
・Increase the amount of SOL staked on Marinade

Overall, the proposal is consistent with Marinade’s current liquidity mining initiatives. While all DEXs increase liquidity for mSOL, Lifinity is able to offer the additional benefits mentioned above by integrating the time component through a custom oracle. Further, we are able to do this in the most capital efficient manner thanks to our use of Pyth’s oracle for SOL.

Looking forward to hearing what the Marinade community thinks!

12 Likes

To clarify, in case anyone missed it on the partnership details, the $100M is a cap on volume and not on the value paid out. The maximum amount paid out would be $50k per month.

1 Like

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.

1 Like

(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:

  • First, it makes the amount of MNDE that would be potentially entering the supply unpredictable;
  • Second, it potentially dilutes some MNDE utility. The liquidity mining gauges let MNDE holders decide where the MNDE supply should be going, but this would remove an unpredictable amount from their control.

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.

1 Like

Basically just going to copy paste my reply from Discord :grimacing:

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!

3 Likes

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.

6 Likes

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.

6 Likes

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 :slight_smile:

2 Likes

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!

8 Likes

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 :smiley: 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:

  1. The fixed amount is not possible in gauges where Marinade wants to manage all liquidity mining precisely as the liquidity topic is nothing but fixed.
  2. This solution would be only compatible with gauges by working around them. The point of setting up the total weekly rate was that it’s approachable, governable, predictable, automatable and auditable.

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.

3 Likes

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?

4 Likes

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 :sweat_smile: 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?

5 Likes

If Marinade went the MMaaS route, it would be relatively straightforward – we create the oracle and pool, and Marinade deposits the liquidity. Done!

1 Like

This was initially suggested, but got removed from the proposal after the discussion.

2 Likes

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?

1 Like

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.

1 Like

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

3 Likes

Yeah. The spread on FTX sucks literally. Lifinity bringing about really tight spreads improves the MSOL price discovery significantly.

3 Likes

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…

2 Likes

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:

  • It is beneficial for Marinade to have a mSOL/USDC pool on Lifinity. The Lifinity innovation of auto-rebalancing concentrated liquidity is good for tighter spreads for frequent rapid swaps.

Observations:

  • Lifinity offers 2 types of service: Market Making as a service (DAO provides the liquidity) and Liquidity as a service (MM as a service with Lifinity providing the liquidity).
  • MarinadeDAO does not have significant liquidity, but believes that it can source the liquidity from the users for less than Lifinity’s Liquidity as a service offer.

Constrains:

  • paying by $-denominated MNDE is hard to evaluate. If MNDE raises in price, it could be a great deal. If it doesn’t, it could be a really bad deal: If Lifinity provides a max volume they offer which is highly-likely, and MNDe remains at the current price, they would get ~25% of the monthly Liquidity mining budget (assuming the MNDE comes out of it). If the market goes down, this share would easily grow beyond that.
    It’s better to work with the known downside and negotiate payment in non $ MNDE. Alternative could be denominating $ MNDE in SOL.
  • Paying for volume is not something Marinade does right now. While volume on chain is a factor for listing mSOL to centralised exchanges, the similar effect could be reached incentivising liquidity on several platforms and offering the arbitrage opportunity to the market – which is the current approach. The benefit of this approach is that mSOL is available everywhere.
  • Marinade does not have spare funds to deposit into Lifinity to pursue Market Making as a service and does not want to raise additional funds specifically to do that. Moreover, depositing funds into unaudited pool would be below the responsible risk level for the treasury.

Proposed Solution

  • Marinade can extend (subject to a governance vote, or maybe note once the grant committee is formed) a grant funding to Lifinity in MNDE (in governance NFT form) to build and open-source the required mSOL-USDC oracle
  • As part of the grant, Lifinity would commit to open the mSOL-USDC pool for user deposits
  • Once the pool is open for deposits, Marinade would open liquidity mining gauge for MNDE where Marinade community can assign liquidity incentives

This approach narrows the risks and incentives for both platforms, because

  • Lifinity will have to maintain and grow the relationship with the pool depositors, including the trading fee and market making fee
  • Depositors will assume the deposit risk into the pool, specifically smart-contract risk and divergence loss risk, in providing their mSOL and USDC as liquidity
  • Marinade will incentivise liquidity deposit using the quarry, coherent with the liquidity mining program

Next steps

  1. Grant requirements from Marinade
  2. mSOL-USDC oracle scope and expected MNDE funding from Lifinity
  3. either a vote on the overall grant program or on this specific grant application
2 Likes