# Wrong calculation of solvency after request to close and after close position

Symmetrical's solvency check for closing positions ignores extra profit from closePrice vs uPnL price, wrongly reverting closes that would leave users solvent.

- Payout: Contest reward
- Severity: medium
- Program: Symmetrical
- Credited: shaka
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-symmetrical-judging/issues/184
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-symmetrical%3AM-7
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** LibSolvency.sol isSolventAfterClosePosition / isSolventAfterRequestToClosePosition
**Root cause:** Solvency functions only subtract the extra loss from closePrice vs upnlSig.price but never add the extra profit when closePrice is more favorable, so available balance is understated.
**Steps:**
1. Open LONG position: qty 1, locked 50, opened 100, current 110, uPnL +10.
2. Party B calls `fillCloseRequest` with closePrice 120.
3. `isSolventAfterClosePosition` computes `partyAAvailableBalance = freeBalance + upnl + unlockedAmount = -5`.
4. Extra profit `closePrice - upnlSig.price = 120 - 110 = 10` is not added; require reverts though true balance would be +5.
**How found:** Code review of LibSolvency: noticed the loss branch of closePrice vs upnlSig.price was handled but the symmetric profit branch was missing.
**Insight:** In perp/DVP solvency math, check both directions of the closePrice-vs-oracle delta; asymmetric handling of profit vs loss silently blocks legitimate closes and can also be abused if the loss side is ever under-counted.