Withdrawal Arbitrage: The Risk of Attacks on the protocol
Last updated
Last updated
The protocol design poses a novel challenge: A unique attack “Withdrawal Arbitrage” happens as the input to the slippage function translates into coverage ratio. How can it occur?
Imagine there is a liquidity pool that contains assets and liabilities (deposits) of 100 initially.
Now there’s one whale who owns 20% of this pool. He is capable of generating some risk-free profit by simply making a series of transactions as below.
Step 1:
The whale buys 20% of the tokens in the pool by trading with another token. As a result, the coverage ratio falls to 0.8, since the amount of assets in the pool has fallen to 80.
There are still 100 tokens available for the LPs. When undertaking a transaction in the current situation, the user will suffer a small amount of slippage.
Step 2:
The whale withdraws all the liquidity (i.e. 20 tokens). The coverage ratio now falls to 0.75.
Step 3:
He swaps back the 20% of tokens he used in Step 1, reversing the original swap. The coverage ratio now goes back to 1.
The protocol incentivizes actions that pull the coverage ratio back or closer to the equilibrium. As this action brings the coverage ratio from 0.75 to a healthy position, the user is rewarded with a favorable exchange rate, in the form of positive slippage.
Note that the slippage fees charged in Step 1 involved a coverage ratio that changed from 1 to 0.8; while the slippage fees awarded in Step 3 involved a coverage ratio that changed from 0.75 to 1.
Due to the convexity of the slippage curve, the reward in Step 3 will be greater than the penalty in Step 1, generating a risk free profit. Hence, the user has successfully attacked the system. He can infinitely repeat steps 1 to 3 until the liquidity pool is drained. This kind of attack is called “Withdrawal Arbitrage”.