Automatic market-makers (AMMs) are one of the major innovations which decentralized finance has brought. They use the maths function to price assets when exchanging two or more tokens. First, Uniswap brought markets created by $x·y = k$ invariant which doesn’t make any assumption about the pricing of underlying assets and spreads liquidity across all prices evenly. Next, Curve introduced the stableswap invariant which allowed to focus most of the liquidity around price 1.0, a very useful feature for creating stablecoin-to-stablecoin liquidity.

Since the inception of AMMs, there have been several notable improvements in AMMs. One such improvement is Curve V2 which introduced CurveCrypto Invariant and can be used to create liquidity for tokens that are not necessarily pegged to each other i.e. their price changes frequently w.r.t. each other.

Limitation of AMMs in Leverage Trading

All these innovations work perfectly fine when it comes to token swaps but it is difficult to apply the same to derivatives, such as perpetual contracts. As derivative trading involves leverage, the position value will be bounded by the pool size, and also the liquidity providers might suffer from high impermanent loss.

To overcome this problem, Perpetual protocol introduced the concept of Virtual AMMs or vAMMs. As the “virtual” part of vAMM implies, there is no real asset pool stored inside the vAMM itself. Instead, the real asset is stored in a smart contract vault that manages all of the collateral backing the vAMM; and the vAMM is just used for pricing the perps. In fact, that is how the Mark Price is determined. The perpetual protocol uses $x*y = k$ (Uniswap v2) invariant in their vAMM. Perpetual protocol V2 is planned to be utilizing the UniswapV3 which relies on makers who provide liquidity around tight ranges and move liquidity accordingly as price changes.

Hubble vAMM

At Hubble, we are using CurveCrypto Invariant in our vAMM. As described in Curve V2 whitepaper, it is way more efficient than $x · y = k$ invariant and concentrates liquidity given by the current “internal oracle” price but only moves that price when the loss is smaller than part of the profit which the system makes. This creates 5 − 10 times higher liquidity than the Uniswap invariant.

Here is an example of how it works under the hood.

Unique Properties of Hubble vAMM

Repegging

In contrast to Uniswap V3, Curve V2 uses an internal oracle to concentrate liquidity and the repegging algorithm takes care of the price update. This makes our vAMM 'smart' enough to concentrate liquidity around the current price by itself.

Since Curve V2 is not path independent, there is a need for Makers in the system to counter the profit/loss due to that. Makers add virtual liquidity to the pool on leverage and earn a part of the trading fee. The good part is, makers don't have to worry about the price range in which they have to provide liquidity to deepen the liquidity around the current price. The repegging algorithm deepens liquidity around current price automatically and hence makers earn fee regardless of the price change. During highly volatile market, makers don't have to worry about getting out of range and lose out on pool fee.

Maths behind Hubble vAMM

The main advantage of using this vAMM is that the repegging algorithm takes care of liquidity concentration around the current price.

Repegging Algorithm

The repegging profit/loss is quantified by constant-product invariant at the equilibrium point. For a pool with $n$ tokens, it is given as

$$ X_{c p}=\left(\prod \frac{D}{n p_{i}}\right)^{\frac{1}{n}} $$