# Keepers can open positions that are already liquidatable

Elfi Protocol order execution lacks a post-open liquidation check, letting keepers open positions that are immediately liquidatable, risking protocol insolvency.

- Payout: Contest reward
- Severity: high
- Program: Elfi Protocol
- Credited: mstpr-brainbot
- Disclosed: 2024-05-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/27
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-elfi-protocol%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:liquidation

**Target:** Perpetual futures order execution (OrderFacet/OrderProcess)
**Root cause:** executeOrder never validates whether the resulting isolated position or cross account would be immediately liquidatable at execution price, so a stale/greedy order can be filled into an underwater state.
**Steps:**
1. User0 deposits 1000 USDC and creates a cross LONG market order on btcUsd with 5000$ orderMargin and 5x leverage via `createOrderRequest`.
2. Keeper (user3) calls `executeOrder(requestId, oracle)` with wbtc price 25000 and usdc price 0.99$.
3. Price moves to 18000; `getIsLiqableTapir(user0, nextOracle)` returns true.
4. User0 submits a DECREASE/SHORT order for the full qty; keeper executes it at the new oracle price without any liquidation check.
**How found:** Code review of OrderProcess.executeOrder and OrderFacet.createOrderRequest revealed no liquidation-health validation on the two-step open flow; author built a Foundry test adding a getIsLiqableTapir helper to confirm the position is liquidatable right after execution.
**Exploitation:** A user submits a greedy leveraged order; by the time a keeper executes it (or immediately after a price move), the position is already underwater. The keeper fills it anyway since no check exists, leaving the protocol to absorb bad debt when liquidation cannot recover collateral.
**Insight:** On two-step order systems (request then keeper execute), check whether the fill path re-validates account health at execution price; stale requests plus oracle movement can produce instantly-bad debt that the protocol eats.