What Matters
A buy from one strategy can cross a sell already resting from another strategy on the same account. If the exchange treats the orders as a potential self-match, its prevention rule can cancel an order or change its size. Before retrying, check both orders and their fills. The incoming order is only half the incident.
DN Evidence Block
Reviewed 7 November 2026. Bybit documents three cancellation modes for eligible self-matches and explains why a setting on a resting order does not control the next incoming order. Coinbase Exchange documents cancellation and size adjustment as possible outcomes. DN reviewed official documentation and checked a synthetic quantity ledger; we did not send live orders. [1] [2]
How two strategies can collide
Imagine one bot posting a sell and another trying to buy at the same price. Each strategy may see a valid instruction in isolation. The exchange sees orders that would cross. Whether the prevention rule applies depends on the identity and grouping rules for that venue and product. Two bot names, API keys or client order IDs are not evidence that the exchange treats the orders as separate participants.
Bybit describes matching scope in terms of the same UID or a specified self-match prevention group. Its documented choices can cancel the resting maker, the incoming taker or both. Bybit also says an order’s SMP setting no longer applies once it rests in the book; the incoming instruction matters. Verify that detail on your own order path rather than assuming the resting quote protects itself. [1]
DN Order Collision Worksheet
Copy this worksheet into an incident record. Capture the original order fields and a fresh account snapshot before amending or replacing anything.
| Check | Record | Why it matters |
|---|---|---|
| Identity | Venue, product, symbol, account scope and configured prevention group | Establish whether the orders could be treated as a self-match. |
| Incoming instruction | Order ID, price, size, time in force, prevention mode and UTC timestamp | Find the exact request and rule evaluated. |
| Resting quote | Order ID, open quantity before the event and final state | See whether a quote disappeared or changed. |
| Actual executions | Unique execution IDs and quantities for both orders | Separate booked trades from canceled or decremented quantity. |
| Current exposure | Position or balance, outstanding orders, and bot retries | Decide whether a replacement would duplicate or exceed the intended quantity. |
Worked example: canceled after a partial fill
Assume a 1.00 BTC buy first fills 0.30 BTC against another participant. Its remaining 0.70 BTC then reaches your own resting sell. In this synthetic example, the applicable rule cancels the incoming remainder and leaves the sell resting. The buy’s quantity ledger is 1.00 = 0.30 executed + 0.70 canceled + 0.00 open. The cancellation does not unwind the 0.30 BTC fill.
If you repeat the original 1 BTC buy and it fills, your combined gross purchases will reach 1.30 BTC. That is an overshoot of 0.30 BTC relative to the original target, before fees and any other activity. The arithmetic gap is 0.70 BTC, but that is not a recommendation to place a replacement. Check the remaining sell and the current portfolio first.
When quantity disappears without a trade
Coinbase Exchange describes a decrement-and-cancel option in which the smaller order is canceled and the larger order is reduced by the smaller amount, with both canceled if their sizes match. It also documents cancellation-only alternatives. This example concerns Coinbase Exchange specifically; do not apply its rules to every Coinbase product. [2]
Suppose a 1.00 BTC incoming order meets a 0.40 BTC own resting order under decrement-and-cancel. If there are no other fills or adjustments, 0.60 BTC of incoming quantity remains immediately after the collision, but zero BTC traded between those orders. The remaining quantity can still encounter other liquidity or expire depending on its instructions. A strategy that counts every decrease as a fill would book inventory it never bought.
Separate the collision from other causes
An expired order, post-only cancellation, explicit cancellation or partial execution can all leave an order absent from the open book. A price overlap alone does not establish self-trade prevention. Look for the exchange’s reason or event record and reconcile execution history. If the record is incomplete, keep the cause unresolved.
Use DN’s partial-fill guide to rebuild the quantity ledger and order timeout guide if you cannot establish whether the request reached the venue.
Build the check into bot operations
In a supported test environment, verify what happens when one strategy crosses another’s quote. Record the mode, both order states and actual executions. Test the partial-fill case, not just an order canceled with zero executions. If the simulator does not model prevention, record that as untested. A bot should reconcile with the venue before assuming that either the quote or its intended hedge still exists.
Method and disclosure
The worksheet uses documentation and synthetic quantities. It does not rank venues, establish live execution behaviour, or assess regulatory compliance. For related venue research see DN Pathfinder. Linked DN comparisons may contain affiliate links. No signup is required to use this worksheet.
Frequently Asked Questions
Does a self-trade prevention event prove nothing filled?
No. It describes the blocked self-match. Reconcile the order’s separate fills with other participants.
Does the resting order always stay open?
No. The result depends on the venue and the applicable prevention mode.
Is a reduction in order size a fill?
No. An order-size adjustment can remove quantity without any trade. Check the execution ledger.
Primary sources
About the Author
