# Hyperdrive LP Issue

## LP with buffer

When a user **adds liquidity** to the Hyperdrive AMM, we calculate the LP shares as follows:

$$
\Delta l = \frac{\Delta z \cdot l}{z - b_z}
$$

where,

- $\Delta l$ is the LP shares calculated for someone adding liqudity

- $\Delta z$ is the amount off new liquidity added to the pool

- $l$ is the existing supply of LP shares

- $z$ is the existing amount of liquiidity in the pool

- $b_z$ represents the share buffer and is used to ensure that the pool holds enough shares to honor the redemption of existing longs

When a user **removes liquidity**, we calculate the amount of base shares their LP shares are worth as follows:

$$
\Delta x = c \cdot (z - b_z) \cdot \frac{\Delta l}{l}
$$

where,

- $\Delta l$ is the LP shares the user is removing from the pool
- $\Delta x$ is the amount of base the user receives for redeeming $\Delta l$
- $c$ denotes the current share price
- $b_z$ represents the share buffer and is used to ensure that the pool holds enough shares to honor the redemption of existing longs
- $l$ is the existing supply of LP shares

These calculationss for adding/removing liquidity do a good job of ensuring that new LPs share of the pool doesn't account for the longs that were open before they joined. Unfortunately, it opens LPs up to an attack that can be described as follows:

- Alice opens the max long possible
- Alice adds a large amount of liquidity to the pool (e.g. 100x the current liquidity in the pool)
- Alice close her long position
- Alice exits the pool for a profit

This attack is demonstrated in [this notebook](https://colab.research.google.com/drive/1l9VodnQTmUt3GqJvPVbXzNAUyh1N1YR2?usp=sharing) under the cell titled `LP Exploit Example With Buffer`

## LP without buffer

The attack described in the previous section can be mitigated by removing $b_z$ from the calculation that determines the $\Delta l$ issued for adding $\Delta z$ liquidity to the pool. When a user **adds liquidity** we can calculate the $\Delta l$ as follows:

$$
\Delta l = \frac{\Delta z \cdot l}{z}
$$

> Note: The calculation for **removing liquidity** remains the same before.

This modification only looks at the available liquidity in the pool and gives the new LP the fraction their new liquidity represents.

[This notebook](https://colab.research.google.com/drive/1l9VodnQTmUt3GqJvPVbXzNAUyh1N1YR2?usp=sharing) under the cell titled `LP Exploit Example Without Buffer` demonstrates how this fixes the issue.

Unfortunately, when we remove $b_z$ from the calculation, new LPs are accountable for long positions that were opened prior to them joining the pool. The worst possible scenario here is if the new LPer tries to add liquidity to the pool when there are a large amount of mature bonds that haven't been redeemed. This means that the existing LPs have already collected the variable interest from the term and owe the fixed interest to thee user's that will eventually redeem their bonds. If the new user LPs at that time they inherit the outstanding debt represented in $b_z$, but didn't get a chance to earn the variable interest.