Alchemix Transmuter

Summary

A strict requirement in the claimAndSwap() (and related _swapUnderlyingToAsset()) functions across StrategyArb, StrategyMainnet, and StrategyOp can cause a Denial of Service (DoS) under certain market conditions. Specifically, the condition:

only permits swaps when a strict “premium” ratio of alETH to WETH is achievable. If the real market conditions do not allow _minOut > _amountClaim, the swap reverts and can repeatedly fail. This leads to inoperability in the strategy’s core functionality—converting WETH back to alETH and depositing it into the transmuter—causing a potential operational lock or severe disruption in yield generation.

Note: While the original codebase might treat this restriction as a “feature” to secure profitable swaps only, it can unintentionally lock the strategy under unfavorable or even near-1:1 market conditions.

Vulnerability Details

1. Location in the Codebase

• StrategyMainnet.sol - claimAndSwap

• StrategyOp.sol - _swapUnderlyingToAsset

• StrategyArb.sol - _swapUnderlyingToAsset

2. Why the Condition Causes a DoS

• Strict Premium Requirement: Swaps only execute if _minOut (the desired output amount in alETH) strictly exceeds the input WETH amount. If the market price of alETH vs. WETH does not allow a ratio > 1:1 (i.e., no real premium), the transaction reverts.

• Repeated Failures: Subsequent attempts at claimAndSwap() or _swapUnderlyingToAsset() with the same or similar parameters also revert, effectively blocking the strategy from its main function—turning claimed WETH back into alETH.

• Potential “Lock-In” of Funds: Depending on whether the claim portion and the swap are atomic, users (or keepers) cannot proceed with normal operations if they must always expect a premium. This can leave funds unutilized or stuck in a state where no reallocation occurs.

Counterargument (Design Intent):
A defender might say that “requiring a premium is by design: the strategy only executes profitable swaps.” However, this design choice leads to a scenario where the strategy cannot operate at all if market conditions never (or rarely) yield a premium, hence a practical DoS in real-world use.

Impact

1. Yield Generation Block

   • Because the strategy cannot re-deposit alETH (if the swap never completes), any yield mechanism tied to having alETH in the transmuter stalls. This can severely impact overall earnings.

2. Partial or Extended Protocol Lock

   • While not all of Alchemix necessarily stops functioning, the affected strategies become inoperative, preventing normal claim-and-swap cycles.

   • In severe or prolonged depeg conditions (e.g., alETH < WETH but not sufficiently below to yield a premium), repeated reverts can create a practical lock of the strategy functionality—a form of DoS.

3. Capital Efficiency Loss

   • WETH that is intended to be swapped to alETH remains “unconverted,” reducing the protocol’s capital utilization.

   • Even if the entire transaction reverts (and thus the WETH remains in the transmuter or elsewhere), the strategy cannot progress to generate yield.

4. Extended Depeg Scenarios

   • If alETH is trading consistently below 1:1 with WETH, or the transmuter’s slow conversion is drawn out, the condition _minOut > _amountClaim becomes harder to satisfy. This exacerbates the blocking effect.

Severity Justification:
The inability to perform intended operations can be classified as a high-severity DoS or major operational risk, impacting user confidence and the protocol’s overall functionality.

Proof of Concept (PoC)

Test Code Exposing the Vulnerability

The following suite of tests in Foundry reproduces various DoS scenarios. Each test sets up an environment with mocks, assigns a claimable balance in the Transmuter, and verifies whether the swap fails (reverts) or succeeds.

Test Results

The logs confirm that in 1:1 or sub-1:1 scenarios, transactions fail with minOut too low, causing an operational lock for the strategy:

All tests passed; reverts confirm the DoS behavior when no premium >1:1 is available.

Test Code and Mitigation Results

To avoid the DoS, the verification > _amountClaim is relaxed to >= _amountClaim. Two new tests are added to validate the mitigation:

Mitigation Test Results

