Description

The _deployFunds function attempts to deposit _amount of asset (alETH) into the transmuter without checking whether the transmuter enforces a deposit cap or has enough capacity. If there is a deposit limit, the transmuter may revert when exceeding it. The strategy does not catch or handle this scenario gracefully, potentially causing user-facing transaction failures whenever that limit is reached.

Impact: Medium

1. User Deposits Blocked

   • Any new deposit that triggers _deployFunds might revert if the transmuter limit is already reached.

2. Confusion & Poor UX

   • Users see failed transactions, but the reason (transmuter deposit limit hit) is not surfaced or handled.

3. Protocol Downtime

   • Requires manual intervention to adjust limits or code updates, blocking normal operation until resolved.

Evidence from Code

No check or fallback if transmuter.deposit reverts due to exceeding limits.

Potential Failure Scenario

1. Deposit Limit Reached

   • The transmuter sets a global or per-address maximum deposit.

2. User Initiates Large Deposit

   • _deployFunds tries to deposit beyond the limit, causing the transmuter’s internal require to fail.

3. Revert with No Recovery

   • The transaction reverts, blocking the user’s deposit. The strategy has no fallback or partial deposit mechanism.

Recommended Mitigations

1. Check Available Deposit Capacity

   • Before calling transmuter.deposit, query how much can still be deposited. If _amount exceeds that, either deposit the max allowed or revert with a clear error message.

   uint256 remainingCapacity = transmuter.getRemainingCapacity();

   if (_amount > remainingCapacity) {

   // revert with informative message or deposit partial

   }

   ​

2. Partial Deposit Logic

   • If partial deposits are acceptable, the strategy can deposit only the allowed amount and keep the remainder in idle state or revert with a more user-friendly reason.

3. User-Facing Notifications

   • Return or emit an event clarifying that the transmuter is at capacity to reduce confusion.

4. Graceful Fallback

   • If deposit fails, consider an alternative approach (e.g., hold the tokens in the strategy until capacity is available or allow the user to cancel the deposit).

Conclusion

Without checking transmuter limits before depositing, _deployFunds can revert unexpectedly under heavy usage or tight deposit caps. Adding validation, partial deposit handling, or clearer user feedback prevents blocked user deposits and enhances the protocol’s reliability.