# Invalid utilization ratio check, blocking users from submitting a flash loan

Blend checked max utilization immediately after adding flash-loan debt, reverting legitimate flash loans that would repay within the same transaction.

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

**Target:** Soroban pool contract flash-loan submit path
**Root cause:** execute_submit_with_flash_loan calls require_utilization_below_max right after add_liabilities, before the user's repay request executes, so transient debt above max_util reverts the whole transaction.
**Steps:**
1. Set reserve max_util=9500000 with b_supply=100e9, d_supply=50e9 (util 50%).
2. Call `execute_submit_with_flash_loan` with FlashLoan{asset: underlying_0, amount: 46e9}.
3. Include requests: SupplyCollateral 50e9 underlying_1, then Repay 46e9 underlying_0.
4. Observe panic `Error(Contract, #1207)` at the utilization check before repay runs.
**How found:** Code reading of the flash-loan submit path: noticed require_utilization_below_max placed immediately after add_liabilities, unlike apply_borrow where it runs after the full action set, and reasoned the end-state utilization would be healthy after repayment.
**Insight:** When auditing deferred-settlement flows (flash loans, batch actions), check that invariant checks run on the post-settlement state, not mid-transaction; compare placement of the same check across sibling entry points.