# Reward checkpointing can consume the full liquidation CPU budget and disable aToken-based collateral seizure

Per-asset 20-reward-token cap multiplies across a liquidation's four incentive hooks to 100 checkpoints, exceeding Soroban CPU budget and blocking aToken-collateral seizure.

- Payout: Contest reward
- Severity: medium
- Program: K2
- Credited: Egobouros
- Disclosed: 2026-08-20
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2026-04-k2#m-40
- Library page: https://bugbountylibrary.com/r/c4%3A2026-04-k2%3AM-40
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:liquidation

**Target:** Soroban lending router liquidation path with incentives hooks
**Root cause:** MAX_REWARD_TOKENS_PER_ASSET caps rewards per token contract, but a receive-aToken liquidation triggers four handle_action hooks (debt burn, collateral transfer to liquidator, fee transfer to treasury) each iterating up to 20 reward streams, so aggregate work is unbounded at the router level.
**Steps:**
1. Configure debt token with 20 borrow reward tokens and collateral aToken with 20 supply reward tokens (valid config).
2. Create unhealthy borrower; leave collateral reserve short of idle underlying so receive-underlying liquidation is infeasible.
3. Call direct liquidation with `_receive_a_token = true`.
4. Router burns debt via `burn_scaled` -> 20 borrow reward checkpoints.
5. Router calls `transfer_on_liquidation` to liquidator -> 20+20 supply checkpoints.
6. Router calls `transfer_on_liquidation` for protocol fee to treasury -> 20+20 supply checkpoints.
7. Total 100 reward-stream iterations; CPU reaches ~103,775,427 vs 21,421,816 baseline, exceeding Soroban 100,000,000 budget and reverting.
**How found:** Observed that incentives are an inline side effect of every aToken/debt-token balance change, then reasoned that the per-token cap composes multiplicatively across the multiple hooks a single liquidation triggers; measured CPU with and without max-valid incentives.
**Exploitation:** No theft; a permitted incentives configuration makes the fallback receive-aToken liquidation path exceed the network CPU budget, so unhealthy accounts cannot be liquidated until rewards are disabled or config changes.
**Insight:** When a per-contract resource cap gates work executed inline on every token movement, count how many times a single high-level router operation invokes those hooks and multiply — the effective cap is per-transaction, not per-asset.