# `liquidatePositionsPartyA` limits partyB loss to partyB allocated balance, which can lead to inflated partyB balance and loss of funds for protocol users

Liquidating partyA positions caps partyB loss at current allocated balance, so loss-then-profit ordering inflates partyB balance, creating protocol insolvency.

- Payout: Contest reward
- Severity: high
- Program: Symmetrical
- Credited: bitsurfer
- Disclosed: 2023-08-28
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-08-symmetrical-judging/issues/6
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-08-symmetrical%3AH-2
- Tags: domain:web3 impact:funds-loss impact:integrity kind:contest platform:sherlock sev:high technique:source-review vuln:accounting-error vuln:business-logic vuln:liquidation

**Target:** Symmio-core LiquidationFacetImpl liquidatePositionsPartyA
**Root cause:** amountToDeduct is min(partyB loss, current allocated balance) applied per-position, so a loss position zeroes balance before a profit position is credited in full, rather than netting total signed pnl.
**Steps:**
1. Set partyB with Position1 upnl=-960, Position2 upnl=+1000, cva+lf=10 each, mm=10 each, allocated balance=0 (available=40>=20, not liquidatable).
2. Liquidate partyA; liquidate Position1 first: amount=960, amountToDeduct=min(960,0)=0, balance stays 0.
3. Liquidate Position2: amount=1000 credited, allocatedBalance becomes 1000.
4. Observe partyB balance inflated to 1000 vs expected <60, with no funds entering protocol.
**How found:** Code reading of amountToDeduct as min(loss, current balance) per position; noticed order-dependence when total upnl is small but individual positions large.
**Exploitation:** Attacker (partyB) deallocates most funds while holding offsetting high-profit and high-loss positions, then triggers partyA liquidation ordering loss-first so the loss is truncated at zero balance and profit credited fully, inflating claimable balance at protocol expense.
**Escalation:** Repeated across liquidations drains protocol reserves, causing bank run and last users unable to withdraw.
**Insight:** When capping a counterparty's loss at their current balance, check whether per-position application makes outcomes order-dependent; net signed pnl across all positions before applying caps.