58572 sc high liquidation of account collateral doesn t subtract mytsharesdeposited which creates bad debt in the system and causes insolvency

Submitted on Nov 3rd 2025 at 09:42:10 UTC by @Tarnishedx0 for Audit Comp | Alchemix V3arrow-up-right

  • Report ID: #58572

  • Report Type: Smart Contract

  • Report severity: High

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

  • Impacts:

    • Protocol insolvency

Description

Brief/Intro

Liquidation of account collateral doesn't subtract _mytSharesDeposited which creates bad debt in the system and causes insolvency.

Vulnerability Details

_mytSharesDeposited is defined as:

    /// @dev Total yield tokens deposited
    /// This is used to differentiate between tokens deposited into a CDP and balance of the contract
    uint256 private _mytSharesDeposited;

When liquidation happens, collateral is liquidated and transferred to the transmuter.

But, _mytSharesDeposited is not updated accordingly. Also, during liquidation if only _forceRepay() happens:

Some portion + fee of account.CollateralBalance is repaid and subtracted but not accounted in the _mytSharesDeposited. Thus, _mytSharesDeposited inaccurately represents the total amount of collateral in the contract and is inflated.

Impact Details

_mytSharesDeposited is used to calculate the totalUnderlyingValue of the AlchemistV3Contract.

This is directly used in the Transmuter.sol contract to calculate badDebtRatio.

Now the overinflated _mytSharesDeposited will also inflate the denominator which in turn will deflate the badDebtRatio. This badDebtRatio is directly used to calculate the amount that users can redeem if a system is in bad debt.

Thus, even when system is in a bad Debt state, Users will be able to claim more than they should due to bad debt ratio being calculated incorrectly and less than it should. Thus, again increasing bad debt and causing protocol insolvency.

References

All the code snippets used above can be verified here: claimRedemption()#Transmuter.sol: https://github.com/alchemix-finance/v3-poc/blob/a192ab313c81ba3ab621d9ca1ee000110fbdd1e9/src/Transmuter.sol#L191-L266

_doLiquidation()#AlchemistV3.sol: https://github.com/alchemix-finance/v3-poc/blob/a192ab313c81ba3ab621d9ca1ee000110fbdd1e9/src/AlchemistV3.sol#L852-L894

_forceRepay()#AlchemistV3.sol:https://github.com/alchemix-finance/v3-poc/blob/a192ab313c81ba3ab621d9ca1ee000110fbdd1e9/src/AlchemistV3.sol#L738-L782

Proof of Concept

Proof of Concept

Here is a PoC to prove that after liquidation _mytSharesDeposited doesn't change.

Paste this in the AlchemistV3.t.sol file, set up $MAINNET_RPC_URL and run it using:

To prove how not updating _mytSharesDeposited results in users redeeming more than they should:

Paste both of these tests in Transmuter.t.sol and run it using the following commands:

If we look at the output of first test where totalUnderlyingValue is accurate:

Amount Received First: 30000000000000000012

And the output of second test where totalUnderlyingValue is not accurate and inflated:

Amount Received Second: 35000000000000000010

Thus, it is proven that users will receive more than they should due to inaccurate _mytSharesDeposited accounting and cause bad debt to the protocol which will result in protocol insolvency.

Was this helpful?