Omnipool Design
The Hydration 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
Hub token
The Omnipool uses H2O 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 H2O.
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 .
Swap Execution
In version 1, the prices behave as though each TKN1/H2O pool is a constant product CFMM, although other CFMMs continue to be under investigation.
Let be the quantity of H2O 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/H2O fee , we have
The H2O 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 H2O.
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 H2O 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 H2O being traded into the pool for TKN), the LPs are entitled to some of that H2O. On the other hand, if the price of TKN goes down (via TKN being sold to the pool for H2O), 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 H2O). 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 H2O was traded into the Omnipool for TKN, so the protocol has extra H2O go give the LP. Specifically,
Note that since , the H2O 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/H2O price, not to prices of other tokens in the Omnipool (except indirectly via H2O).