# It is possible to open and liquidate your own position in 1 transaction to overcome efficiency and liquidity removal limits at almost no cost

Perennial allowed opening/withdrawing to maintenance edge then self-liquidating in one tx using a recorded Pyth price, bypassing efficiency and liquidity-removal limits.

- Payout: Contest reward
- Severity: medium
- Program: Perennial
- Credited: Emmanuel
- Disclosed: 2023-07-17
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-07-perennial-judging/issues/104
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-07-perennial%3AM-6
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:chained technique:source-review vuln:business-logic vuln:liquidation vuln:oracle-manipulation

**Target:** Perennial v2 market contract / oracle commit + liquidation flow
**Root cause:** Solvency is checked only against maintenance margin (no separate initial margin), so a position can be brought to exactly the liquidation edge; combined with committing a non-requested oracle version, a user can make their own position liquidatable and liquidate it in the same transaction.
**Steps:**
1. Record Pyth oracle price signatures until finding a price slightly above/below the latest oracle version price in the favorable direction.
2. In one transaction, withdraw max collateral or open a position with minimum collateral to sit exactly at the maintenance edge.
3. Commit the recorded non-requested oracle version so the position becomes liquidatable.
4. Call liquidate on your own position; liquidation fee returns to you, paying only keeper/open-close fees.
**How found:** Code reading of Position.sol solvency check (maintenance-only margin) plus observation that oracle commits accept non-requested versions, letting the author construct a same-tx self-liquidation and an unsuspecting-user liquidation PoC.
**Exploitation:** Attacker records a favorable Pyth price, brings position to maintenance edge, commits the stale/recorded oracle version, and self-liquidates in one tx, paying only keeper and position fees while bypassing efficiency and liquidity-removal limits; can also frontrun large price updates by withdrawing max collateral from a losing position and liquidating it same-tx while a profitable position captures the move.
**Escalation:** Chained with maker/taker imbalance: open large maker then liquidate it to socialize positions, or leave small maker to profit from high taker interest; also frontrunning large oracle updates to make risk-free profit across two accounts.
**Insight:** When a protocol checks solvency only against maintenance margin and accepts non-requested oracle versions, test whether you can move to the liquidation edge and self-liquidate in one tx; also check whether collateral withdrawal is applied immediately while position size updates later, enabling same-block liquidation of others.