Vaults liquidating strategy

General Chat Technical Discussion
1

Screen Shot 2020-08-21 at 15.56.41
Screen Shot 2020-08-21 at 15.56.411652×922 82.3 KB

This code snippet is taken from the DForceDAI strategy (the Dai vault). It always uses the same path in Uniswap to swap dForce token for dai. This strategy is vulnerable to front-running and might be exploited by arbitrageurs (in a sandwich like attack where they swap dForce for dai just before the strategy contract does, thereby reducing its price, then the yStrategy contract sells at a lower price then it should and then the arbitrager buys back the dForce token for cheap, increasing their holding. Any arbitrageur willing to have exposure to dForce increases its holding easily on the expense of the yStrategy contract).

Mitigation:
What if we had 2 paths hard coded into the strategy and chose one of them pseudo-randomly according to a hash that takes as input: (i) some state from the relevant uniswap pools (eg. current balances), and (ii) the block’s timestamp (in which the transaction was included). This would make it impossible for an arbitrageur to simulate (off-chain and in advance) the path that is going to be used by the strategy contract.

Can something like this work?

3 Likes
2

yeah thats fucked, bots could take all the dForce if they held enough to sandwich it to 0

fix by adding a minimum DAI received argument to harvest function

@andre.cronje

3

I guess this a simpler way to mitigate the issue. But I like my construction which is clean and does not require to query an oracle before calling harvest().

This needs to be taker care of in all vaults.