Table of Contents
· Introduction
· Changing Market Conditions
· The Delta Neutral Market Maker
· Eliminating Price Risk
· Testing our DNMM
· Rollout
· Conclusion
Introduction
Despite the bear market since our veIDO, Lifinity has to date facilitated over $1B in total volume without any liquidity mining, all while generating a profit that has been distributed to token holders and used to buy back tokens. Never satisfied with our current earnings, the Lifinity team has continued searching for ways to improve our profitability.
Today we are pleased to announce Lifinity v2 — a major upgrade to Lifinity’s market making algorithm with wide-reaching benefits!
Before we examine this next step in Lifinity’s evolution, let’s consider Lifinity’s overarching goals, how v1 has performed in the current landscape, and the challenges we encountered that have incited the development of v2.
Changing Market Conditions
Lifinity aims to maximize the profit it generates from market making. This translates into maximizing trading fees and market making profit (MMP) simultaneously. This is a difficult multivariate optimization problem in which changes to improve one can negatively affect the other, and the causal relationships are not obvious since they can be obfuscated by confounding variables such as the fluctuations in volume or the luck of a trade’s timing.
Due to our DEX’s capital efficiency, we have always fared well in terms of trading fees. MMP was also a valuable source of profit in Lifinity’s first few months, but it is now approximately breakeven (the details depend on the pool under consideration). While it is impossible to pinpoint the exact reasons for the change in our MMP, we believe a major contributor is an increase in the number and aggressiveness of arbitrageurs on Solana. Our pools now revert to a 50/50 balance much more quickly than they used to even during periods of high volatility, making it more difficult to delay rebalancing and avoid IL.
This has motivated us to develop a more resilient market making algorithm and make our MMP positive again. The improvements we made have additional benefits that enable Lifinity to better control the protocol’s exposure to the price of assets and expand the set of trading pairs that it can profitably provide liquidity for.
The Delta Neutral Market Maker
Currently, our pools aim to rebalance their reserve ratios to 50/50. A consequence of this is that the amounts of each asset that balance a pool evenly depends on their prices. Consider a perfectly balanced SOL-USDC pool containing $1M worth of assets. USDC is pegged to $1, so the pool will contain 500k USDC. But the amount of SOL in the pool will depend on its price. The pool will contain 5k SOL if SOL is worth $100, while it will contain only 2.5k SOL if SOL is worth $200. Thus, as the price of SOL changes, the pool will target a different amount of SOL.
Incidentally, this can be viewed as the reason why pools incur IL. IL is any loss resulting from buying and selling compared to when the assets are instead just held. As the price of assets change, the pool changes the amount of them that it holds relative to when they were first deposited. In particular, AMMs generally buy assets as they become less valuable and sell assets as they become more valuable, both of which are unfavorable for liquidity providers (LPs).
The delta neutral market maker (DNMM) looks to disrupt this dynamic by altering the rebalancing target. Instead of targeting a particular ratio between a pool’s two assets, the DNMM targets the initially deposited amount of the base asset (as if we had just held the asset). When the price changes by a predetermined amount (e.g. 5%), the target amount of the base asset is updated and the pool rebalances to a 50/50 ratio at the new price.
The image below compares the target pool balances of a SOL-USDC pool in v1 (current version) and v2 as the price of SOL changes. v1 always targets a 50/50 ratio regardless of price. In contrast, v2 fixes the absolute amount of SOL until a rebalancing event is triggered. This means that SOL will comprise greater than 50% of the pool as price increases, and vice versa. When price moves by a predetermined amount and a rebalancing event takes place, the target amount of SOL is adjusted such that its value becomes 50% of the pool at the current price.
The key difference in v2 is that the rebalancing target is independent of asset prices until a rebalancing event. Instead of rebalancing to a 50/50 ratio for every little change in price (as we currently do), the DNMM allows us to delay rebalancing rather than be at the whim of the oracle and arbitrageurs. In practice, this will mean that the protocol is continually converting the base asset (SOL, BTC, ETH, etc.) obtained from fees to the quote asset (USDC, USDT, UXD, etc.).
Rebalancing is essentially a profit-taking or dip-buying event. The frequency with which we rebalance (i.e. the size of the price change that triggers a rebalancing event) will affect a pool’s MMP, so this will be a parameter that we need to optimize for each pool. The aim is to harvest volatility by buying low and selling high but not do so too frequently since it increases the risk of IL (more frequent = closer to the v1 model). Notably, if we assume that the size and timing of trades are identical, v2 will outperform a CPMM in terms of IL and v1 in terms of MMP regardless of the rebalancing frequency.
The image below presents two scenarios A and B with the same starting price and two potential rebalancing thresholds x and 2x but varying price action.
In A, when x is used as the rebalancing threshold, we sell some at x and rebuy at the starting price, resulting in a profit from selling high and buying low. If 2x had been used as the rebalancing threshold instead, no rebalancing would have taken place and we wouldn’t have been able to harvest the volatility.
In B, when x is used as the rebalancing threshold, we sell some at x and then sell some more at 2x. In this case, we would have been better off using 2x as the rebalancing threshold because we would have done all our selling at the higher price rather than some at a lower price and some at the higher price.
Of course, we can’t know whether price will behave as in A or B, so we have to find a rebalancing frequency that strikes the right balance between both possibilities. In general, this will mean that the more volatile an asset, the more space between each rebalancing threshold.
As a side note, a bonus feature of the DNMM is that our pools are no longer limited to the 50/50 ratio and we can create pools with any desired ratio (e.g. 80/20). This is useful for protocols that want to provide liquidity but have much more of one asset than the other or if trades are expected to be concentrated on either the buy or sell side.
Eliminating Price Risk
The DNMM was named as it was to convey its full potential, but in fact the delta neutral part is optional. The mechanism explained above deals with IL risk, but price risk is a separate matter. IL is not incurred if assets are just held, but of course the value of the assets can change, resulting in a profit or loss.
Since AMMs are required to hold assets to be able to market make for them, LPs are forced to have long exposure. And in Lifinity’s case, the LP is often the protocol itself. Through its unique property of targeting a fixed amount of an asset, however, there are a number of ways in which the DNMM enables us to neutralize price risk.
Perps
If we hold an asset and simultaneously short its perp, we will have net zero exposure to its price. This is what UXD, one of our MMaaS partners, does to issue a stablecoin backed by volatile assets. We would have to choose between using a centralized but cheaper platform such as Binance or a decentralized but pricier platform such as Mango.
Pros:
・Opening and closing positions is relatively cheap
Cons:
・Funding rates can be volatile
・Capital inefficient due to overcollateralization
・Liquidation risk
Lending Protocols
If we borrow an asset and market make with it, we will have net zero exposure to its price. There are many lending protocols to choose from, each with their own set of supported assets and fee structures.
Pros:
・Wider selection of assets than perps
Cons:
・Origination fees can be expensive and prohibit frequent adjustments
・Capital inefficient due to overcollateralization
・Liquidation risk
Permissionless Pools on Solend
The logic for eliminating price risk is the same as for lending protocols, but in this case Lifinity would offer a fixed APR that it would pay for borrowing an asset (with deposits capped) and it would not provide any collateral.
Pros:
・Extremely capital efficient since users provide the capital
・Pools can be created for any asset
Cons:
・Requires depositors to trust Lifinity
・May require Lifinity to offer high APRs to attract sufficient capital
The above strategies are possible precisely because the DNMM targets a fixed amount of an asset. If the amount of the asset in a pool were constantly fluctuating (as it does when a pool targets a 50/50 ratio as in v1), the perp position or amount of the asset borrowed would have to be adjusted continuously, resulting in higher complexity and greater fees.
Going market neutral comes with costs (funding rates, trading fees, borrowing costs, less capital efficiency, etc.), so for any given asset we will have to carefully consider whether it is worth it. For example, we will likely not consider it necessary to go delta neutral for major assets such as SOL, BTC, and ETH. The ability to eliminate long exposure is particularly useful for assets with much less of a Lindy effect (and thus whose future is much less certain) and/or have long-term structural sell pressure (e.g. tokens with heavy liquidity mining programs).
We currently have a few pools in which liquidity is provided by external LPs (e.g. RAY/SRM/GMT paired with USDC) since our community deemed it not worth having price exposure to the assets. In these cases it is the LPs rather than Lifinity who takes on the price risk. This is the most convenient for Lifinity, but the issue is that we are not always able to reach the ideal level of liquidity. Further, we earn a much smaller portion of the trading fees when it is not us who is providing the liquidity. Thus, it is pools like these that we expect to benefit the most from the ability to go delta neutral.
Testing our DNMM
We performed a test of our DNMM to see whether it could maintain balance during a volatile market and rebalance smoothly when the target pool balance is updated.
The test was performed on a SOL-USDT pool with $100k of deposits. The pool was not integrated with Jupiter and it was difficult to capture all of the available arbitrage trades (arbitrage bots are very competitive!), so we ran a bot that mimicked them. In other words, the pool balance was adjusted as if it had been arbitraged whenever an opportunity arose. This essentially tested the worst case scenario in terms of toxic flow.
The following results exclude trading fees and only look at MMP, as our main objective was to determine how the DNMM’s impermanent loss profile compared to CPMMs and holding.
On net, v2’s MMP outperformed both holding and CPMMs.
Before the first rebalancing, the pool performed the same as holding and slightly better than CPMMs. This is expected since the pool targets the same pool balance as holding while CPMMs experienced some IL from selling an appreciating asset.
After the first rebalancing, the pool performed significantly better than both holding and CPMMs. Price declined soon after the rebalancing, so v2 took profit where the other two did not.
After the second rebalancing, the pool performed slightly worse than holding but slightly better than CPMMs. After buying back at the lower price, price continued to decline, leading to holding outperforming.
While v2 proved successful in our test, the real challenge will be unidirectional market environments where price essentially moves only up or only down over prolonged periods. This is what v1 faced as SOL declined from ~$180 to the current price of ~$30 yet has been able to outperform both CPMMs and holding. Given our test results and our expectation of v2 outperforming v1 for the reasons explained in previous sections, we are confident that v2 will perform better than v1 even in challenging market conditions.
Rollout
Once v2 is integrated with Jupiter, we will begin to migrate our v1 pools to v2 gradually, starting with a v2 SOL-USDC pool that will run side by side with our v1 SOL-USDC pool to analyze their relative performances. If satisfactory, we will deprecate the v1 pool and migrate our other v1 pools to v2 pools as well. We’ll start by using fixed intervals for the rebalancing thresholds but will look to implement more intelligent methods in the future.
Please note that once we launch our v2 pools, LPs in our v1 pools will need to migrate their liquidity manually (withdraw from v1 and deposit in v2).
SDK: https://www.npmjs.com/package/@lifinity/sdk-v2
Program ID: 2wT8Yq49kHgDzXuPxZSaeLaH1qbmGXtEyPy64bL7aD3c
Conclusion
This upgrade is the beginning of an exciting new chapter for Lifinity. We look forward to seeing v2’s benefits for our token holders as well as the liquidity of tokens across the Solana ecosystem!
