# When adding a gauge, its initial value has to be set by an admin or all voting power towards it will be lost

GaugeController.add_gauge never initializes time_weight, so _get_weight loops 500 weeks from timestamp 0 and returns 0, silently discarding all votes until an admin manually calls change_gauge_weight.

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

**Target:** GaugeController.sol gauge weight accounting
**Root cause:** add_gauge does not call _change_gauge_weight, leaving time_weight[gauge] == 0; _get_weight then iterates 500 weeks from t=0, never reaching block.timestamp, so it returns 0 and never persists recent points.
**Steps:**
1. Deploy GaugeController; gov calls `add_gauge(gauge1)` without a subsequent `change_gauge_weight`.
2. user1 calls `ve.createLock{value: 1 ether}(1 ether)` then `gc.vote_for_gauge_weights(gauge1, 10000)`.
3. Call `gc.get_gauge_weight(gauge1)` — returns 0 because `_get_weight` loops 500 weeks from t=0 and never sets time_weight.
4. Repeat with gov calling `change_gauge_weight(gauge1, 0)` after add_gauge — weight returns ~993424657416307200.
5. Midway case: votes before admin set are lost; only re-voting after reset restores weight.
**How found:** Code reading of _get_weight: noticed time_weight defaults to 0 and the 500-iteration loop advances t by WEEK from 0, so it can never reach block.timestamp for a fresh gauge; confirmed with Foundry tests comparing with/without manual change_gauge_weight.
**Exploitation:** No attacker profit; a governance/accounting flaw where users' votes are silently zeroed until an admin initializes the gauge, and votes cast in the window between add_gauge and admin set are permanently lost unless users unvote and re-vote.
**Insight:** When a time-accumulator loop starts from a stored timestamp that defaults to 0, check whether the loop bound (500 weeks) can ever catch up to block.timestamp; uninitialized accumulators silently return zero and drop state updates.