Add test case for proposed attack vector (uniswapDeposit sandwich) #213
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This issue proposes an attack vector where a
uniswapDeposit
(or other Uni V3 mint) is sandwiched between two swaps -- one that pushes away from the TWAP, and another that moves back towards it. More specifically, aBorrower
's borrowed assets are used to create a very thin range order (limit order) just below the manipulated price, causing it to buy ETH at far higher than fair value (2x in the example given).Assuming a USDC/WETH pool for simplicity, a naive health check implementation could look like this:
The position's value is calculated using the TWAP. This is good. The danger is that underlying amounts are determined by the instantaneous
slot0.sqrtPriceX96
. This allows an attacker to manipulate the(uint256 usdc, uint256 eth)
tuple so that it swings from (1M USDC, 0 ETH) to (0 USDC, 1M / X ETH) for arbitrary values of X. Essentially, the protocol has assumed X≅TWAP when it's not.Aloe II does not make this mistake. Our code looks something like this:
The key is that we (a) find underlying amounts and (b) combine them to get total value at the same price (sqrtProbePrice). And we do not use the instantaneous
slot0
variables for this at all. Getting back to the {buys ETH at twice its fair price} example: that can certainly happen in aBorrower
, and theBorrower
would certainly lose money. But our health check accounts for that hypothetical loss before it happens such that atomically-dangerous positions cannot be constructed.This new test simply demonstrates that.
Spreadsheet with results for various sandwich conditions:
https://docs.google.com/spreadsheets/d/11TUjflXETGLKv3VuI0OcLYEpbi-2b2ipGfvS8cISMbA/edit?usp=sharing