# Locking up AURA Token does not increase voting power of individual

AuraLocker._lock only checkpoints votes when a delegatee exists, so users who lock AURA without self-delegating get zero voting power despite holding vlAURA.

- Payout: Contest reward
- Severity: medium
- Program: Aura Finance
- Credited: xiaoming90
- Disclosed: 2022-07-26
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-aura-findings/issues/186
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-aura%3AM-08
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:governance

**Target:** AuraLocker.sol _lock / checkpointDelegate voting-power accounting
**Root cause:** _lock() only calls _checkpointDelegate when delegates(_account) != address(0); with no delegatee, locked balance is never checkpointed into votes, so getVotes stays 0.
**Steps:**
1. Lock AURA via AuraLocker.lock() with no prior delegatee set.
2. Call getVotes(account) -> returns 0 despite locked balance.
3. Wait one epoch (increaseTime ONE_WEEK); getVotes still 0 while balanceOf shows locked vlAURA.
4. Only after calling delegate(self) does _checkpointDelegate run and votes update (effective next epoch).
**How found:** Read AuraLocker._lock source and noticed checkpointing is gated on a non-zero delegatee; wrote a test locking tokens, advancing a week, and asserting getVotes increased, which failed.
**Insight:** In vote-escrow forks, check whether checkpointing is conditional on a delegatee being set; locking without self-delegation silently produces zero voting power, a governance-participation bug rather than a fund-loss one.