# Withdrawal share burn vs payout mismatch

Does every withdraw branch burn shares equal in value to the assets actually transferred?

_Area: DeFi accounting and math bugs. Seen in 3 disclosed reports; latest 2025-03-20. Updated 2026-10-24._

## How it works
A withdrawal computes two quantities that must agree: shares to burn and assets to pay. The bug is divergence. The user's full share balance (or full requested amount) is burned, but the transfer is reduced, capped, or computed from a different quantity. The broken assumption is that "burn amount" and "pay amount" are the same variable. Any branch that adjusts one without the other breaks the invariant. The shortfall stays in the vault and is absorbed by remaining holders, or the user is simply underpaid.

## Where it shows up
- Shortfall/partial-fill branches that recompute the payout but not the burn. In TermMaxVault, `amountLeft -= assetBalance` subtracts the vault's own balance from the transfer amount, but that balance is never transferred, while shares are burned for the full request [E3](https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.1.6.md).
- `amount -= balance` patterns where the subtracted balance is never actually transferred [E3](https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.1.6.md).
- Withdraw code where the burn uses the full amount but the transfer uses a decremented or capped value.
- Vault valuation that uses the total withdrawal request instead of the user's share, overvaluing collateral [E1](https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-12.md).

## How to review
For every withdrawal branch, trace the share burn and the asset transfer side by side. The invariant: `sharesBurned * exchangeRate == assetsTransferred` (within rounding), in every branch including caps, shortfalls, and partial fills. Locate the burn call and the transfer call; confirm both consume the same variable. Check that any `-=` on the payout amount is matched by a reduction in shares burned. For valuation, confirm every branch uses the user's specific share amount, not the total request [E1](https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-12.md). For ERC4626, check that `previewWithdraw`/`convertToShares` rounding favors the vault and matches the actual burn.

## Variants seen
- Shortfall branch subtracted vault balance from the transfer but burned shares for the full amount, underpaying users [E3](https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.1.6.md).
- Withdraw-request valuation used the entire request amount instead of the user's shares, overvaluing collateral and blocking liquidations [E1](https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-12.md).

## Impact and severity
Losses are socialized across depositors or hit the withdrawing user directly. Severity is high: silent underpayment [E3](https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.1.6.md), and overvalued collateral that prevents liquidation [E1](https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-12.md). Worse when the shortfall is invisible to the caller.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-12.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-06.md
- E3: https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.1.6.md