Smart contract unable to operate due to lack of token funds
Description
Brief/Intro
The AlchemistV3 protocol contains a critical accounting vulnerability where the internal _mytSharesDeposited variable fails to be decremented when MYT tokens are transferred out during forced repayments (_forceRepay()) and liquidations (_doLiquidation()). This accounting mismatch causes the _getTotalUnderlyingValue() function to return progressively overstated Total Value Locked (TVL) calculations, which compound with each liquidation event. As the discrepancy between reported and actual token balances grows, the smart contract becomes unable to operate properly due to insufficient token funds relative to what the protocol believes it holds, ultimately leading to operational failure and potential system-wide dysfunction.
Vulnerability Details
The vulnerability stems from incomplete accounting maintenance in two critical functions within the AlchemistV3 contract. The contract uses an internal variable _mytSharesDeposited (line 134) to track the total MYT shares deposited:
uint256private _mytSharesDeposited;
This variable is used by the _getTotalUnderlyingValue() function (line 1238-1241) to calculate the protocol's TVL:
The contract correctly maintains this accounting variable in most operations:
Incremented during deposit() at line 383: _mytSharesDeposited += amount;
Decremented during withdraw() at line 410: _mytSharesDeposited -= amount;
Decremented for protocol fees in multiple locations
However, two critical functions transfer MYT tokens out without updating the accounting:
Location 1: _forceRepay() Function (Line 779)
Location 2: _doLiquidation() Function (Lines 875, 879)
Technical Impact Chain
Accounting Discrepancy: Each liquidation/forced repayment creates a growing gap between _mytSharesDeposited and actual MYT token balance
TVL Overstatement: _getTotalUnderlyingValue() returns inflated values based on the incorrect _mytSharesDeposited
Dependent Function Failures: Functions like totalValue() (line 1073) and collateralization calculations rely on accurate TVL data
Operational Breakdown: As the discrepancy grows, operations requiring actual token transfers fail when the contract believes it has more tokens than it actually possesses
Vulnerability Reproduction Path
User deposits 50,000 MYT shares → _mytSharesDeposited = 50,000
User borrows against collateral and creates transmuter redemption
Liquidation occurs → _forceRepay() transfers 50 MYT shares to Transmuter
Actual MYT balance: 49,950 shares (correctly decreased)
Token Fund Shortage: The contract believes it holds more MYT tokens than it actually possesses
Operation Failures: Functions requiring token transfers fail when attempting to move non-existent tokens
Progressive Deterioration: Each liquidation/forced repayment event worsens the discrepancy
Financial Quantification
Per-Event Impact: Each liquidation creates a permanent accounting gap equivalent to the liquidated amount
Cumulative Effect: The discrepancy compounds with protocol usage - active protocols with frequent liquidations will accumulate larger discrepancies faster
System-Wide Risk: Affects all users as the core TVL calculation becomes increasingly unreliable
Operational Consequences
Withdrawal Failures: Users may be unable to withdraw funds when the contract's perceived balance exceeds actual balance
Liquidation System Breakdown: Incorrect TVL calculations affect liquidation triggers and calculations