DeFiFoundrySolidity
16,653 OP
View results
Submission Details
Severity: low
Invalid

Insufficient Slippage Protection and Front-Running Vulnerability in claimAndSwap Function

Summary

The claimAndSwap function in the smart contract includes a basic check to prevent slippage by ensuring that the swap results in at least a minimum amount of alETH (_minOut). However, this protection does not account for potential front-running attacks, where an attacker could observe the transaction and manipulate the price before it is executed. This could lead to the keeper receiving less alETH than anticipated, although the function does prevent outright losses.

Vulnerability Details

function claimAndSwap(uint256 _amountClaim, uint256 _minOut, IRamsesRouter.route[] calldata _path) external onlyKeepers {
transmuter.claim(_amountClaim, address(this));
uint256 balBefore = asset.balanceOf(address(this));
_swapUnderlyingToAsset(_amountClaim, _minOut, _path);
uint256 balAfter = asset.balanceOf(address(this));
require((balAfter - balBefore) >= _minOut, "Slippage too high");
transmuter.deposit(asset.balanceOf(address(this)), address(this));
}

Example Scenario:

  • Suppose the keeper intends to swap 10 WETH for alETH with a minimum output of 90 alETH (_minOut = 90).

  • An attacker observes the transaction and places their own swap just before the keeper’s transaction is confirmed, increasing the price of WETH and reducing the amount of alETH the keeper will receive.

  • The keeper's swap still succeeds, but the slippage protection (require((balAfter - balBefore) >= _minOut)) ensures that they don’t lose money. However, the final amount of alETH received might be less than originally expected because of the attacker's price manipulation.

  • The attacker profits from the price change they caused.

Impact: If front-running occurs, the keeper may receive less alETH than expected, though they will not experience a loss due to the slippage protection. However, the anticipated benefits could be significantly reduced.

Tools Used: Manual Review

Recommendations:

Add Time Delay or Timelock: Introduce a short delay before the swap execution to mitigate front-running attacks. This delay could allow the transaction to stabilize and reduce the risk of price manipulation.

Prioritize Gas Fees for Keepers: Implement a mechanism to prioritize gas fees for keepers’ transactions to ensure their swaps execute before any front-running attempts.

Updates

Lead Judging Commences

inallhonesty Lead Judge
8 months ago

Appeal created

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

[INVALID] Front-Running Vulnerability in claimAndSwap

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.