In the claimAndSwap
function, after the swap operation, the contract deposits the entire balance of the asset
token instead of the incremental amount resulting from the swap (balAfter - balBefore
). This could result in depositing unintended funds, including any pre-existing balance of the asset
token held by the contract.
https://github.com/Cyfrin/2024-12-alchemix/blob/5c19ee37df3aa7605bf782c9c40a482fd82adc67/src/StrategyMainnet.sol#L112
https://github.com/Cyfrin/2024-12-alchemix/blob/5c19ee37df3aa7605bf782c9c40a482fd82adc67/src/StrategyArb.sol#L77
https://github.com/Cyfrin/2024-12-alchemix/blob/5c19ee37df3aa7605bf782c9c40a482fd82adc67/src/StrategyOp.sol#L88
Function: claimAndSwap
Issue:
After the swap, the contract calculates balAfter - balBefore
to check slippage but deposits the entire asset
balance into the transmuter
contract instead of only the incremental amount resulting from the swap.
Implication:
If the contract already holds asset
tokens prior to calling claimAndSwap
, those tokens are also deposited unintentionally.
This behavior can lead to incorrect accounting or potential loss of operational flexibility since excess funds are locked in the transmuter
.
Code Affected:
Funds Lock: Any pre-existing asset
token balance in the contract will be unintentionally deposited, locking these funds in the transmuter
contract.
Operational Issues: Locked funds may cause operational inefficiencies, such as lack of liquidity in the contract for other purposes or delayed execution of subsequent operations requiring those funds.
Deposit Only Incremental Amount:
Modify the deposit line to deposit only the incremental amount resulting from the swap (balAfter - balBefore
) rather than the entire balance. For example:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.