Alchemix Transmuter

Summary

The claimAndSwap function is susceptible to transaction reordering, which could exploit the protocol's reliance on optimistic rollups for execution ordering. Without sufficient safeguards such as dynamic slippage protection, the protocol risks swaps executing at manipulated prices, reducing user yields and exposing the protocol to economic inefficiencies.

This vulnerability arises from predictable transaction parameters and static slippage checks (_minOut), which fail to adapt to real-time market conditions. Mitigation through slippage controls and improved execution validation is recommended.

Technical Details

Code Reference

The claimAndSwap function facilitates swaps via preconfigured routes, relying on Keepers to execute without incorporating additional validations:

The Issue Identified

1. Static Slippage Checks:

   • _minOut is user-defined and static, failing to account for dynamic market conditions, price fluctuations, or manipulation.

2. Sequencer Transaction Ordering Risk:

   • Centralized sequencers on Optimism can reorder or delay transactions, allowing Keepers or colluding actors to execute trades at unfavorable prices for the protocol.

3. Lack of Additional Safeguards:

   • No mechanism ensures swaps occur at optimal rates based on current market conditions (e.g., real-time oracle integration).

Exploitation Scenarios

Scenario 1: Suboptimal Execution Due to Price Volatility (Which is common to happen in volatile market)

1. Setup:

   • The protocol relies on Keepers to execute a claimAndSwap with _amountClaim = 1,000 WETH and _minOut = 980 alETH.

2. Execution:

   • A Keeper submits the transaction during a period of high market volatility.

   • Before execution, market conditions shift, reducing the value of the trade to 950 alETH.

3. Impact:

   • The protocol suffers a slippage loss of 30 alETH, impacting yields and returns.

Scenario 2: Transaction Reordering by Colluding Keepers

1. Setup:

   • A Keeper submits a claimAndSwap transaction with _amountClaim = 500 WETH and _minOut = 490 alETH.

2. Execution:

   • A colluding Keeper submits a higher-priority transaction to execute a large WETH-alETH trade, manipulating the price.

   • The original Keeper’s transaction is processed after the price manipulation, causing it to execute at an unfavorable rate.

3. Impact:

   • The manipulated price results in a reduced swap return, impacting protocol efficiency.

Impact Analysis

Severity: Medium to High

1. Financial Impact:

   Suboptimal swaps and manipulated prices reduce yields and user returns.

2. Operational Impact:

   Reordering of transactions disrupts the protocol’s intended yield-generation process.

3. Reputational Impact:

   Loss of trust in the protocol’s ability to ensure secure and optimal swaps.

Root Cause Analysis

1. Predictable Transaction Parameters:

   _amountClaim and _minOut are fixed and exposed in execution, leaving the protocol vulnerable to dynamic price shifts.

2. Reliance on Centralized Sequencer:

   The protocol assumes benign behavior from the sequencer without validating execution outcomes.

3. Lack of Market-Aware Safeguards:

   Swap execution relies solely on Keeper-defined parameters without incorporating real-time price data.

Mitigation Recommendations

1. Dynamic Slippage Controls

• Mechanism:

  • Use real-time on-chain oracles to calculate _minOut dynamically based on market conditions.

  uint256 oraclePrice = getOraclePrice();

  uint256 dynamicMinOut = (_amountClaim * oraclePrice) / 1e18;

  require(dynamicMinOut <= _minOut, "Slippage too high");

  ​

2. Commit-Reveal for Swap Execution

• Mechanism:

  • Implement a commit-reveal scheme to obfuscate transaction details before execution, reducing predictability.

  bytes32 public lastCommit;

  ​

  function commitSwap(bytes32 commitHash) external onlyKeepers {

  lastCommit = commitHash;

  }

  ​

  function revealSwap(uint256 _amountClaim, uint256 _minOut, uint256 _routeNumber, bytes32 commitHash) external onlyKeepers {

  require(keccak256(abi.encode(_amountClaim, _minOut, _routeNumber)) == lastCommit, "Invalid commit");

  // Execute swap logic

  }

  ​

3. Enforce Execution Time Windows

• Mechanism:

  • Set a strict time window for swap execution, reverting transactions that exceed this limit.

  uint256 public constant MAX_EXECUTION_DELAY = 5 minutes;

  ​

  function claimAndSwap(uint256 _amountClaim, uint256 _minOut, uint256 _routeNumber) external onlyKeepers {

  uint256 startTimestamp = block.timestamp;

  // Execution logic

  require(block.timestamp <= startTimestamp + MAX_EXECUTION_DELAY, "Execution delayed");

  }

  ​

4. Incorporate Anti-Sandwiching Logic

• Mechanism:

  • Introduce checks to detect and revert transactions with sudden price deviations during execution.

Proof of Concept (PoC)

Reproducing the Issue

1. Deploy the contract and simulate a transaction submission with _amountClaim = 1,000 WETH and _minOut = 980 alETH.

2. Execute a price manipulation or delayed transaction reordering in a sequencer simulation.

3. Observe the impact on the executed swap, with reduced outputs or higher slippage.

Verifying Mitigation

1. Implement dynamic slippage controls and commit-reveal logic.

2. Submit transactions with hidden parameters and validate correct execution against the commit phase.

3. Ensure time-bound execution prevents delayed or manipulated swaps.