# Unlisting a vesting after seller has claimed additional steps locks tokens which should have been claimable already

Unlisting a vesting after claiming steps redistributes refunded tokens across remaining steps, re-locking tokens that were already unlocked and claimable.

- Payout: Contest reward
- Severity: medium
- Program: SecondSwap
- Credited: BenRai
- Disclosed: 2025-02-18
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-12-secondswap#m-18
- Library page: https://bugbountylibrary.com/r/c4%3A2024-12-secondswap%3AM-18
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** SecondSwap_VestingManager.sol releaseRate recalculation on unlist
**Root cause:** On unlist, refunded tokens are spread over remaining unclaimed steps by recomputing releaseRate = (totalAmount - amountClaimed)/(numOfSteps - stepsClaimed), ignoring steps already unlocked since listing, so previously claimable tokens get pushed into future steps.
**Steps:**
1. Alice has 100-token allocation over 10 steps, releaseRate 10/step.
2. She lists 50 tokens; VestingManager holds them, releaseRate becomes (100-50)/10 = 5/step.
3. After 5 steps she claims 5*5 = 25 tokens; 25 remain claimable.
4. No buyer, so she unlists; 50 tokens refunded and releaseRate recomputed as (25+50)/(10-5) = 15/step.
5. She now cannot claim the 50 tokens that should already be unlocked at step 5.
**How found:** Code-reading of the unlist releaseRate formula; noticed it divides remaining amount by remaining steps without accounting for steps unlocked/claimed between listing and unlisting.
**Insight:** When a contract recomputes a rate/schedule on refund, check whether it divides by remaining periods while ignoring periods already elapsed since the state change—this silently re-locks vested value.