Liquidity providers (LPs) in Uniswap-like protocols are negatively exposed to price volatility of the pair of tokens in the pool. This is known as impermanent loss. We propose creating a synthetic asset using UMA with price
1-impermanent_loss so that LPs can hedge against price fluctuations.
Which metric will your synth track?
When someone adds liquidity to a Uniswap pool in the state
(balance0, balance1), they receive liquidity tokens, whose value will depend on the initial price
p0 = balance0 / balance1 as well as the price at any future time,
p. If the pool is large enough and the fees are zero, this value is equal to the (approximate) impermanent loss,
2*sqrt(p/p0) / (1 + p/p0) . Note that this figure is always less than 1 (so the LP can only lose if the price changes) and it’s log-symmetric (so the LP is equally impacted if the price goes up or down by a certain factor).
Because of this, adding liquidity to a Uniswap pool is only profitable if trading volume is high enough so that liquidity fees make up for any expected price volatility. Therefore, LPs should be willing to hedge against this price volatility. I propose creating a synthetic asset using UMA with price equal to
1 - impermanent_loss(pool, p0, p) so that LPs can construct a portfolio that is insensitive to price changes.
How will you get data for your metric?
Both the initial and current prices can be queried from Uniswap Time-Weighted Average Prices (TWAPs). These oracles are robust to transient price manipulation (e.g. through flash loans) because they aggregate historical prices, effectively computing a moving average.
What collateral would you use for this synthetic?
Several options could be explored. Two seem most natural:
- High market cap cryptocurrencies that are well-known, trusted, and liquid. ETH, wBTC, DAI, USDC, etc.
- Pool liquidity tokens. This would allow LPs to lock up the tokens in a contract as they receive them without needing to buy any other intermediate asset.
Describe how you would create this synthetic
This synthetic could be deployed either as an EMP or a perpetual contract.
A new price feed identifier would need to be added and implemented. It could inherit from
LPPriceFeed.js and be parametrized by a timestamp (indicating when the LP deposited liquidity in the pool) as well as the pool address. From these two parameters, the initial price
p0 can be retrieved and the synth price calculated as
1 - 2*sqrt(p/p0) / (1 + p/p0).
We note that every liquidity provider would be interested in entering a contract with
p0 equal to the price when they added liquidity to the pool. Since it may be impractical to deploy one contract for each price, we suggest deploying a set of contracts at fixed price intervals. This would give LPs only partial protection against impermanent loss, but it would make the contracts more liquid.
In order to create a smooth workflow, a dapp could be developed on top of Uniswap that automatically suggests available synths for that pool at the closest possible price. This way the LP could create a hedged position in just a couple of clicks.
Since Uniswap v3 allows LPs to put their capital in price bins to reduce exposure to extreme price volatility , we expect this product would be most interesting for protocols using Uniswap v2 core contracts. However, the product also offers protection against impermanent loss for v3 LPs inside the selected price range.