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

Mixing Token Types in claimAndSwap Function Leads to Misleading Slippage Validation

Summary
The claimAndSwap function suffers from a logical oversight where it assumes the same asset is being measured before and after the swap. This leads to potential confusion when calculating balances, as the tokens involved (WETH claimed vs. alETH received) are not explicitly differentiated. Such an assumption may introduce bugs or incorrect behavior, especially in cases where pre-existing contract balances or conversion rates affect the calculation**.**

Vulnerability Details
The function claimAndSwap calculates slippage and validates the outcome of a token swap using the difference between balAfter and balBefore:

require((balAfter - balBefore) >= _minOut, "Slippage too high");

Token Type Confusion: The balance measured before (balBefore) is for WETH (claimed from transmuter), while the balance measured after (balAfter) includes alETH (received after the swap). Since WETH and alETH are distinct tokens, directly comparing their quantities is logically flawed unless they are fungible (e.g., have a 1:1 value correspondence).

  • Misleading Calculations: If the contract already holds alETH before the function call, the balBefore calculation includes unrelated funds. This can lead to misleading slippage checks, as the difference (balAfter - balBefore) reflects more than just the result of the current swap.

  • Value-Based Slippage Not Accounted: The function assumes a direct 1:1 ratio between WETH and alETH, which may not hold in real-world scenarios if conversion rates fluctuate or fees are involved. A large discrepancy in value could bypass or fail the validation incorrectly.

Example:
The contract starts with 50 alETH.

  • _amountClaim = 20 WETH, _minOut = 21 alETH.

  • After claiming, balBefore is calculated as 50 (existing alETH balance).

  • The swap results in 22 alETH, and balAfter is calculated as 72.

  • The slippage check calculates (balAfter - balBefore) = 22, which is greater than _minOut (21), so it passes. However:

    • The comparison implicitly assumes that the difference of 22 alETH corresponds directly to the value of 20 WETH swapped, which is not validated.

Impact:
Incorrect Slippage Validation: If WETH and alETH have differing values or conversion rates, the slippage check may pass or fail incorrectly, leading to potential economic loss or function reverts.

Tools Used

Manual Review

Recommendations

Explicitly Track Token Types: Use separate variables for WETH (claimed) and alETH (received) to ensure clarity in calculations.

Updates

Lead Judging Commences

inallhonesty Lead Judge
8 months ago

Appeal created

inallhonesty Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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