mDAO Proposal - Market Making Partnership with Lifinity


Hey chefs!

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

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


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


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!


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.

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.

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!


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

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?

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.

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!