Protecting Retail Capital in DeFi - The Promise of Single-Sided Liquidity
Exploring the 5 ways that Single-Sided Liquidity Provisioning (SSLP) can be set-up, how SSLP can help retail investors lose less capital while providing liquidity and areas of further research.
Retail investors losing money is bad for crypto. One of the main goals for builders in crypto should be to create structurally safer products for retail investors. I think single-sided liquidity provisioning potentially holds this promise to create structurally safer standards for retail liquidity providers (LP) moving forward, helping to minimize principal loss, and reduce impermanent loss, while providing liquidity to the markets for trading. I believe that structurally safer yield-bearing instruments in DeFi will be a key catalyst for the next bull market.
First, a quick recap - Liquidity provisioning represents one of the main ways to earn yield in crypto while holding a basket of tokens. Liquidity provisioning works off the concept of automated market makers (AMMs), which allow anyone to create pools of two pairs of assets that instantly provide liquidity to that trading pair. This pool allows others to trade between the two assets deposited, allowing traders more liquidity to freely trade out of positions and allowing depositors to earn transaction fees. Liquidity providers typically need to deposit 50% in value of each asset. In the early days of frantic trading activity, liquidity provisioning was a significant source of yield.
Thanks for reading Messy Problems! Subscribe for free to receive new posts and support my work.
However, as liquidity provisioning became more competitive, it became clear that it was very easy to lose money as a liquidity provider (LP) without active sophisticated management. The main reason for this was impermanent loss, where due to the nature of trading pools, you ended up with more of 1 of the 2 assets that was worth less over time, as traders traded out of the less profitable asset.
Key risks also included design flaws for newly developed liquidity pools, transaction fee rewards that may be denominated in the platform’s native tokens (which may depreciate quickly), as well as providing liquidity for tokens that may be rugpulls and be ‘dumped’ on, draining liquidity and leaving LPs with the worthless tokens.
The solution is two-fold - proactive or structural. From a proactive perspective, you either help create complex derivatives (or one-click strategies) and trading interfaces to help sophisticated traders hedge their exposure to create delta-neutral strategies. This exists, is a decent solution, but can sometimes require LPs to have a deep mathematical understanding of the type of exposures they are getting themselves into or require proactive management. This is more feasible for professional rather than retail traders. Simpler solutions like NIL Protocol attempts to automate much of the hedging of potential impermanent loss. There are, however, some structural obstacles (potentially solvable) that come with attempting to hedge IL, including the difficulty in predicting/calculating IL.
The second solution is structurally single-sided liquidity provisioning where their retail liquidity providers can provide liquidity for trading pools, with guaranteed preservation of principal as well as some level of transaction fee revenue, through structures that mechanically prevent impermanent loss (as opposed to hedging against it).
The development of single-sided liquidity has so far been relatively slow but I’ve noted 5 ways that single-sided liquidity can be developed, with the aim of structurally reducing the losses that derive from impermanent loss.
5 types of structural single-sided liquidity
Method 1 - Stableswaps
The first, and most obvious way to provide single-sided liquidity provisioning (‘SSLP’) is to only provide this for 1:1 assets. 1:1 assets are asset pairs where the value between the two assets should always be fixed (i.e. USDC<>USDT, ETH<>WETH, WBTC<>renBTC, etc), due to the inherent relative value of both assets.
Coupled with a Curve-type stableswap AMM design (which reduces but does not eliminates slippage between 1:1 assets), you can essentially create a situation where LPs can reasonably expect to not encounter any impermanent loss since they would always receive value (through either token) that are equal in relative value.
The downside of this approach is that it is inherently limited to providing liquidity for assets that have a 1:1 equivalent, which is the minority of tokens. It also forces LPs to bear the de-peg risk of the counterparty, which became increasingly common through StETH, UST, etc, which would have caused losses to counterparties in the pool. Protocols that employ this include Stargate (which has focused only on blue-chip assets like ETH, USDT, USDC), and Platypus Finance (which uses oracles to monitor and halt trading during de-peg events).
Method 2 - Native Token SSLP
The second way is to provide what I term native-token single-sided liquidity pairing. This can be seen in protocols like Bancor and MonoX.
LPs would essentially deposit against a native token provided by the underlying platform. For Bancor, you would provide liquidity against the BNT governance token. For MonoX, you would provide liquidity against the vUNIT native token created by MonoX.
The thinking is that in case of impermanence loss, the platform can print more of its native tokens at a lower rate than the revenue coming from transaction fees.
The flaw of this model was of course, that this created a constant downward sell pressure, despite calculations to the contrary. Furthermore, the platform was essentially creating a leveraged bet on continued revenue streams boosting native-token prices. In case of either a general DeFi sell-off or a huge drop in native-token prices, the cost to cover impermanent loss would exceed what the protocol could print in native tokens. This happened to Bancor during the 2022 DeFi sell-off, and Bancor at the time of writing, has still suspended operations.
MonoX suffered a critical hack that is unrelated to its economic design, and has recently relaunched. Interestingly though, vUNIT is not a governance token, but rather a representation of protocol-owned liquidity and assets. Arguably, a similar flaw might have happened here during downward markets affecting liquidity and asset availability.
Tokemak arguably has a similar design, although with a seemingly more sustainable model. LPs can stake on a single-sided basis into a pool that is paired with the native token TOKE. TOKE has utility as a bribery token similar to Convex, thus providing utility and a base value for the token. It remains a question if this will be sustainable in the long run.
Method 3 - Customizable IL Pairing
The third way would be what I call customizable IL pairing (“IL pairing”). IL pairing is essentially the acknowledgment that there are players in the market who are willing to take on some form of price fluctuation but willing to provide liquidity for long-term purposes.
This includes a lot of the DAO liquidity management solutions like Rift Finance. Here, the key insight is that DAOs are willing to provide liquidity for one side of the liquidity pair in their own native tokens and be willing to absorb as much of the IL that happens to the entire pool. The reason for this is that this is a more capital-efficient way to provide liquidity for those who are looking to trade their DAO token (as opposed to paying for a market maker, or immediately selling their DAO token for ETH, depressing token prices, and providing both ETH and the DAO token to trade within a pool).
Of particular interest is the fact that Rift allows the DAO to absorb any IL that may emerge in the pool. The ratio of losses to be first absorbed by the DAO can be customized (hence customizable IL pairing), but the default on Rift is for the LP to have completed principal protection of capital. LPs are therefore protected on their principal LP amount unless the token pair value drops by 75%.
So, the three rules defining the return profile for Rift's initial vaults are the following:
The ETH side gets off back at least the APY floor.
The DAO side gets at most their ceiling.
The ETH side gets any additional yield beyond requirements (1) and (2).
We will increasingly see mechanics like this that shift the burden of impermanent loss to one party or the other within an AMM pool. Arguably, a similar principle is at play when we think about fixed versus variable interest rate bond products as we saw in Ondo Finance where the burden of IL is essentially shifted to the variable interest rate bondholder.
I believe single-sided liquidity management in this design mechanic will eventually become a core primitive that sits below bond instruments, interest rate swaps, and other emerging instruments.
Method 4: Halting unprofitable trades through oracles and dynamic concentrated liquidity
The whole idea of an AMM is that you can bootstrap liquidity and thus trading, by allowing price discovery to occur naturally through arbitrageurs.
Each trade that is used to facilitate arbitrage (that takes a view on prices of assets in other markets to understand if an arbitrage opportunity exists), fundamentally represents a loss.
Given that AMMs do not exist in a vacuum, and that an AMM can take reference to prices occurring in other markets, it is, therefore, possible to act against arbitrageurs by only allowing LP-favorable trades to occur in the pool.
This can be done through a mixture of two things - dynamic concentrated liquidity and through oracle backstops.
Maverick Protocol is one of the pioneers in dynamic concentrated liquidity, and there are easy ways that the math behind dynamic concentrated liquidity would be broadly useful for single-sided liquidity mechanics that aim to reduce or democratize access to low IL liquidity provisioning.
GooseFX has an interesting model where LPs get to benefit from dynamic concentrated liquidity provisioning to reduce the arbitraging that happens on their AMMs (since liquidity will be dynamically concentrated around an oracle-set price, which should be the market price as taken from other parts of the market). Furthermore, an oracle backstop solution exists where the oracle will charge traders of the AMM the worst price from the market price (as judged by the oracle from prices in the other markets) and the price within the AMM. This ensures that there will be no situation where LPs are providing liquidity at a price that allows them to be taken advantage of. There are limitations with relying on oracle systems such as front-running and centralization risk, which however should be solvable over time.
Method 5: Pool-Specific Market Making
Hashflow employs an interesting model for single-sided liquidity by allowing users to lend into pools that are issued as capital to market-makers to create liquidity for the pools that users lent capital into.
This is slightly controversial in my head, because if you’re issuing capital to market makers, then that is simply a quasi-unsecured lending marketplace, or conversely not an ‘automated’ market maker. Traditional lending protocols also lend to market makers who generate yield by providing liquidity on CeFi and DeFi mechanics. Theoretically, this makes the risk profile no different from uncollateralized permissioned lenders like Clearpool who ultimately lend out to market makers.
Impermanent loss is therefore structurally protected against by a centralized entity that is actively hedging and providing liquidity in a smart, non-automated way. In another way, this is similar to Method #4, but relies on a centralized entity as opposed to a decentralized algorithm to help avoid impermanent loss. There’s a very useful feedback loop where the platform fundamentally attracts liquidity for its own trading pools, and LPs are simply indirectly providing liquidity to an identified pool.
If we fundamentally are optimizing for safer structures for liquidity provisioning, Hashflow’s model should be something we can look to as a potential model for replication.
What I don’t consider single-sided liquidity provisioning
The most misleading form of single-sided liquidity provisioning are the ones provided by Alpha Homora/ KyberSwap/ Thorchain. Despite an option to provide only one side of the token pair, what instead happens is that the deposited assets get swapped for the counter-token pair at the point of deposit, forcing the LP to gain exposure to the token pair, which is against the principle of single-sided liquidity provisioning (and thus single-asset price exposure as far as practicable).
LP Provisioning and the swap at the point of deposit for Thorchain. Note the difference in total supply and the assets in position.
Areas of further research/other ideas
If we think about what IL is - it is essentially a short on volatility. Low/no volatility pairs (i.e. a token pair of stablecoins like USDC<>USDT) do not suffer IL.
The total loss by a liquidity provider is also a net position (i.e. one only suffers loss when the impermanent losses of the value of the assets in the pool exceed the transaction fees gathered by LPs to a pool). This means that IL is also predicated on time. Exiting a liquidity pool soon after a period of high volatility will likely mean crystalizing IL, as opposed to a point in time in the future.
This means that better tooling should be provided to retail LPs that are embedded into AMM pools to allow LPs to know when they can exit positions. This can take the form of forced lock-ups by AMMs (likely controversial), and projection calculators (to allow users to automatically calculate when and whether it can mathematically recover IL losses from their LP position). We can also consider other issues such as capital efficiency (ROI of revenue for TVL provided) calculators to understand how much liquidity within a dynamic concentrated liquidity band is being appropriately utilized, instead of laying idly not collecting fees with sub-optimal concentrated liquidity.
As a separate point, there is an increased appreciation that liquidity provisioning is not only a type of financial instrument/position that an investor is taking but a position that can be embedded into other types of financial instruments (bonds, interest rate swaps, etc).
Maturity around single-sided liquidity provisioning promises to usher in a new age of safer DeFi, especially for retail users. I am particularly excited by the way that DeFi will mature in a safer way while creating the foundation that will unlock further financial instruments.
I believe a mixture of Method 3, Method 4, and Method 5, enhanced by embedded calculator tools and potentially fixed term lock-ups, are directionally correct and will help to structurally reduce the amount of capital lost through impermanent loss. I would love to talk to anyone who has done any thinking or building around SSLP, and if there are any mechanics that are missing, please do ping me at firstname.lastname@example.org.
Thanks to James Key, Lauren Stephanian, Ronald Jan Schuurs, Ash Zenhom, GooseFX, Maverick Protocol, etc for comments/inputs. Comments do not imply endorsement.
Thanks for reading Messy Problems! Subscribe for free to receive new posts and support my work.