リサーチ
Order controls across seven venues: time in force, reduce-only, self-trade prevention and the dead man's switch
Beyond price and size, an order carries a handful of controls that decide what happens when things go wrong. Which ones exist on which venue decides how much of your safety has to live in your own code.
リサーチ記事は英語で公開しています。
Every exchange accepts a limit order with a price and a quantity. The differences that matter to a trading system are in the controls around it: what the order does if it cannot fill immediately, whether it may increase a position, what happens if it would trade against your own order, and what the venue does with your orders if your connection dies. This note maps those controls across the seven venues our connectors cover, as documented in October 2026. Venues revise these without notice; the map is a starting point for reading their documentation, not a substitute for it.
Time in force
Good till cancelled rests until filled or cancelled. Immediate or cancel fills what it can at once and cancels the rest. Fill or kill fills entirely at once or not at all. Post-only rests or is rejected, never takes (see Maker-only orders).
| Venue | GTC | IOC | FOK | Post-only |
|---|---|---|---|---|
| Binance | yes | yes | yes | yes |
| Bybit | yes | yes | yes | yes |
| OKX | yes | yes | yes | yes |
| Bitget | yes | yes | yes | yes |
| KuCoin | yes | yes | yes | yes |
| Gate | yes | yes | yes | yes (poc) |
| MEXC | yes | yes | yes | yes |
The set is uniform; the spellings are not. Several venues implement IOC and FOK as separate order types rather than as a time-in-force field, and one venue’s “IOC” on spot is a different parameter from its “IOC” on derivatives. A connector that exposes one order model has to carry that mapping per venue and per market type.
Reduce-only
A reduce-only order on a derivatives venue may only decrease an open position; it is rejected or trimmed if it would open or increase one. It is the control that lets a hedger close exposure without the risk of flipping to the opposite side when a fill arrives late.
All seven venues support reduce-only on perpetuals. The corner cases differ: whether an order that would over-reduce is rejected outright or reduced to the remaining position size, and whether reduce-only is honoured for orders already resting when the position changes. The second question matters most for a quoting engine that keeps closing orders resting while the position moves; on venues that re-check reduce-only continuously, those orders are cancelled by the venue when they stop reducing, and the engine must expect that.
Self-trade prevention
When one account, or several accounts of one owner, has orders on both sides of a book, a new order can match a resting one of its own. The venue’s self-trade prevention decides what happens: cancel the incoming order, cancel the resting one, cancel both, or let the trade happen and charge fees on both sides.
| Venue | Self-trade prevention | Configurable per order |
|---|---|---|
| Binance | yes, several modes (expire taker, expire maker, expire both) | yes |
| Bybit | yes, cancel maker, cancel taker or cancel both | yes |
| OKX | yes, cancel maker, cancel taker or cancel both | yes |
| Bitget | yes | yes |
| KuCoin | yes, several modes | yes |
| Gate | yes, several modes | yes |
| MEXC | yes on spot (stpMode: cancel taker, cancel maker or cancel both); not documented for futures |
yes |
Where self-trade prevention is absent on a given market, the trading system has to avoid self-matches itself, by keeping a single view of its own resting orders across accounts and never crossing it. That is a non-trivial piece of state, and it is a reason to prefer venues that provide the control.
The dead man’s switch
Also called cancel-on-disconnect or cancel-all-after. The client tells the venue: if you do not hear from me within N seconds, cancel my orders. When the connection dies, the venue cleans up; without it, resting quotes stay on the book while the strategy that priced them is gone, which is how a market maker ends up with a position it never intended during an outage.
| Venue | Dead man’s switch | Scope |
|---|---|---|
| Binance | yes on futures (countdown cancel-all); not on spot | per symbol |
| Bybit | yes (disconnect cancel-all protection) | per connection |
| OKX | yes (cancel-all-after) | per account |
| Bitget | not in the current API | — |
| KuCoin | yes on spot for high-frequency accounts (dead-cancel-all, 5 to 86 400 s); not documented for futures |
per account or per symbol |
| Gate | yes (countdown cancel) | per account or market |
| MEXC | not in the current API | — |
On venues without it, the only protection is an external watchdog: a second process, ideally on a second machine, that notices the strategy is gone and cancels on its behalf. We run one on every venue regardless, because a dead man’s switch protects against a lost connection, not against a strategy that is alive, connected and wrong.
What follows for a connector
The honest conclusion is that a unified order model cannot hide these differences; it can only make them explicit. Our approach in Connect is a capability flag per venue and market type for each control above, checked at start-up, so that a strategy asking for reduce-only on a venue that lacks it fails at configuration time rather than at the first fill. The safety the venue does not provide has to be provided by the trading system, and it is better to know on day one which pieces those are.
Avtimエンジニアリングチーム執筆。取引所のドキュメントから引用した数値は執筆時点のものです。取引所は予告なく制限を変更するため、これを前提に構築する前にご確認ください。本記事のいかなる内容も投資助言ではありません。