• It is confirmed that after relaxing the requirement to require(_minOut >= _amountClaim, "minOut condition not met"), swaps can be executed at 1:1 without reverting.

• This eliminates the strict DoS caused by the “premium > 1:1” condition.

• However, if the pool objectively cannot provide sufficient tokens (due to actual slippage), the transaction will still revert, which is expected behavior for a slippage check, not a design-induced DoS.

Observations

1. Depeg Scenarios: The original vulnerability causes a permanent revert if no premium above 1:1 exists. With the mitigation, the strategy can continue operating even at parity or slight negative deviations.

2. Slippage Checks Are Retained: The mitigation does not remove the revert in cases where liquidity or minimum output is not met, but it prevents a “total lock” caused solely by requiring >1:1.

3. Security Impact: Allowing 1:1 removes the DoS risk, but projects can implement additional safeguards to ensure swaps are not executed at excessive losses (e.g., using dynamic _minOut, oracles, etc.).

Conclusion

This PoC demonstrates how the restriction require(_minOut > _amountClaim) in claimAndSwap() causes a Denial of Service when the alETH/WETH ratio does not exceed 1:1. The tests highlight the failure in multiple scenarios (1:1, sub-1:1, and insufficient router capacity) and subsequently validate the fix by applying a >= check instead of >. This change resolves the DoS in 1:1 scenarios, allowing the strategy to function uninterrupted under normal market conditions.

In summary:

• Vulnerability: All swaps are blocked if no premium > 1:1 is available.

• Mitigation: Change require(_minOut > _amountClaim) to require(_minOut >= _amountClaim) with an updated message, such as minOut condition not met.

• Result: Swaps at 1:1 (or close) are allowed without automatic reverts, preventing the strategy from becoming inoperable.

Tools Used

1. Manual Code Review

   • Examined _swapUnderlyingToAsset() and claimAndSwap() logic to identify the strict requirement.

   • Correlated lines with the repository’s main branch to ensure accuracy.

2. Foundry

   • Created test scenarios in Foundry to simulate calls to claimAndSwap() or _swapUnderlyingToAsset() with _minOut > _amountClaim.

   • Verified repeated transaction reverts in environments mimicking actual user or keeper calls.

Recommendations

1. Relax or Remove the Strict > _amountClaim Check

   • Currently:

     require(_minOut > _amountClaim, "minOut too low");

   • Suggestion:

     require(_minOut >= _amountClaim, "minOut condition not met");

   • Outcome: Allows a 1:1 swap (or a near match) without reverting. This prevents a total block if the premium is not strictly above 1.

2. Incorporate a Flexible Slippage / Oracle Mechanism

   • Dynamically compute _minOut based on real-time on-chain data or oracles, adding a small buffer for slippage.

   • Example: If 1 WETH ~= 0.99 alETH, allow _minOut = 0.98 * _amountClaim. This avoids a revert while still enforcing a safety margin.

3. Introduce a Fallback / Standby Mode

   • If market conditions do not allow profitable swaps (premium > 1:1), permit a fallback path:

     • Deposit WETH directly into a safe holding pattern, or

     • Wait for a better ratio but without blocking all further interactions.

4. “Force Swap” or Management Override

   • Let onlyManagement or a similar privileged role bypass the strict check in emergencies.

   • This ensures the strategy does not remain stuck if the premium is never reached.

5. Parameterizable Route Updates

   • The current code references multiple routes. Ensure that management or keepers can update _minOut or route parameters on demand, preventing a scenario where unchangeable, overly strict slippage settings cause permanent lock.

Rationale:
While some operators might prefer only profitable swaps, a total inability to execute any swap under less-than-ideal conditions is more damaging in the long term. Introducing the above improvements would prevent a “hard revert” scenario, thereby avoiding DoS.

Conclusion

By relaxing the rigid “premium-only” requirement or adding fallback logic, the protocol can avoid an unintended DoS that renders these Alchemix-based strategies inoperable under certain (potentially prolonged) market conditions. This ensures capital efficiency, continuous yield generation, and overall protocol stability.