Comparisons

Quellengeprüfte Recherche: Deribit

8 Min.

Der Artikeltext wird im geprüften englischen Original angezeigt. Die Übersetzung folgt nach der Quellenprüfung.

Direct answer

Kraken Futures and Deribit both document controls that can cancel resting orders after connectivity failure, but they use different activation models. Kraken's futures dead-man switch is a renewable countdown: the client repeatedly pushes back a timeout, with the documentation recommending 15–20 second calls and a 60-second timeout. Deribit's WebSocket-only cancel-on-disconnect can apply to one connection or at account scope for newly opened connections, and heartbeats improve stale-connection detection; graceful logout is a documented exception. Neither control proves every order was cancelled. Operators must test scope, trigger timing, partial fills, reconnect behavior and authoritative post-event reconciliation in a non-production environment.

Weniger anzeigen

Verified source facts

1. Kraken Futures documents a countdown that cancels user orders when the timeout expires unless the client renews or disables it. 2. Kraken recommends refreshing every 15 to 20 seconds with a 60-second timeout as an example operating pattern. 3. Deribit documents WebSocket-only cancel-on-disconnect with connection and account scopes, where connection scope does not affect orders created by other connections. 4. Deribit says heartbeat detection can improve triggering and that private logout does not trigger cancel-on-disconnect.

Comparison at a glance

Artikeltabelle: horizontal scrollen oder den Tabellenbereich fokussieren und die Pfeiltasten verwenden.

Decision layerWhat to inspectMinimum safe action
Activationcountdown request or WebSocket settingmake activation explicit
Scopeuser, account or connection order ownershiptag every order by session
Timeoutdelay before cancellationtest with measured network failure
Heartbeatstale-connection detectionmonitor request and response cadence
Graceful closelogout versus abnormal disconnecttest both branches separately
Partial fillquantity executed before cancellationreconcile fills before replacement
Order classregular, trigger and other resting ordersbuild an explicit coverage matrix
Reconnectstate after a new session opensquery authoritative open orders
PermissionsAPI scope required to manage ordersapply least privilege
Evidencetrigger time, cancel result and remaining ordersretain non-secret event records

1. Control test: Activation

A trading-control disclosure is meaningful only when converted into a testable rule. For activation, inspect countdown request or WebSocket setting. Use a sandbox, non-production context, or the smallest reversible test available, then make activation explicit. 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, account defaults is therefore an explicit audit gap.

The activation row should end with a concrete monitoring rule tied to countdown request or WebSocket setting. Make the operator make activation explicit, 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; account defaults remains a separate production risk until observed.

2. Control test: Scope

For scope, inspect user, account or connection order ownership. Use a sandbox, non-production context, or the smallest reversible test available, then tag every order by session.

In this dimension, cross-session behavior is therefore an explicit audit gap.

The scope row should end with a concrete monitoring rule tied to user, account or connection order ownership. Make the operator tag every order by session, 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; cross-session behavior remains a separate production risk until observed.

3. Control test: Timeout

For timeout, inspect delay before cancellation. Use a sandbox, non-production context, or the smallest reversible test available, then test with measured network failure.

In this dimension, exchange-side scheduling is therefore an explicit audit gap.

The timeout row should end with a concrete monitoring rule tied to delay before cancellation. Make the operator test with measured network failure, 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; exchange-side scheduling remains a separate production risk until observed.

4. Control test: Heartbeat

For heartbeat, inspect stale-connection detection. Use a sandbox, non-production context, or the smallest reversible test available, then monitor request and response cadence.

In this dimension, silent partition is therefore an explicit audit gap.

The heartbeat row should end with a concrete monitoring rule tied to stale-connection detection. Make the operator monitor request and response cadence, 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; silent partition remains a separate production risk until observed.

5. Control test: Graceful close

For graceful close, inspect logout versus abnormal disconnect. Use a sandbox, non-production context, or the smallest reversible test available, then test both branches separately.

In this dimension, client-library behavior is therefore an explicit audit gap.

The graceful close row should end with a concrete monitoring rule tied to logout versus abnormal disconnect. Make the operator test both branches separately, 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; client-library behavior remains a separate production risk until observed.

6. Control test: Partial fill

For partial fill, inspect quantity executed before cancellation. Use a sandbox, non-production context, or the smallest reversible test available, then reconcile fills before replacement.

In this dimension, race timing is therefore an explicit audit gap.

The partial fill row should end with a concrete monitoring rule tied to quantity executed before cancellation. Make the operator reconcile fills before replacement, 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 timing remains a separate production risk until observed.

7. Control test: Order class

For order class, inspect regular, trigger and other resting orders. Use a sandbox, non-production context, or the smallest reversible test available, then build an explicit coverage matrix.

In this dimension, future product additions is therefore an explicit audit gap.

The order class row should end with a concrete monitoring rule tied to regular, trigger and other resting orders. Make the operator build an explicit coverage matrix, 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 product additions remains a separate production risk until observed.

8. Control test: Reconnect

For reconnect, inspect state after a new session opens. Use a sandbox, non-production context, or the smallest reversible test available, then query authoritative open orders.

In this dimension, delayed cancellation is therefore an explicit audit gap.

The reconnect row should end with a concrete monitoring rule tied to state after a new session opens. Make the operator query authoritative open orders, 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; delayed cancellation remains a separate production risk until observed.

9. Control test: Permissions

For permissions, inspect API scope required to manage orders. Use a sandbox, non-production context, or the smallest reversible test available, then apply least privilege.

In this dimension, credential compromise is therefore an explicit audit gap.

The permissions row should end with a concrete monitoring rule tied to API scope required to manage orders. Make the operator apply least privilege, 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; credential compromise remains a separate production risk until observed.

10. Control test: Evidence

For evidence, inspect trigger time, cancel result and remaining orders. Use a sandbox, non-production context, or the smallest reversible test available, then retain non-secret event records.

In this dimension, retention period is therefore an explicit audit gap.

The evidence row should end with a concrete monitoring rule tied to trigger time, cancel result and remaining orders. Make the operator retain non-secret event records, 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; retention period remains a separate production risk until observed.

Decision scenarios

Scenario 1: when activation becomes decisive

Consider a reader whose main constraint is countdown request or WebSocket setting. The correct response is not to infer a universal platform or product winner. It is to make activation explicit, 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 scope becomes decisive

Consider a reader whose main constraint is user, account or connection order ownership. It is to tag every order by session, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when timeout becomes decisive

Consider a reader whose main constraint is delay before cancellation. It is to test with measured network failure, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when heartbeat becomes decisive

Consider a reader whose main constraint is stale-connection detection. It is to monitor request and response cadence, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when graceful close becomes decisive

Consider a reader whose main constraint is logout versus abnormal disconnect. It is to test both branches separately, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when partial fill becomes decisive

Consider a reader whose main constraint is quantity executed before cancellation. It is to reconcile fills before replacement, retain the evidence, and define a stop condition before funds or permissions are committed.

Quellen

04
  1. Kraken SupportDerivatives Platform Outage Options and Dead Man's Switch · support.kraken.com
  2. Kraken SupportKraken Derivatives API URLs · support.kraken.com
  3. Deribit APIEnable Cancel on Disconnect · docs.deribit.com
  4. Deribit SupportConnection Management Best Practices · support.deribit.com
Nächsten Rechercheweg auswählen