Exchange Updates

Riset terverifikasi sumber: OKX

8 mnt

Isi artikel ditampilkan dalam bahasa Inggris asli yang telah diverifikasi. Terjemahan ditambahkan setelah tinjauan sumber.

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.

Tampilkan lebih sedikit

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

Tabel artikel: gulir secara horizontal atau fokuskan area tabel dan gunakan tombol panah.

Decision layerWhat to inspectMinimum safe action
Account scopeuser, portfolio, master account and subaccountsdraw the exact account relationship
Default modebehavior when no explicit parameter is sentpin the documented default in the strategy spec
Cancel makertreatment of the resting ordermodel queue-position loss
Cancel takertreatment of the incoming orderhandle the rejection or cancellation event
Cancel bothwhether both sides are removedreconcile both client order IDs
Decrement behaviorquantity reduction rather than full cancellationconsume change or restatement messages
Order coveragesupported products and order typesverify the exact endpoint and order schema
Event evidenceREST, WebSocket and order-history signalspersist the venue's cancellation reason
Strategy ownershipmultiple bots sharing one account hierarchyallocate account boundaries before deployment
Test plansandbox or minimal-size collision testsprove 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.

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.

Sumber

05
  1. Coinbase Developer DocumentationExchange matching engine and self-trade prevention
  2. Coinbase Developer DocumentationCreate a new Exchange order
  3. Coinbase Developer DocumentationExchange WebSocket channels
  4. OKX Help CenterOKX mandatory self-trade prevention · okx.com
  5. OKX API DocumentationOKX self trade prevention modes · okx.com
Pilih jalur riset berikutnya