When the system becomes undercollateralized and a position is liquidated, MYT backing is moved from the Alchemist to the Transmuter. Due to a bookkeeping bug, that MYT is effectively counted twice in the claim-scaling math, so identical redemption positions can receive a larger payout after liquidation than they would have before. A user can split redemptions, wait for/trigger liquidation, then claim the “after” leg to siphon unclaimed yield—overpaying early claimants at the expense of later claimants and the protocol. This can be repeated, front-run, or batched to drain the Transmuter-held MYT vault shares (i.e., myt().balanceOf(address(transmuter))), distort settlement fairness, and worsen bad debt, increasing insolvency risk.
Vulnerability Details
The root cause is a stale, cached TVL source in AlchemistV3 that gets combined elsewhere with a live Transmuter balance, so the same MYT is effectively counted twice immediately after liquidation.
Specifically, Alchemist’s TVL helper _getTotalUnderlyingValue() reads an internal accumulator of MYT shares (_mytSharesDeposited) instead of the contract’s live MYT share balance:
Before liquidation: MYT shares sit in Alchemist; _mytSharesDeposited ≈ balanceOf(Alchemist), so cached and live views align.
During liquidation: Alchemist transfers MYT shares to the Transmuter to cover redemptions. Immediately after this move:
The Transmuter’s live balance increases (myt().balanceOf(address(transmuter))).
Alchemist’s _getTotalUnderlyingValue() still uses the cached _mytSharesDeposited, which hasn’t yet reflected the transfer.
Right after liquidation: claimRedemption combines Alchemist TVL (from the stale cache) plus the Transmuter’s live MYT—counting the same shares twice until the cache is reconciled (e.g., later via setTransmuterTokenBalance(...)).
Effect: an “after-liquidation” claim for an otherwise identical position pays more than the “before-liquidation” claim.
Fix guidance
Additionally, keep _mytSharesDeposited accurate wherever tokens move (e.g., decrement on outbound transfers): _mytSharesDeposited -= protocolFeeTotal;.
Impact Details
What gets stolen: Excess MYT shares are paid out to the first claimant(s) immediately after a liquidation because the Transmuter uses a live MYT balance while Alchemist’s TVL helper still reports a stale cached MYT amount that includes the same shares that were just moved.
Who loses: All remaining claimants in the redemption queue (and the system’s residual MYT backing) are diluted by the overpayment. If the overpayment drains the Transmuter’s balance, later claimants receive less than they are entitled to or nothing at all.
Proof of Concept
Proof of Concept
PoC shows the claim amount increases after liquidation when MYT is transferred from Alchemist to Transmuter. It reproduces by creating two identical redemptions, forcing under-collateralization, liquidating, then showing the second claim should NOT exceed the first.
The PoC demonstrates: two equal redemptions, vested equally; claim #1 before liquidation vs. claim #2 after liquidation. Claim #2 is larger solely because the same MYT was double-counted during the short reconciliation window.