Safely adding AMM Liquidity

[RickGriff]

The chicken bonds system needs to periodically add liquidity to the following Uniswap pairs:

• LQTY-ETH
• sLQTY-LQTY (possibly)

Challenge

LP deposits to AMM pairs can be sandwiched by trades, and value can be extracted by the sandwicher. The attacker performs the following steps around the LP deposit:

1. Front-run: attacker sell LQTY for sLQTY
2. LP makes deposit
3. Back-run: attacker sells sLQTY for LQTY

See this example attack for extractable profits:
https://docs.google.com/spreadsheets/d/1XsNaX9GlDDlS99Cw6zLvfj0gXuYGrHODRzTnXdBsGeI/edit#gid=0

Normal LP deposit mitigations

Uniswap provides the following advice for LPs to avoid depositing at a manipulated spot price:

• Form a belief about the true market price
• Do not rely on the spot price to determine token quantities added from inside a liquidity-add transaction
• Specify minimum quantities for each token (passed as params to addLiquidity) which enable the LP to effectively choose a tolerance for legitimate price movements in the time interval between their transaction being broadcast and mined.

LQTY-ETH LP deposit sandwich mitigations

The LQTY-ETH Uniswap pairs have signifiant liquidity, and if manipulated, the spot price can be readily arbitraged. Therefore a given spot price is likely to reflect the actual market price (since if it was manipulated, it would be rapidly arbed back to parity with the market price, and the attacker would lose value).

There are a few potential ways to mitigate an LP deposit sandwich attack:

• Manual: Perform manual LP deposits with minimum token quantities based on belief about current market price
• Algorithmic minimum amounts: the system makes regular deposits using a TWAP to determine the minimum token quantities. A TWAP based on a long enough interval makes spot price manipulation expensive.

sLQTY-LQTY LP deposit sandwich mitigations

At launch, and for an unknown duration thereafter (perhaps for the entire system lifetime) the sLQTY-LQTY AMM will have thin liquidity, making the TWAP cheap to manipulate.

Also, manual LP deposits should be ruled out, as the spot price of the AMM may effectively be the market price, since there will be very little sLQTY liquidity on other exchanges/DEXes. There will therefore be no trusted source of sLQTY price information outside the sLQTY-LQTY AMM.

Possible mitigations:

• Algorithmic minimum amounts and timing: use the price differential between spot and TWAP to determine when to perform the deposit

• Delay between LP deposit and back-run: enforce a 1-block delay after the system makes an LP deposit before further trades may occur. This can be implemented in the sLQTY ERC20 transfer function. This would ensure at least one block is mined between the system LP deposit and the "back-run" in the sandwich attack. This makes sandwiches non-risk-free, as they must span multiple blocks and thus can not be combined into a single flashbots / direct-to-miner bundle, and the attacker risks the AMM pool being arbed before their 2nd transaction is mined - making a net loss overall.

• Rate limits on trading: the attacker can only extract significant value from the sandwiched LP deposit when they first move the spot price by a large amount. (see sheet above). Trading frequency/volume could be limited in order to limit large spot price manipulations. This could be enforced in the sLQTY ERC20 transfer function.

We can differentiate between trades and LP deposits in the sLQTY ERC20 transfer function - restricting trades only, using the _to and _from params and a trusted sLQTYManager contract through which all LP deposits must originate. Pseudo-code for the logic is:

if from == uniswap (buy) -> restrict
if to == uniswap and from != sLQTYManager (sell) -> restrict
else allow