Self-Trade Prevention (STP): When Your Orders Meet Each Other
Sometimes an order disappears without executing or being rejected. Its log says canceled, although you never canceled it. The exchange may have removed it automatically when it encountered another order from your account. This rule is self-trade prevention, or STP.
Your own orders do not execute against each other
Buy and sell orders normally match when their prices overlap. If they belong to the same account, an STP-enabled matching engine instead stops that match and cancels one or both.
Two orders from one account:
Resting sell limit: $60,100, 2 contracts.
Incoming buy limit: $60,100, 2 contracts.
Ordinarily:
Overlapping prices → immediate matching.
Same account with STP:
Execution blocked.
One order canceled.
─────────────
This is a cancellation, not a rejection.
It can disappear without a request error.
Trading against yourself can manufacture volume without a genuine change of ownership. Exchanges block this at the engine level for market-data integrity and regulatory reasons. Intentional and accidental collisions are subject to the same rule. See execution priority for order queues and reading the order book for the book itself.
Three modes: Which order disappears?
Names vary by venue, but three common modes determine which order is removed.
Existing sell: 2 contracts. Incoming buy: 2 contracts.
① Cancel taker
The new order disappears.
The resting sell remains.
② Cancel maker
The resting sell disappears.
The incoming buy continues toward other counterparties.
③ Cancel both
Both orders disappear.
─────────────
① The new entry does not happen.
② A resting target or stop order can disappear.
③ Both are removed.
The guide highlights ② as particularly dangerous. A separate additional-entry order can overlap a take-profit limit, allowing the entry while silently removing the target. The position remains without its intended exit. Partial executions complicate this further; see partial fills for remaining quantities.
Where it happens ① Grid bots
Grids maintain buy and sell ladders simultaneously. Narrow price ranges or close spacing can bring your own orders together.
Spacing: $50. Quantity: 2 contracts per level.
Sell ladder: $60,050 / $60,100 / $60,150.
Buy ladder: $59,950 / $59,900 / $59,850.
A sharp rise executes the $60,050 sell.
The bot moves a buy level upward
and submits a new buy at $60,050.
But cancellation is delayed:
0.4 contracts of an old $60,050 sell remain.
─────────────
STP cancels one side.
Buy ladder: 3 levels → 2.
The bot records “order submitted,”
while the actual grid contains a hole.
A missing grid level does nothing when price returns. Over several days, scattered holes can make the bot behave differently from its design. See grid trading for the structure and grid bot optimization for spacing.
Where it happens ② Simultaneous longs and shorts in hedge mode
Hedge mode allows a long and short in the same instrument. The collision described here involves a long-entry buy and a short-entry sell at the same price; closing a long and opening a short are both sell-side actions and do not themselves form an opposing pair.
Position mode: Hedge.
Pending long entry: Buy $59,900, 1 contract.
Pending short entry: Sell $59,900, 1 contract.
Intention: Follow whichever direction breaks.
The orders attempt to match each other.
STP activates.
─────────────
Expected: One execution reveals direction.
Actual: One side is canceled; only the other remains exposed.
Cancel-both mode removes both,
leaving no order for the breakout.
A breakout straddle cannot be implemented by two opposing plain limits at the same price. The original guide proposes separating levels, illustrating buy $59,900 / sell $59,800, or using separate conditional triggers. Those quoted plain-limit prices would still cross if simultaneously active; order type and trigger direction must implement the intended separation. See one-way and hedge position modes.
Where it happens ③ Multiple API keys
Different keys do not necessarily mean different STP identities. STP commonly applies at account or subaccount-group level. Two bots using different keys on one account can belong to the same group.
Bot A, API key #1: Sell $60,100, 2 contracts.
Bot B, API key #2: Buy $60,100, 2 contracts.
The bots do not know about one another.
STP cancels one order.
The affected bot cannot explain the disappearance.
It commonly resubmits, gets canceled again, and repeats.
─────────────
The loop floods requests
and can hit a rate limit.
If strategies can oppose one another, the guide suggests separate subaccounts, subject to the venue's STP grouping. See API keys for permissions. Repeated cancellation and replacement consume request capacity before fees, potentially delaying a needed stop request.
How to detect a cancellation
STP cancellation differs from rejection. A rejected request returns an error, whereas an STP order may be accepted first and change state afterward, so the initial response looks successful.
Rejected:
Error response to the request;
the guide's example has no order ID.
Open:
Status live; remaining quantity unchanged.
STP cancellation:
Order ID exists; request accepted.
Status canceled.
Executed quantity: 0 in this example.
Cancellation reason contains an STP code.
─────────────
Check order history, not just executions,
and inspect the cancellation reason.
A bot should reconcile status after acceptance.
For bot operation, the guide recommends checking order status again after several seconds instead of trusting submission alone. This detects an allegedly resting stop that no longer exists. Other causes of nonacceptance are covered in order rejection reasons.
Ways to reduce collisions
① Avoid overlapping entry and exit prices;
use appropriately separated levels and order conditions.
② Use reduce-only on exits to specify that they must not open exposure.
③ Reposition a grid after confirming cancellation;
do not submit the cancellation and replacement simultaneously.
④ Separate opposing strategies into subaccounts where venue rules support it.
⑤ Include post-submission status reconciliation.
⑥ On repeated cancellations, stop resubmitting and investigate;
avoid endless retries.
Reduce-only in ② does not disable STP, but prevents an exit from creating new exposure and simplifies its purpose. See post-only, reduce-only and IOC. Rule ③ matters because a new order submitted before cancellation completes can briefly coexist with the old order at the same price, creating a collision window.
Fees and trading volume
A quantity canceled by STP is not executed, so it incurs no execution fee and adds no trading volume. It cannot manufacture volume toward a VIP tier.
2 contracts canceled by STP.
Executed quantity: 0.
Fee: $0.
30-day volume contribution: $0.
─────────────
Execution cost is zero,
but an opportunity has disappeared:
the intended order is absent at that price.
The real cost is what the missing order was meant to do.
STP itself does not debit money. Loss can arise because an order you thought existed is absent. See fee tiers and VIP levels and trading frequency and fee drag.
Recap
② It can appear as a quiet cancellation, not rejection.
③ Modes cancel the taker, maker or both.
④ Cancel-maker can remove a resting exit.
⑤ Grid replacement delays create collisions.
⑥ Same-price opposing plain limits do not create a breakout straddle.
⑦ Different API keys may share one account group.
⑧ Resubmission loops consume rate limits.
⑨ Acceptance alone is insufficient.
⑩ Reconcile status after submission.
⑪ Design entry and exit conditions to avoid collisions.
⑫ No execution fee does not remove the risk of a missing order.
An STP cancellation may not produce an obvious alert. If your approach maintains several orders, periodically confirming that supposedly resting orders are still live is part of operating it reliably.
Caution
Prices including $60,100, $60,050, $59,900 and $59,850; quantities of 2, 1 and 0.4 contracts; $50 grid spacing; three-level ladders; and the two-key or subaccount arrangements are hypothetical illustrations, not measured accounts or live quotes. STP details vary by exchange: default mode, per-order configuration, account grouping, reason codes and reduce-only handling must be checked in that venue's API documentation and trading rules. This explains execution mechanics without recommending a particular strategy or bot configuration. Leverage can lose all principal, and accurate order management does not guarantee profit. Decisions and outcomes remain your responsibility.
NOONOO TRADING invites you to follow live trading in our free chat.
Start in the bot📈 OKX trading fee discount for new registrations
Register for the OKX Fee Discount →