Issue: No Oracle-Based or On-Chain Price Check

Description

The code in functions like _swapUnderlyingToAsset and _harvestAndReport references a TODO: check that price is better than 1:1, but relies solely on the minOut parameter provided by a keeper. There’s no actual on-chain pricing or oracle feed to validate whether the swap rate is fair (e.g., comparing WETH to alETH based on a trusted market price). As a result, the strategy depends entirely on keepers to set an honest minOut threshold, which can be manipulated.

Impact: Medium to High

1. Potential Value Extraction / Poor Swap Rates

   • A dishonest keeper could artificially lower minOut, effectively executing swaps at a disadvantageous rate, siphoning value.

2. No Automatic Peg Enforcement

   • If alETH is intended to track WETH 1:1 (or with a certain premium), there is no direct mechanism to reject swaps that deviate significantly from the intended peg.

3. Overreliance on Keeper Integrity

   • The protocol’s profitability and correctness hinge on keepers setting minOut accurately.

Evidence from Code

Example Pseudocode:

The TODO note highlights the absence of a formal mechanism to confirm a favorable exchange rate beyond the keeper-supplied minOut.

Potential Attack / Exploit Scenario

1. Keeper Malfeasance

   • A malicious keeper sets minOut just slightly above _amount, locking in a poor exchange rate that falls below a true market price.

2. Value Drain Over Time

   • Each time a swap occurs, a fraction of the strategy’s value is siphoned away. The keeper arbitrages the difference on a separate address or route.

3. Protocol or Investor Losses

   • The strategy consistently realizes below-market returns, eroding user capital until discovered.

Recommended Mitigations

1. Integrate an On-Chain Oracle

   • Use a reputable oracle (e.g., Chainlink) to fetch WETH/alETH pricing. Verify the final swap ratio does not deviate beyond a specified slippage threshold.

   // Example Pseudocode:

   uint256 oraclePrice = IPriceFeed(priceFeedAddress).getPriceWETHtoALETH();

   uint256 expectedOut = _amount * oraclePrice / 1e18;

   require(actualOut >= expectedOut * (1e4 - maxSlippageBps) / 1e4, "Excessive slippage");

   ​

2. Designate a Peg or Fair-Price Mechanism

   • If the protocol’s design requires alETH to be near 1:1 with WETH, ensure swaps are disallowed if the implied price drifts too far from peg.

3. Stiffer Keeper Validation

   • Impose stricter checks on minOut (e.g., disallow minOut being only barely above _amount if a higher reference price is available).

   • Optionally, consider multiple keepers or a multi-sig approach for certain large swaps.

4. Timelocks / Monitoring

   • Emit events for all swaps showing the minOut, final output, and relevant pricing data so any suspiciously low or high values are quickly detectable.

Conc

Without an oracle feed or robust on-chain price check, the protocol relies on keepers to set a fair minOut. This trust model risks suboptimal or exploitative trades if the keeper acts maliciously or inputs incorrect data. Implementing an oracle-based reference price, stricter slippage controls, or multi-keeper verification reduces this threat and helps ensure alETH remains fairly valued against WETH.