# Incorrect `prefundingRefund` calculation will disallow claiming

claimProceeds computes prefundingRefund from already-decremented routing.funding, causing underflow and blocking sellers from claiming proceeds after bidders claim payouts.

- Payout: Contest reward
- Severity: high
- Program: Axis Finance
- Credited: ether_sky
- Disclosed: 2024-03-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-03-axis-finance-judging/issues/187
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-axis-finance%3AH-10
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** AuctionHouse.sol claimProceeds
**Root cause:** prefundingRefund is computed as routing.funding + payoutSent_ - sold_, but routing.funding is already decremented by each bid payout in claimBids, so it no longer holds capacity+curator fees and the subtraction underflows.
**Steps:**
1. Prefund capacity=100 so routing.funding==100
2. Sell 90 (sold_=90), no partial fill/curator fees
3. Bidders call `claimBids`, each decrementing `routing.funding -= bidClaim.payout`, leaving routing.funding==10
4. Seller calls `claimProceeds(lotId, callbackData)`
5. `uint96 prefundingRefund = routing.funding + payoutSent_ - sold_` = 10 + 0 - 90 underflows and reverts
**How found:** Code reading of claimProceeds vs claimBids revealed routing.funding is mutated in two places with inconsistent accounting assumptions; traced a concrete numeric example to confirm underflow.
**Exploitation:** Not an attacker-driven exploit; a logic bug where normal bid-claim flow drains routing.funding before claimProceeds, making the refund computation underflow and permanently reverting seller claims.
**Insight:** When a shared accounting variable is decremented in multiple flows, check every consumer's formula against the post-mutation state, not the initial invariant; construct a numeric walkthrough with all payouts claimed first.