# The newRemainingPeriod is wrongly calculated when a non zero remainingPeriod is less than the new timeElapsed

SmoothYieldVault miscalculates newRemainingPeriod when a nonzero remainingPeriod is less than timeElapsed, skewing the profit-smoothing denominator and distributing yield unevenly.

- Payout: Contest reward
- Severity: medium
- Program: VII Finance
- Credited: GeneralKay
- Disclosed: 2026-03-07
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_vii_finance_jan2026.pdf#3.2.1
- Library page: https://bugbountylibrary.com/r/cantina%3Avii_finance_jan2026%3A3.2.1
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:precision-loss

**Target:** SmoothYieldVault.sol _smoothedProfit() yield smoothing logic
**Root cause:** The else branch computes newRemainingPeriod = smoothingPeriod - timeElapsed, ignoring the existing nonzero remainingPeriod, so leftover time from the prior cycle is dropped instead of carried into the next smoothing period.
**Steps:**
1. Set smoothingPeriod=100, remainingPeriod=100.
2. Mint yield and `vm.warp(+70)`; call `vault.sync()` -> remainingPeriod becomes 30.
3. `vm.warp(+40)`; call `vault.sync()` again.
4. Observe remainingPeriod returns 60 instead of expected 90 (10s overflow should carry into period 2).
**How found:** Code review of the ternary in _smoothedProfit: noticed the smoothingPeriod - timeElapsed branch assumes remainingPeriod is zero, then constructed a two-cycle timeline (70s + 40s) to show the carry-over is lost.
**Insight:** In smoothing/vesting math, when timeElapsed crosses a period boundary, the overflow must be added to the fresh period length; test multi-cycle sequences where remainingPeriod is nonzero and less than timeElapsed, not just single-cycle cases.