# Wrong calculation of solvency in `fillCloseRequest` prevents the position from being closed even if the user is solvent after position closure

fillCloseRequest reverts when partyA is insolvent at market price but solvent at partyB's better closePrice, blocking closure and enabling unfair liquidation.

- Payout: Contest reward
- Severity: medium
- Program: Symmetrical
- Credited: panprog
- Disclosed: 2023-08-28
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-08-symmetrical-judging/issues/9
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-08-symmetrical%3AM-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:incomplete-fix technique:regression vuln:business-logic vuln:liquidation

**Target:** LibSolvency.isSolventAfterClosePosition in symmio-core close-request flow
**Root cause:** isSolventAfterClosePosition requires both parties solvent at both market price and closePrice, instead of only at closePrice, so a favorable closePrice that restores solvency is rejected.
**Steps:**
1. partyA requests to close a position while insolvent at current market price
2. partyB calls `fillCloseRequest` with a `closePrice` better than market price
3. at closePrice partyA would be solvent, but isSolventAfterClosePosition also checks market price
4. market-price check fails, transaction reverts, position cannot be closed
**How found:** Regression review: prior contest issue 184 was only partially fixed (request-to-close path), so the researcher re-checked the fillCloseRequest path and found the same solvency logic still enforced market-price solvency.
**Exploitation:** Not an attacker-driven exploit; partyA is unfairly liquidated because the legitimate close cannot complete, causing loss of funds.
**Insight:** When a prior fix touches one code path, audit sibling paths (request vs fill) for the same flawed invariant; here solvency should be evaluated only at the execution price, not both market and execution price.