# Party B liquidation can expire, causing the liquidation to be stuck

Party B liquidation requires a Muon price signature within the liquidation timeout; once expired, liquidation reverts permanently, leaving Party A's locked balance stuck.

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

**Target:** LiquidationFacetImpl.liquidatePositionsPartyB (Solidity diamond facet)
**Root cause:** The priceSig.timestamp must fall within partyBLiquidationTimestamp + liquidationTimeout, but no path resets partyBLiquidationStatus/timestamp after the timeout, so any later signature is rejected as expired.
**Steps:**
1. Liquidator initiates Party B liquidation, setting partyBLiquidationTimestamp[partyB][partyA] and status=true.
2. Liquidation is not completed within liquidationTimeout.
3. Liquidator calls `liquidatePositionsPartyB(partyB, partyA, priceSig)` with a fresh Muon signature.
4. `require(priceSig.timestamp <= partyBLiquidationTimestamp + liquidationTimeout)` reverts with 'LiquidationFacet: Expired signature'.
5. Status remains true, so notLiquidated/notLiquidatedPartyB modifiers block retry; Party A locked balance never decremented.
**How found:** Code reading of the timestamp bound in liquidatePositionsPartyB and noticing no reset function exists for the liquidation status/timestamp once the timeout elapses.
**Insight:** When a state machine gates actions on a timestamp window, check whether the state can be reset or re-entered after the window closes; a one-way latch on a time-bounded check creates a permanent DoS.