Alchemix Transmuter

01. Relevant GitHub Links

• https://github.com/Cyfrin/2024-12-alchemix/blob/82798f4891e41959eef866bd1d4cb44fc1e26439/src/StrategyMainnet.sol#L92C1-L113C6

02. Summary

The claimAndSwap function of the StrategyMainnet contract does not include a deadline parameter or any deadline validation. This omission can leave users vulnerable to front-running, MEV exploitation, and execution under outdated or unfavorable market conditions. Without a deadline, transactions may remain pending indefinitely, allowing adversaries to manipulate their execution timing and extract value at the user’s expense.

03. Vulnerability Details

In standard Automated Market Maker (AMM) or swapping protocols, including a deadline parameter ensures that the trade is executed promptly or not at all. The absence of deadline checks in the claimAndSwap function means that if a transaction sits in the mempool for an extended period, its parameters (such as minimum output) may become stale. This scenario creates opportunities for miners, validators, or MEV bots to front-run or back-run these trades strategically, exploiting users by forcing slippage or executing the trade under less favorable prices.

While other swap functions in related contracts (like on the Optimism or Arbitrum networks) do employ deadlines by passing block.timestamp as a parameter to their swapping functions, this mainnet implementation does not. This inconsistency further emphasizes that the omission may be an oversight rather than an intentional design choice.

04. Impact

• MEV Exploitation: Without a deadline, malicious actors have a wider time window to inject their transactions and exploit price differences or slippage, extracting profit at users’ expense.

• Reduced User Confidence: The inability to rely on timely execution damages user trust in the protocol’s security and fairness.

05. Proof of Concept or Scenario

Below is a hypothetical scenario illustrating how the absence of deadline checks in the claimAndSwap function could lead to negative outcomes for the user and create opportunities for MEV exploitation:

User Scenario (Without Deadline Protection):

1. Initial Intention:
   The Keeper intends to convert underlying tokens into the synthetic asset ALETH via the claimAndSwap function. She expects the market rate to remain relatively stable and sets _minOut at a value that allows a small margin for slippage, ensuring she will receive at least a certain amount of ALETH.

2. Transaction Submission:
   The Keeper submits her transaction with a low gas fee, expecting it to be executed in a timely manner. However, due to network congestion or sudden spikes in gas prices, her transaction remains pending in the mempool for an extended period—possibly hours or even days.

3. Market Conditions Change:
   While the Keeper’s transaction sits unconfirmed, the market dynamics shift dramatically. The relative value of the underlying asset she is swapping out of, as well as that of ALETH, may have changed. Although her _minOut parameter ensures some minimum quantity of ALETH, the economic value of this output could now be significantly lower in terms of other stable assets or fiat equivalents.

4. Delayed Execution, Unaware User:
   Eventually, when gas prices drop or conditions become favorable for inclusion, a miner includes the Keeper’s transaction in a block. At this point, the Keeper might have forgotten about her pending transaction or believed it had already failed. Because the function does not enforce a strict deadline, the swap occurs at outdated prices, causing the Keeper to receive fewer funds than she would have if the trade had been executed promptly. In other words, the Keeper has inadvertently executed a suboptimal trade.

MEV Exploitation Scenario (Malicious Actor Steps In):

1. Lingering Transaction Detected by MEV Bots:
   MEV bots constantly scan the mempool for profitable opportunities. They notice the Keeper’s pending claimAndSwap transaction, which is locked with an outdated _minOut parameter. Originally, _minOut was a safeguard based on the price environment when the Keeper signed the transaction, but after significant time, it now effectively allows for a large slippage margin.

2. Market Changes Favor Exploitation:
   Suppose the underlying asset that the Keeper is swapping has surged in value relative to ALETH after setting the _minOut. Even though the _minOut might still be met, it no longer reflects a fair current-market minimum. The MEV bot sees this as an opening to insert its own transactions around the Keeper’s swap.

3. Sandwich Attack Execution:
   The MEV bot can front-run the Keeper’s swap by pushing up the price of the output asset (or manipulating liquidity conditions) and then back-run it by selling back at a profit. Because the Keeper’s transaction does not have a time-bound protection, the bot has the luxury of waiting for the optimal moment to execute this sandwich. The result: the MEV bot profits from the Keeper’s outdated and now unfavorable _minOut parameter, while the Keeper ends up with a significantly worse effective rate.

4. Resulting Losses for the Keeper:
   By the time the Keeper’s transaction is finally processed, she receives her minimum output—technically fulfilling the _minOut condition—but the value of that output is heavily diminished. The MEV bot’s interference, facilitated by the lack of a deadline, leaves the Keeper with a trade execution that is far worse than what she intended. Her trust in the system erodes as she realizes the vulnerability stemmed from the absence of a straightforward safeguard: a deadline parameter.

06. Tools Used

Manual Code Review and Foundry

07. Recommended Mitigation