The claimAndSwap function in StrategyMainnet.sol claims wETH from the Transmuter contract and attempts to swap this wETH to alETH utilizing Curve's pools. Due to the lack of liquidity in the Curve pools, it is easily manipulateable. Any user with enough wETH can "sell" wETH into the pool to cause a spike in alETH price in order to DoS the claimAndSwap function. Knowing the keeper will only make swaps at a premium, users can easily front-run this swap to benefit from this premium for themselves while causing the keepers transaction to revert or achieve less of a profit.
Taking a look at the claimAndSwap function:
It is observed that this function will claim wETH from the transmuter and swap this wETH for alETH to be deposited back into the transmuter contract. This function only swaps at a premium, meaning that amount of alETH received should be higher than the amount of wETH sent to the pool.
If we observe the alETH/wETH pool in Curve, we can see the following reserve amounts:
The low liquidity in the pool means that, a swap of 350.07917 wETH for 351.544 alETH will bring the alETH price in this pool to be greater than wETH, making it impossible to swap at a premium from now on. In this scenario, claimAndSwap function will no longer be swapping at a premium and revert due to the following check:
Attackers can now use their alETH to either swap back in Curve (a sandwich attack to cause DoS) or any other exchange or deposit into the transmuter contract to create an incentive for their attack. Even if the Curve swap happens through multiple pools, the swap route is set with the contract and is predictable, still making it easy to manipulate the pools that will be used.
This same attack is also possible in the other contracts in Arbitrum or Optimism, however, due to how hard it is to front-run in these chains and use of Ramses Exchange utilizing many pools that aren't always predicatable, makes it less likely. In short, malicious attacker can basically take advantage of the same trade that the keeper was intending to do while causing the keepers transaction to revert or in smaller swap amounts, cause it to benefit less from it's swap.
Another issue that arises due to the predictability of the Keeper's swap is that any user will be aware that this swap is going to increase alETH prices compared to wETH, user's can front-run the Keeper's swap to buy alETH from the same pool, cause Keeper to receive less alETH than it intended (while still satisfying the _minOut check) and back-run the Keeper's transaction to sell their alETH after Keeper's swap raises the alETH/wETH price.
The claimAndSwap function will fail to achieve it's purpose, can be DoS'd without much cost for the attacker.
Alternatively, users can benefit from the predictable nature of this swap to benefit themselves and cause the Keeper to receive less alETH than it thought it would receive.
Manual review
Utilize more ways of swapping wETH for alETH rather than only relying on the unstable Curve pools.
Additionally, add a buffer according to the amount being swapped that must be received on top of the _minOut
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.