Reduce-only is a hard constraint on an order: no matter how markets move, no matter what other orders are sitting on the book, the order will never add to your position and will never flip your side. It is the backbone of safe stop-losses, take-profits, and unwind strategies — and it is especially important for algo systems that hold many positions and rely on automatic risk reduction.
What reduce-only guarantees
- Position decreases only. A reduce-only order cannot open, enlarge, or reverse a position.
- No upfront margin. Reduce-only orders do not reserve available balance. You can place them even with zero free collateral and even when your maintenance margin ratio is dangerously high (100–120% MMR) — in fact, that is exactly when you need them most.
- Automatic scaling. When your position shrinks for any reason, the protocol automatically trims or cancels your resting reduce-only orders so their total size never exceeds the remaining position.
Submission checks
When you submit a new reduce-only order, the gateway rejects it if any of the following holds:
- You have no position in this contract (or in hedge mode, no position on the matching side)
- The order side does not match “close direction” — for a long, the order must be a sell
- The single order quantity exceeds your current position on that side
- The order quantity would round to zero under the contract’s lot size
Submission checks only compare the single new order against the current position. They do not sum up existing reduce-only orders. This is intentional — you may legitimately want overlapping reduce-only orders at different prices. The engine handles the aggregate constraint later via trimming.
Trimming when position shrinks
Whenever your position decreases, the risk engine re-evaluates every reduce-only order on that side. If their total size exceeds the new position, it trims them using price-time priority, worst-first: for a long, the highest-priced sell goes first; for a short, the lowest-priced buy. Ties break by time — the latest order is trimmed first.
The engine prefers to shrink orders (via Modify orders) rather than cancel them outright. An order is only cancelled once its size would drop to zero; if shrinking stops just short of zero, the order stays live even if it is below the minimum order size.
Worked example
You are long 10 BTC and place three reduce-only sells: A (2 BTC @ 80,000), B (3 BTC @ 82,000), C (8 BTC @ 81,000). Total 13 > 10, so the engine cancels the worst-priced order B entirely, leaving A + C = 10 BTC.
You then market-sell 9 BTC. Position drops to 1 BTC, so the engine cancels C (worst remaining) and shrinks A from 2 to 1. Final state: A live at 1 BTC @ 80,000.
Full close or reversal
When a position reaches zero — or is reversed through to the other side — the engine cancels every remaining reduce-only limit order on the old direction, plus any triggered reduce-only conditional orders on that side. Untriggered conditional orders (TP/SL children of a still-pending parent, for example) are untouched because they were never active to begin with.
In hedge mode with both long and short positions on the same contract, closing the long only affects long-side reduce-only orders. The short-side reduce-only orders are not disturbed.
Liquidations
Before the liquidation engine takes over a position, all of that account’s outstanding reduce-only orders — including conditional ones — are cancelled so they cannot conflict with the liquidation flow. For a partial liquidation that leaves a small residual position, any new reduce-only order must respect the remaining position size.
Matching-time recheck
Reduce-only orders are rechecked at match time. If a race makes an order look like it would increase a position at the moment of a fill, the match is rejected — catching edge cases that submission-time checks cannot cover. 
