Kaynak doğrulamalı araştırma: OKX
Gövde metni doğrulanmış İngilizce kaynak dilinde gösteriliyor. Çeviri kaynak incelemesinden sonra eklenecek.
Direct answer
Coinbase Exchange and OKX both document self-trade prevention, but their public control models are not identical. Coinbase documents four Exchange STP behaviors led by decrement-and-cancel, while OKX documents mandatory master-account-level STP with cancel-maker as the default and two alternative API modes. An operator must map account scope, default behavior, supported order types, partial-fill consequences, event messages and historical-order evidence before enabling a multi-strategy trading system.
Analizi kapat
Verified source facts
1. Coinbase Exchange says orders from the same user cannot fill one another and the taker order's STP instruction takes precedence. 2. Coinbase documents decrement-and-cancel, cancel-oldest, cancel-newest and cancel-both behaviors for the Exchange matching engine. 3. OKX says mandatory STP applies at master-account scope, including the master and its affiliated subaccounts across order-book trading products. 4. OKX documents cancel-maker as the default, with cancel-taker and cancel-both available through the API for supported orders.
Comparison at a glance
Makale tablosu: yatay kaydırın veya tablo alanına odaklanıp ok tuşlarını kullanın.
| Decision layer | What to inspect | Minimum safe action |
|---|---|---|
| Account scope | user, portfolio, master account and subaccounts | draw the exact account relationship |
| Default mode | behavior when no explicit parameter is sent | pin the documented default in the strategy spec |
| Cancel maker | treatment of the resting order | model queue-position loss |
| Cancel taker | treatment of the incoming order | handle the rejection or cancellation event |
| Cancel both | whether both sides are removed | reconcile both client order IDs |
| Decrement behavior | quantity reduction rather than full cancellation | consume change or restatement messages |
| Order coverage | supported products and order types | verify the exact endpoint and order schema |
| Event evidence | REST, WebSocket and order-history signals | persist the venue's cancellation reason |
| Strategy ownership | multiple bots sharing one account hierarchy | allocate account boundaries before deployment |
| Test plan | sandbox or minimal-size collision tests | prove every configured mode before scale |
1. Control test: Account scope
A trading-control disclosure is meaningful only when converted into a testable rule. For account scope, inspect user, portfolio, master account and subaccounts. Use a sandbox, non-production context, or the smallest reversible test available, then draw the exact account relationship. Capture configuration and event evidence without recording credentials, and verify the documented cancel, reject, decrement, or history behavior.
Model the failure path, not just the setup path. Ask which strategy owns the maker and taker orders, which account boundary the venue evaluates, which message reveals intervention, and how reconciliation behaves after a partial fill or disconnect. Platform documentation describes supported settings; it cannot prove that an operator configured them correctly. In this dimension, behavior across unrelated legal entities is therefore an explicit audit gap.
The account scope row should end with a concrete monitoring rule tied to user, portfolio, master account and subaccounts. Make the operator draw the exact account relationship, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; behavior across unrelated legal entities remains a separate production risk until observed.
2. Control test: Default mode
For default mode, inspect behavior when no explicit parameter is sent. Use a sandbox, non-production context, or the smallest reversible test available, then pin the documented default in the strategy spec.
In this dimension, future default changes is therefore an explicit audit gap.
The default mode row should end with a concrete monitoring rule tied to behavior when no explicit parameter is sent. Make the operator pin the documented default in the strategy spec, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; future default changes remains a separate production risk until observed.
3. Control test: Cancel maker
For cancel maker, inspect treatment of the resting order. Use a sandbox, non-production context, or the smallest reversible test available, then model queue-position loss.
In this dimension, execution after a network delay is therefore an explicit audit gap.
The cancel maker row should end with a concrete monitoring rule tied to treatment of the resting order. Make the operator model queue-position loss, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; execution after a network delay remains a separate production risk until observed.
4. Control test: Cancel taker
For cancel taker, inspect treatment of the incoming order. Use a sandbox, non-production context, or the smallest reversible test available, then handle the rejection or cancellation event.
Bölgesel uygunluk ve hesap koşullarını kontrol edin
Aç →In this dimension, partial execution under future liquidity is therefore an explicit audit gap.
The cancel taker row should end with a concrete monitoring rule tied to treatment of the incoming order. Make the operator handle the rejection or cancellation event, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; partial execution under future liquidity remains a separate production risk until observed.
5. Control test: Cancel both
For cancel both, inspect whether both sides are removed. Use a sandbox, non-production context, or the smallest reversible test available, then reconcile both client order IDs.
In this dimension, race conditions among concurrent strategies is therefore an explicit audit gap.
The cancel both row should end with a concrete monitoring rule tied to whether both sides are removed. Make the operator reconcile both client order IDs, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; race conditions among concurrent strategies remains a separate production risk until observed.
6. Control test: Decrement behavior
For decrement behavior, inspect quantity reduction rather than full cancellation. Use a sandbox, non-production context, or the smallest reversible test available, then consume change or restatement messages.
In this dimension, rounding at product precision is therefore an explicit audit gap.
The decrement behavior row should end with a concrete monitoring rule tied to quantity reduction rather than full cancellation. Make the operator consume change or restatement messages, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; rounding at product precision remains a separate production risk until observed.
7. Control test: Order coverage
For order coverage, inspect supported products and order types. Use a sandbox, non-production context, or the smallest reversible test available, then verify the exact endpoint and order schema.
In this dimension, availability for a new product is therefore an explicit audit gap.
The order coverage row should end with a concrete monitoring rule tied to supported products and order types. Make the operator verify the exact endpoint and order schema, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; availability for a new product remains a separate production risk until observed.
8. Control test: Event evidence
For event evidence, inspect REST, WebSocket and order-history signals. Use a sandbox, non-production context, or the smallest reversible test available, then persist the venue's cancellation reason.
In this dimension, message loss during an outage is therefore an explicit audit gap.
The event evidence row should end with a concrete monitoring rule tied to REST, WebSocket and order-history signals. Make the operator persist the venue's cancellation reason, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; message loss during an outage remains a separate production risk until observed.
9. Control test: Strategy ownership
For strategy ownership, inspect multiple bots sharing one account hierarchy. Use a sandbox, non-production context, or the smallest reversible test available, then allocate account boundaries before deployment.
In this dimension, human orders crossing automated orders is therefore an explicit audit gap.
The strategy ownership row should end with a concrete monitoring rule tied to multiple bots sharing one account hierarchy. Make the operator allocate account boundaries before deployment, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; human orders crossing automated orders remains a separate production risk until observed.
10. Control test: Test plan
For test plan, inspect sandbox or minimal-size collision tests. Use a sandbox, non-production context, or the smallest reversible test available, then prove every configured mode before scale.
In this dimension, production-only edge behavior is therefore an explicit audit gap.
The test plan row should end with a concrete monitoring rule tied to sandbox or minimal-size collision tests. Make the operator prove every configured mode before scale, retain the venue response, and assign an owner for exceptions. Documentation quality is a useful signal, but it does not certify the exchange or the trading system; production-only edge behavior remains a separate production risk until observed.
Decision scenarios
Scenario 1: when account scope becomes decisive
Consider a reader whose main constraint is user, portfolio, master account and subaccounts. The correct response is not to infer a universal platform or product winner. It is to draw the exact account relationship, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.
Scenario 2: when default mode becomes decisive
Consider a reader whose main constraint is behavior when no explicit parameter is sent. It is to pin the documented default in the strategy spec, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 3: when cancel maker becomes decisive
Consider a reader whose main constraint is treatment of the resting order. It is to model queue-position loss, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 4: when cancel taker becomes decisive
Consider a reader whose main constraint is treatment of the incoming order. It is to handle the rejection or cancellation event, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 5: when cancel both becomes decisive
Consider a reader whose main constraint is whether both sides are removed. It is to reconcile both client order IDs, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 6: when decrement behavior becomes decisive
Consider a reader whose main constraint is quantity reduction rather than full cancellation. It is to consume change or restatement messages, retain the evidence, and define a stop condition before funds or permissions are committed.
Konular ve araçlar:Borsa API'leri ve piyasa verisi
Bölgesel uygunluk ve hesap koşullarını kontrol edin
Aç →Kaynaklar
05- Exchange matching engine and self-trade prevention
- Create a new Exchange order
- Exchange WebSocket channels
- OKX mandatory self-trade prevention · okx.com
- OKX self trade prevention modes · okx.com