# Users may be forced into long lock times to be able to undelegate back to themselves

VotingEscrow delegate check requires delegatee lock end >= caller lock end, forcing users to extend lock 5 years to undelegate back to themselves.

- Payout: Contest reward
- Severity: high
- Program: Canto
- Credited: ADM
- Disclosed: 2023-10-11
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-08-verwa-findings/issues/182
- Library page: https://bugbountylibrary.com/r/c4%3A2023-08-verwa%3AH-06
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:regression technique:source-review vuln:access-control vuln:business-logic

**Target:** VotingEscrow delegate/undelegate logic
**Root cause:** delegate() requires toLocked.end >= fromLocked.end, so undelegating to self fails when the caller's own lock ends earlier than the current delegatee's; the only workaround (extending lock) bumps 5 years in veRWA.
**Steps:**
1. Bob creates lock in week 1.
2. Dave creates lock in week 2; Bob calls `ve.delegate(dave)`.
3. 3 years later Bob calls `ve.delegate(bob)` to undelegate to self.
4. Call reverts at `require(toLocked.end >= fromLocked.end, "Only delegate to longer lock")` because Bob's lock ends before Dave's.
5. Extending Bob's lock to satisfy the check adds 5 years in veRWA.
6. Repro: modify testSuccessDelegate to warp 8 days between locks, then run `forge test --match testSuccessUnDelegate`.
**How found:** Code-reading of the delegate lock-end comparison against FiatDAO original; noticed the 5-year extension delta makes the standard extend-lock workaround unacceptable.
**Insight:** When porting forked ve-token contracts, diff the lock-extension granularity: a check that was benign with 1-week extensions becomes a griefing/loss vector when the fork enforces multi-year extensions.