Alchemix Transmuter

Summary

There's accounting mismatch between the balanceDeployed() function of StrategyOp.sol and the actual deposit process.

The balanceDeployed() function incorrectly includes the underlying token balance in its calculation. When _deployFunds() is called, it deposits the asset (alETH) into the transmuter, but balanceDeployed() also counts any WETH balance. This creates a situation where:

1. The actual deployed amount is only tracked in transmuter.getUnexchangedBalance()

2. But balanceDeployed() adds the underlying token balance which is not actually deployed

3. This breaks the specification's requirement that deployment must increase balance by exactly the input amount

The vulnerability exists because of incorrect accounting assumptions about what constitutes "deployed" funds. The underlying token (WETH) sitting in the contract should not be considered deployed since it hasn't been put to work in the transmuter.

This can lead to:

• Incorrect total value calculations

• Misleading deployment status reporting

• Potential manipulation of strategy metrics

Vulnerability Details

The issue is located within the implementation of the claimAndSwap function across all three strategy variants (StrategyOp.sol, StrategyMainnet.sol, and StrategyArb.sol).

In StrategyOp.sol#claimAndSwap

The balance check is performed incorrectly in the sequence of operations. The function:

1. Claims WETH from transmuter

2. Records alETH balance

3. Performs swap

4. Verifies balance change

This creates a sudden vulnerability because:

• The initial balance check happens after claiming but before swapping

• An attacker could manipulate the contract's alETH balance between these steps

• The slippage check becomes ineffective as it's based on potentially manipulated values

Impact across implementations:

• StrategyMainnet.sol (Ethereum) claimAndSwap

• StrategyArb.sol (Arbitrum): claimAndSwap

The vulnerability affects all three chains (Optimism, Ethereum, Arbitrum) and could lead to:

• Loss of funds through manipulated swaps

• Incorrect slippage protection

• Potential sandwich attacks during the swap process

Impact

The bug is caused by incorrect sequencing of operations in the claimAndSwap function across all strategy variants. The root issue originates from taking balance measurements at the wrong time during the swap process.

The problematic sequence:

1. Claims WETH from transmuter

2. Takes initial alETH balance measurement

3. Performs swap

4. Takes final balance measurement

5. Checks slippage

This sequence creates a window where the balance check can be manipulated because:

• The initial balance is measured after claiming but before swapping

• The final balance check only verifies the difference between these two points

• The actual swap outcome could be manipulated while still passing the slippage check

The core issue is that the balance checks don't properly encapsulate the entire operation from start to finish. Instead, they only measure a subset of the transaction window, making the slippage protection ineffective.

This vulnerability exists because the code assumes that measuring balances around just the swap operation is sufficient for slippage protection. However, this assumption is incorrect as it doesn't account for the entire state change from the initial pre-claim state to the final post-swap state.

The issue affects all three strategy variants (StrategyOp.sol, StrategyMainnet.sol, StrategyArb.sol) since they all implement the same flawed balance checking pattern, just with different DEX routers (Velodrome, Curve, Ramses).

Recommendations