# Improper adjustment of Lending Ledger configuration

LendingLedger.setRewards and setBlockTimeParameters retroactively apply to markets not updated in the same block, mis-measuring lender rewards.

- Payout: Contest reward
- Severity: medium
- Program: Canto
- Credited: 0xsomeone
- Disclosed: 2024-04-26
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-03-neobase-findings/issues/16
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-neobase%3AM-04
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** LendingLedger.sol reward/block-time configuration functions
**Root cause:** setRewards and setBlockTimeParameters mutate epoch/block-time parameters without forcing all markets to be updated in the same block, so the new values retroactively apply to stale markets.
**Steps:**
1. Deploy LendingLedger and set up a lending market with a lender via setupStateBeforeClaim.
2. Roll to `BLOCK_EPOCH * 5 + 1`.
3. As governance call `ledger.setRewards(fromEpoch, toEpoch, amountPerBlock * 2)` without calling `update_market` on the market.
4. As lender call `ledger.claim(lendingMarket)` and observe balance delta != expected `amountPerBlock - 1` (assertion fails).
**How found:** Code-reading of the approximation system and the in-code warning in update_market; noticed setRewards lacks the same warning and that retroactive application occurs when markets are stale.
**Exploitation:** Governance reconfigures rewards or block-time parameters; any market not updated in that exact block gets over- or under-estimated rewards on subsequent claims.
**Insight:** When a contract uses per-market lazy accounting (update_market) plus global config setters, check whether config changes require a synchronized update of all markets; a warning comment in one function does not enforce it in sibling setters.