# User cannot withdraw stakingToken due to incorrect calculation of _totalSupply

ZivoeRewardsVesting.revokeVestingSchedule subtracts full vestingAmount from _totalSupply instead of already-withdrawn-adjusted amount, causing underflow that blocks later users' withdrawals.

- Payout: Contest reward
- Severity: high
- Program: Zivoe
- Credited: 0xAnmol
- Disclosed: 2024-03-19
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-03-zivoe-judging/issues/31
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-zivoe%3AH-3
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:dos

**Target:** ZivoeRewardsVesting staking/vesting contract
**Root cause:** revokeVestingSchedule subtracts the full vestingAmount from _totalSupply even though part was already withdrawn and previously deducted, double-counting the withdrawn portion and driving _totalSupply below the sum of remaining claimable balances.
**Steps:**
1. Create vesting schedule for userA: 20 ether, cliff 30d, vest 120d; userB: 30 ether, same params. _totalSupply = 50.
2. Warp 60 days; userB calls `withdraw()` for 15 ether. _totalSupply = 35.
3. ZVL calls `revokeVestingSchedule(userB)`, which subtracts full 30 ether. _totalSupply = 5.
4. Warp another 60 days; userA calls `withdraw()` for 20 ether; `_totalSupply.sub(20)` underflows and reverts (panic 0x11).
**How found:** Manual review of accounting invariants: noticed revoke subtracts vestingAmount rather than the remaining unwithdrawn amount, then constructed a two-user scenario with a mid-vest withdrawal followed by revoke to force underflow.
**Insight:** When a revoke/cancel path adjusts a global supply counter, check whether the per-user already-withdrawn amount was previously deducted from that same counter; subtracting the full original amount double-counts and can underflow, bricking later claims.