# Missing reserve interest accrual prior to backstop take rate update leads to incorrect backstop_credit computation

Blend's execute_update_pool changes bstop_rate without accruing reserve interest, so previously accrued interest is credited at the new rate, misallocating backstop_credit.

- Payout: Contest reward
- Severity: medium
- Program: Blend
- Credited: 0xadrii
- Disclosed: 2025-08-13
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-02-blend-v2-audit-certora-formal-verification#m-13
- Library page: https://bugbountylibrary.com/r/c4%3A2025-02-blend-v2-audit-certora-formal-verification%3AM-13
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Soroban pool config contract (execute_update_pool) and reserve accrual logic
**Root cause:** execute_update_pool writes pool_config.bstop_rate without first loading/accruing the reserve, so unaccrued interest is later credited using the new rate instead of the rate in effect when it accrued.
**Steps:**
1. Pool has 100 tokens of unaccrued interest with bstop_rate=30%.
2. Admin calls `execute_update_pool(backstop_take_rate=0, ...)`; no reserve accrual occurs.
3. Next pool interaction triggers `Reserve::load` -> `accrue` with bstop_rate=0.
4. `new_backstop_credit = accrued.fixed_mul_floor(0)` = 0, so 0 instead of 30 tokens go to backstop_credit.
**How found:** Code reading of config.rs execute_update_pool versus reserve.rs accrue: noticed bstop_rate is read at accrual time and the setter does not force accrual first.
**Exploitation:** Admin-triggered config change (or any bstop_rate update) in a low-activity pool causes accrued interest to be credited at the wrong rate; no external attacker extraction described.
**Insight:** When a config parameter is consumed lazily at accrual/settlement time, any setter for it must flush pending accrual first, otherwise historical periods get repriced at the new value.