# Permanent freeze of vested tokens due to overflow in _baseVestedAmount

VTVLVesting._baseVestedAmount multiplies uint112 linearVestAmount by uint40 duration, overflowing and reverting, permanently freezing vested tokens above ~16.4M for one-year vesting.

- Payout: Contest reward
- Severity: high
- Program: VTVL
- Credited: Trust
- Disclosed: 2022-11-01
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-09-vtvl-findings/issues/95
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-vtvl%3AH-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** VTVLVesting.sol vesting claim calculation
**Root cause:** Intermediate product _claim.linearVestAmount (uint112) * truncatedCurrentVestingDurationSecs (uint40) is computed in uint112, so large vest amounts overflow and revert under Solidity >=0.8.0.
**Steps:**
1. Create claim with linearVestAmount = 170000000000000000000000000 (17M tokens, 18 decimals) over 1 year
2. Call vestedAmount(recipient, endTimestamp)
3. Observe revert with Panic(0x11) arithmetic overflow
4. Half-term call succeeds returning 85e24, confirming only full-duration product overflows
**How found:** Code reading of _baseVestedAmount: noticed uint112 * uint40 multiplication and computed max safe vest amount (2^112/1e18/31536000 ≈ 16.4M tokens/year) to prove uint112 is inadequate.
**Exploitation:** No attacker action; the overflow triggers on legitimate vestedAmount/withdraw calls once vest amount exceeds ~16.4M tokens for 1-year vesting, blocking recipients from withdrawing.
**Insight:** When auditing vesting/streaming math, compute the max safe value of each fixed-width intermediate product (amount * duration) against realistic token supplies with 18 decimals; uint112 amounts times uint40 durations overflow far sooner than expected.