# Tokens with lower number of decimals can result in postponed linear vesting for user

Integer truncation in VTVLVesting's linear vesting math causes low-decimal tokens like USDC to delay a user's vesting start by days.

- Payout: Contest reward
- Severity: medium
- Program: VTVL
- Credited: pashov
- Disclosed: 2022-11-01
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-vtvl-findings/issues/191
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-vtvl%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:accounting-error vuln:precision-loss

**Target:** VTVLVesting.sol vesting calculation (_baseVestedAmount)
**Root cause:** Solidity integer division truncates `linearVestAmount * elapsed / finalVestingDurationSecs` to zero when the numerator is smaller than the large duration denominator, so vested amount stays 0 until enough time elapses.
**Steps:**
1. Use a 6-decimal token (USDC/USDT) with 10,000 tokens vested over 10 years (315360000 secs).
2. linearVestAmount = 10,000*10^6 / 315360000 ≈ 310 fractions/sec.
3. Call `_baseVestedAmount` early: `310 * elapsed / 315360000` truncates to 0.
4. Vested amount remains 0 until elapsed ≥ ~1,017,290 secs (~12 days), postponing vesting.
**How found:** Code-reading of `_baseVestedAmount` division; reasoned about integer truncation with a concrete low-decimal token and long vesting duration to compute the delay.
**Insight:** When auditing vesting/streaming math, plug in low-decimal tokens (USDC/USDT) and long durations to expose truncation-to-zero windows that 18-decimal assumptions hide.