Alchemix Transmuter

Summary and Impact

The strategy attempts to enforce a premium on token swaps by using a naive check require(minOut > _amount) within the claimAndSwap function. This check presumes that simply demanding minOut to exceed the input amount guarantees a profit or premium. However, it fails to reference any real price feeds, oracles, or stable external metrics to ensure that the protocol actually gains value. As a result, attackers (e.g., dishonest keepers) can manipulate on-chain prices, exploit minor market dislocations, or rely on MEV techniques to fulfill this condition without providing genuine premium value.

This flaw introduces a medium-level vulnerability:

• Attackers can orchestrate trades so that the contract receives nominally “more” tokens but actually less real value, violating the intended invariant that all swaps must occur at a premium.

• Over time, such attacks can systematically erode protocol reserves.

• Though not trivially exploitable without market manipulation, the risk remains substantial. Attackers with MEV capabilities or access to flash loans could exploit transient price movements and ensure that the protocol always gets a worse effective exchange rate than intended.

Given the complexity and cost of orchestrating such attacks, this vulnerability may not be as catastrophic as a direct critical loss. Yet, it stands as a clear security fail against the project’s stated invariants—namely that the system must never lose out on its keepers’ operations. The deficiency in verifying genuine economic value against documented expectations elevates the issue from low to medium severity.

Vulnerability Details

Root Cause: The key issue lies in a simplistic assumption about minOut. The code only ensures minOut > _amount, ignoring the asset’s external price and real-world value. Without referencing an oracle or a time-weighted average price, the contract can be tricked into accepting trades that, on paper, look profitable but are effectively losing money due to manipulated exchange rates.

Code Snippet (From StrategyOp.sol, illustrating the problematic requirement):

The comment acknowledges the need to ensure a price better than 1:1, but the implemented check is insufficient. It does not consult any oracle or verify actual market conditions.

Test Code Snippet (Relevant Excerpt):

Step-by-Step Logic of Exploit:

1. Preparation: The attacker (keeper) monitors pools or sets up transient liquidity conditions where alETH trades slightly below WETH.

2. Invocation: The keeper calls claimAndSwap with minOut just over _amount, ensuring the require passes.

3. Execution: Due to manipulated on-chain conditions, the actual received alETH may be worth less than the WETH claimed. The contract is unaware since it never checks the true exchange rate.

4. Aftermath: The strategy’s reserves diminish in real economic terms while all checks appear superficially satisfied.

This breaks a core invariant: the system expects that demanding a “premium” ensures profitable or at least non-loss trades. Without verifiable price data, minOut alone is not sufficient to guarantee this outcome.

Tools Used

• Manual Review.

• Foundry.

Recommendations

To properly enforce a premium and align with documented invariants, the contract should integrate either an on-chain price oracle or a time-weighted average price (TWAP) mechanism. Such a safeguard would ensure that minOut corresponds to real economic value rather than a nominal amount. Specifically:

• Oracle Integration: Incorporate a price feed (e.g., Chainlink) to determine the fair market value of alETH relative to WETH. Require minOut to reflect a genuine premium based on this external reference.

• TWAP Checks: Use a TWAP oracle from reputable DEXes or AMMs, comparing the expected minOut against historical price data to prevent flash-loan or MEV-based manipulations.