58462 sc low incorrect post withdraw balance measurement causes false loss reporting and mis accounting in morphoyearnogwethstrategy deallocate

Submitted on Nov 2nd 2025 at 13:57:46 UTC by @Kissiahmyo for Audit Comp | Alchemix V3arrow-up-right

  • Report ID: #58462

  • Report Type: Smart Contract

  • Report severity: Low

  • Target: https://github.com/alchemix-finance/v3-poc/blob/immunefi_audit/src/strategies/mainnet/MorphoYearnOGWETH.sol

  • Impacts:

    • Smart contract unable to operate due to lack of token funds

Description

Brief/Intro

The MorphoYearnOGWETHStrategy._deallocate function reads wethBalanceBefore and wethBalanceAfter after calling vault.withdraw, making both variables reflect the same post-withdraw balance. Because of this, wethRedeemed is computed as 0 in almost all cases, leading to unconditional “deallocation loss” events and breaking the intended sanity checks that rely on the redeemed amount. The bug undermines accurate accounting of redemptions, can trigger false alarms in monitoring, and may interact poorly with automated governance or operational tooling that reacts to perceived losses.

Vulnerability Details

A read-order bug in the WETH redemption path miscomputes the redeemed amount by measuring pre- and post-withdraw balances only after the withdrawal has occurred. This produces 0 for the redeemed delta, leading to perpetual false “loss” events and unreliable deallocation accounting. In production, this can degrade monitoring fidelity, cause erroneous operational responses, and reduce confidence in strategy behavior, especially under stress.

  • Affected file: src/strategies/mainnet/MorphoYearnOGWETH.sol

  • Function: _deallocate(uint256 amount)

v3-poc/src/strategies/mainnet/MorphoYearnOGWETH.sol::_deallocate#L50-L53arrow-up-right

Both wethBalanceBefore and wethBalanceAfter are measured after vault.withdraw. They are effectively identical and equal to the post-withdraw balance. wethRedeemedbecomes0 (after - after), regardless of how much was actually redeemed. The event StrategyDeallocationLoss is emitted spuriously on every call (wethRedeemed < amount`). The intended sanity check to ensure enough assets were redeemed is no longer based on the true delta; it compares the post-withdraw balance twice, losing the information about the actual redemption amount.

Impact Details

False loss reporting: Every _deallocate call emits a “loss” event even when exact or greater-than-expected amounts were redeemed. This pollutes operational telemetry and dashboards. Broken observability: Redeemed amounts are not captured correctly, weakening post-trade analysis, reconciliation, and anomaly detection. Potential operational griefing: If downstream tooling reacts to the event (alerts, halts, automated policy changes), normal operation can be disrupted despite healthy redemptions.

Recommendations

Fix read order in _deallocate: Read before balance, perform vault.withdraw, read after balance, compute redeemed = after - before.

References

  • File: v3-poc-immunefi_audit/src/strategies/mainnet/MorphoYearnOGWETH.sol

  • Function: _deallocate(uint256 amount) (lines surrounding vault.withdraw and balance reads)

v3-poc/src/strategies/mainnet/MorphoYearnOGWETH.sol::_deallocate#L50-L53arrow-up-right

Proof of Concept

Proof of Concept

This test case specifically targets a known issue related to the incorrect order of balance checks within the _deallocate function. The purpose of this test is to demonstrate that, when the deallocate function is invoked under the circumstances where the bug occurs, the system should revert the transaction.

Please add the test test_poc_withdraw_bug_incorrect_balance_check_order() at the file of MorphoYearnOGWETHStrategy.t.sol which can run successfully

Was this helpful?