The HydraDX Omnipool is a novel type of AMM which concentrates all liquidity in a single trading pool, thus unlocking an array of efficiencies. This doc contains a mathematical specification of the mechanics which power the Omnipool.
The Omnipool uses LRNA as a "hub" token through which all trades are routed, avoiding the segmentation of liquidity inherent to AMMs which require LPs to provide liquidity for a pair of tokens. Both transaction fees and partial impermanent loss mitigation are paid out in LRNA.
A note on notation
Throughout this page, we will refer to the change in some amount as . When is a pool variable (e.g. the quantity of some asset in the pool), we adopt the convention that is negative if the pool variable is decreasing (e.g. some amount of the asset is leaving the pool) and is positive if the pool variable is increasing (e.g. some amount of the asset is entering the pool). In particular, note that this means when we consider a swap of of one asset for of another asset, one of these will be negative.
A user variable meanwhile will have the sign convention that flows to the user are denoted by positive while flows away from the user are denoted by negative . In particular, for a token transfer to/from the pool for some token , we will have .
We will also adopt the notational convention that .
In version 1, the prices behave as though each TKN1/LRNA pool is a constant product CFMM, although other CFMMs continue to be under investigation.
Let be the quantity of LRNA in the TKN1 pool and be the quantity of TKN1. Suppose a trader stipulates they wish to sell of TKN1 for TKN2. Then , so with asset fee and protocol/LRNA fee , we have
The LRNA or "protocol" fee is (which is positive since is negative) and the asset fee is .
Providing Liquidity to Omnipool
Liquidity providers (LPs) may contribute a single asset, and in return receive a share of the pool of that asset. When the LP removes liquidity, they may receive both the asset they provided and LRNA.
Single-asset liquidity providers for some TKN cannot always be given only the token they contributed, because if the price of TKN has gone up and substantial amounts of TKN have left the pool, LPs of TKN are splitting a much smaller pot. The protocol, meanwhile, has a much larger amount of LRNA that has been traded in for TKN. Instead of simply allowing LPs to take the loss, the protocol splits the matched pool with the LPs. If the price of TKN goes up (via LRNA being traded into the pool for TKN), the LPs are entitled to some of that LRNA. On the other hand, if the price of TKN goes down (via TKN being sold to the pool for LRNA), the protocol is entitled to some TKN.
Let be the current price of TKN, the price when an LP initially provided liquidity, the number of shares the LP wishes to withdraw, the number of TKN shares owned by the protocol.
Note that since shares are burned when liquidity is removed, .
If the price of TKN has gone down (), the LP will be withdrawing only TKN (no LRNA). The protocol will take control of some TKN shares from them, while some shares will be burned.
We first calculate the change to the protocol share ownership of TKN:
Note that if (the price of TKN has gone down), is positive, meaning that the protocol is claiming some of the shares from the LP. If , the protocol claims no asset shares from the LP.
Next, we find the number of shares to burn:
We can then calculate the total amount of TKN the LP receives, which is simply proportional:
If , lots of LRNA was traded into the Omnipool for TKN, so the protocol has extra LRNA go give the LP. Specifically,
Note that since , the LRNA that is not distributed to the LP who is withdrawing liquidity is burned by the protocol.
Impermanent Loss of Single-Asset Liquidity Provider
Given the mechanisms described above, the "impermanent loss" of a single asset LP is
The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).