# New vest reset unlockBegin of existing vest without removing vested amount

Re-vesting in StakedCitadelVester resets unlockBegin/unlockEnd but keeps claimedAmounts, causing claimableBalance to underflow or re-lock already-vested tokens.

- Payout: Audit contest
- Severity: medium
- Program: BadgerDAO
- Credited: gzeon
- Disclosed: 2022-07-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-04-badger-citadel-findings/issues/158
- Library page: https://bugbountylibrary.com/r/c4%3A2022-04-badger-citadel%3AM-04
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** StakedCitadelVester.sol vesting contract
**Root cause:** vest() overwrites unlockBegin/unlockEnd and adds to lockedAmounts without clearing claimedAmounts, so previously claimed tokens are re-locked under the new schedule and claimableBalance can underflow.
**Steps:**
1. Call vest(recipient, _amount, _unlockBegin) on a recipient with existing vesting and claimedAmounts > 0
2. Observe lockedAmounts += _amount, unlockBegin = _unlockBegin, unlockEnd = _unlockBegin + vestingDuration, claimedAmounts unchanged
3. Call claimableBalance(recipient): locked - claimed underflows or returns reduced value because claimed is subtracted from a freshly-restarted linear schedule
**How found:** Code review of vest() and claimableBalance() noticing claimedAmounts is never reset when the unlock window is overwritten.
**Exploitation:** Not weaponized; a legitimate xCTDL vault vest call re-locks a user's already-claimed tokens, delaying or reverting their claim.
**Insight:** In linear-vesting contracts, any function that resets unlockBegin/unlockEnd must also reconcile claimedAmounts, otherwise the claimed offset is applied against a fresh schedule and either underflows or re-locks paid tokens.