# update_market() market weight incorrect

LendingLedger.update_market() passed block numbers as the time argument to GaugeController.gauge_relative_weight_write(), yielding near-zero weights and lost/incorrect CANTO rewards.

- Payout: Contest reward
- Severity: high
- Program: Canto
- Credited: bin2chen
- Disclosed: 2024-02-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-canto-findings/issues/10
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-canto%3AH-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** LendingLedger.update_market() reward accounting / GaugeController
**Root cause:** update_market() computes epoch from block.number and passes it to gauge_relative_weight_write(), but GaugeController expects a Unix timestamp and floors it to WEEK (7 days), so the lookup lands in 1970 and returns ~0 weight.
**Steps:**
1. Read update_market(): `uint256 epoch = (i / BLOCK_EPOCH) * BLOCK_EPOCH;` derived from block.number
2. Observe call `gaugeController.gauge_relative_weight_write(_market, epoch)` passes that block number as `_time`
3. In GaugeController, `_gauge_relative_weight` computes `t = (_time / WEEK) * WEEK` with WEEK = 7 days
4. For block 7999034, t resolves to ~1970-04-02, where points_sum[t].bias is 0
5. Result: weight 0, cantoReward 0, accCantoPerShare not incremented
**How found:** Code-reading: noticed the second parameter of gauge_relative_weight_write is a timestamp while the caller derived it from block.number, then traced into GaugeController to confirm the WEEK-based flooring.
**Insight:** When integrating a Curve-style GaugeController, verify unit alignment: its weight lookups are keyed by timestamp floored to WEEK, so any caller passing block numbers silently reads empty historical points and returns zero.