# StopLoss/TakeProfit should be validated again for the new price in Trading.executeLimitOrder()

Tigris executeLimitOrder overwrites stop-order open price with feed price but never re-validates SL/TP, so orders can open and instantly close at a loss.

- Payout: Contest reward
- Severity: medium
- Program: Tigris Trade
- Credited: hansfriese
- Disclosed: 2023-02-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-12-tigris-findings/issues/512
- Library page: https://bugbountylibrary.com/r/c4%3A2022-12-tigris%3AM-18
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Trading.executeLimitOrder() stop-order execution path
**Root cause:** For stop orders (orderType 2/3) executeLimitOrder sets trade.price = _price from the verified feed, but the StopLoss/TakeProfit bounds validated at order creation are not re-checked against the new price.
**Steps:**
1. Create a stop order (orderType 2 or 3) with SL/TP bounds valid for the original trade.price.
2. Wait until the feed price _price differs enough from trade.price that the SL/TP bounds no longer hold.
3. Call `executeLimitOrder(_id, _priceData, _signature)`; line 506 sets `trade.price = _price` without re-validating SL/TP.
4. Order opens at the new price and is immediately closed by SL/TP, realizing an unexpected loss.
**How found:** Code reading of executeLimitOrder: noticed trade.price is reassigned to the feed price for stop orders while the SL/TP validation done at order creation is not repeated, hypothesizing the new price could violate those bounds.
**Insight:** When an execution path mutates a stored order's price/parameters, check whether invariants (SL/TP, ranges) validated at creation are re-validated after mutation; stop orders differ from limit orders in price guarantees.