# Upon IncreaseAmount the lock may not align to the nearest weekly increment

VotingEscrow.increaseAmount set lock end to block.timestamp+LOCKTIME without flooring to a week, breaking checkpoint slope alignment and corrupting votes.

- Payout: Contest reward
- Severity: medium
- Program: Canto
- Credited: gzeon
- Disclosed: 2023-10-11
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-08-verwa-findings/issues/145
- Library page: https://bugbountylibrary.com/r/c4%3A2023-08-verwa%3AM-02
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:governance

**Target:** VotingEscrow.sol smart contract (Solidity)
**Root cause:** increaseAmount sets newLocked.end = block.timestamp + LOCKTIME directly, while other paths floor end via _floorToWeek; _checkpoint implicitly assumes week-aligned lock times.
**Steps:**
1. Call increaseAmount on an existing lock at a block.timestamp not aligned to a WEEK boundary
2. Observe newLocked.end = block.timestamp + LOCKTIME is not floored to the nearest weekly increment
3. _checkpoint records slope changes at unaligned timestamps, so user-specific and global slope changes are not applied correctly
4. Delegate/undelegate checks comparing toLocked.end >= fromLocked.end also behave inconsistently
**How found:** Code review comparing increaseAmount against other lock-creation paths that use _floorToWeek; spotted the missing rounding.
**Exploitation:** No direct theft; misaligned lock end causes _checkpoint to skip slope changes, producing wrong voting power/relative votes if many users do it.
**Escalation:** Aggregate effect across many users corrupts global slope accounting, skewing votes.
**Insight:** When a protocol has a canonical time-rounding helper, grep every assignment to the same field and flag any path that bypasses it—checkpoint/slope math often silently assumes alignment.