# Reward computation is wrong

LendingPair.accrueAccount distributes rewards before updating supply/borrow indexes, letting a user claim a larger share of rewards than their fair stake.

- Payout: Audit contest
- Severity: high
- Program: Wild Credit
- Found by: cmichel
- Disclosed: 2021-08-17
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2021-07-wildcredit-findings/issues/116
- Library page: https://bugbountylibrary.com/r/c4%3A2021-07-wildcredit%3AH-01
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** LendingPair.sol accrueAccount reward accounting
**Root cause:** _distributeReward is called before accrue() and _accrueAccountInterest update total supply/debt and the user's balance, so the user's balance-to-total ratio used for reward payout is stale and skewed.
**Steps:**
1. User A and B each deposit 1000 tokens in same block; totalSupply=2000.
2. After 50,000 blocks A calls `accrueAccount(A)`: `_distributeReward` pays A 1000/2000=50% of rewards, then accrue mints A 200 more tokens, totalSupply=2200.
3. After another 50,000 blocks A calls `accrueAccount(A)` again: `_distributeReward` pays A 1200/2200=54.5% of rewards.
4. A collects >50% of 100,000-block rewards despite equal deposit; B gets ~45%.
**How found:** Code reading of accrueAccount ordering: noticed reward distribution precedes index/balance updates, then constructed a two-user equal-deposit scenario to quantify the skew.
**Exploitation:** Any depositor repeatedly calls accrueAccount on themselves to capture a disproportionate share of reward emissions at the expense of other LPs; no capital beyond a normal deposit required.
**Insight:** In reward-accrual contracts, check ordering of reward payout vs. index/balance updates; any payout computed from a ratio (userBalance/totalSupply) before the denominator is refreshed lets the caller inflate their share by self-triggering accrual.