# šBBOX AMM

Virtual CLMM

BBOX uses the Concentrated Liquidity Market Maker (CLMM) as the underlying price discovery mechanism. Any pool state in BBOX at a particular time can be modeled as an aggregate of individual Liquidity Provider (LP) positions, each characterized by the coordinate system$(p,L, p_a, p_b)$, where:

$p$ is the mark price.

$L$is the liquidity parameter computed over the Constant Function Market Maker (CFMM) Curve, determined at the time of the LP position creation.

$p_a, p_b$ are the respective lower bound and upper bound for the designated liquidity position to be actively provided.

At any pool state, one can also compute the real balance of the virtual token (Perp contract) and the numeraire asset via the following re-parameterization:

Liquidity Provision Range | Balance of Virtual Token X | Balance of the Numeraire |
---|---|---|

$p \leq p_a$ | $\frac{L}{\sqrt{p_a}} - \frac{L}{\sqrt{p_b}}$ | $0$ |

$p \in [p_a, p_b]$ | $\frac{L}{\sqrt{p_a}} - \frac{L}{\sqrt{p_b}}$ | $L\sqrt{p} - L\sqrt{p_a}$ |

$p \geq p_b$ | $0$ | $L\sqrt{p_b} - L \sqrt{p_a}$ |

### Example: LP Alice Supplies (Leveraged) Liquidity in the Market

Suppose that Alice, a market maker, wants to provide leveraged liquidity. Alice will need to determine:

The price range $[p_a, p_b]$ in which she wants to concentrate her liquidity.

The amount of liquidity $L$ sheās willing to provide, determined via the re-parameterization rule specified in the table above.

Then Alice is faced with the following three scenarios when trying to provide liquidity:

Place a range order above the current tick price $p, i.e. p \leq p_a$ , and Alice is willing to

**sell the asset.**Place a range order around the current tick price $p, i.e. p \in [p_a, p_b]$ , and Alice is willing to

**buy and sell the asset**.Place a range order below the current tick price $p, i.e. p \geq p_b$ , and Alice is willing to

**buy the asset.**

In cases 1 and 2, Alice will receive the (leveraged) token assets as a loan. These tokens must be paid back when the liquidity position is closed. If the asset price appreciates, the amount of USDC needed to cover the loan also increases, potentially triggering liquidation.

**Scenario 1****: **$p \leq p_a$

**Scenario 1**

**:**$p \leq p_a$

Suppose that Alice wants to provide 1000 USDC with 2x leverage. Alice will first interact with the *Trade Engine,* which the engine will:

Places the 1000 USDC collateral into the vault

Mints and loans 1.09 V-ETH and put the loan as Aliceās cost basis

Puts the 1.09 V-ETH in the pre-designated LP range $[p_a, p_b]$, where the liquidity parameter $L$ gets calculated via $1.09 = L(\frac{1}{\sqrt{p_a}} - \frac{1}{\sqrt{p_b}}) \Longleftrightarrow L = \frac{1.09}{ (\frac{1}{\sqrt{p_a}} - \frac{1}{\sqrt{p_b}}) }$

**Scenario 2****: **$p \in [p_a, p_b]$

**Scenario 2**

**:**$p \in [p_a, p_b]$

Similarly, if Alice wants to provide 1000 USDC with 2x leverage around the mark price. The *Trade Engine* will make the following modifications:

Places the 1000 USDC collateral into the vault

Alice decides to supply 1000 V-USDC, then the vault will compute the amount of V-ETH that needs to be loaned from $L = \frac{1000}{\sqrt{p} - \sqrt{p_a}}$, and the amount of V-ETH to be deployed is equal to $L(\frac{1}{\sqrt{p}} - \frac{1}{\sqrt{p_b}})$. Alice can also mark the desired liquidity position by adjusting the leverage.

Puts liquidity into the pre-designated range $[p_a, p_b]$ and records the liquidity parameter $L$.

**Scenario 3****: **$p \geq p_b$

Last, if Alice wants to provide 1000 USDC with 2x leverage this time in a range below the mark price. The *Trade Engine* will conduct the following:

Place the 1000 USDC collateral into the vault

Mints 2000 V-USDC and records it as the position cost in Aliceās PnL account

Puts the 2000 V-USDC in the pre-designated LP range $[p_a, p_b]$, where the liquidity parameter $L$ gets calculated via $L = \frac{2000}{(\sqrt{p_b} - \sqrt{p_a})}$.

Last updated