Exchange Updates

Quellengeprüfte Recherche: Kraken Websocket Token Deadman

5 Min.

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

Verified Fact Boundary

1. Kraken support documentation describes authenticated WebSocket trading through a token obtained from a REST token endpoint. 2. Kraken support documentation describes addOrder and cancelOrder messages over an authenticated WebSocket connection. 3. Kraken API key information documentation lists permissions including create-ws-token and order or trade permissions. 4. Kraken Futures documentation describes a dead man's switch endpoint that cancels orders after a timeout unless refreshed. 5. Kraken Futures trade history provides a separate surface for checking recent trade history. 6. A radar should separate token acquisition, WebSocket command acknowledgement, dead-man timeout, state query and evidence hygiene.

Weniger anzeigen

Decision Matrix

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

CheckWhat it meansPractical actionUnknown to keep explicit
Token permissionWebSocket trading requires the correct API-key permission surfaceverify create-ws-token and order permissions without exposing the keywhether an old key lacks the needed permission
Connection reusea private WebSocket session is intended to handle repeated order messagesreuse and monitor a stable authenticated connectionwhether reconnect logic creates duplicate commands
Cancel acknowledgementa cancel message acknowledgement is not the same as full portfolio reconciliationstore non-secret txid and cancel status onlywhether an already-filled order was locally treated as cancelled
Dead-man timeoutthe switch protects only when the refresh cadence is maintainedset timeout and refresh interval as explicit strategy parameterswhether network delay caused timer expiry or failed refresh
Fallback queryfinal state needs a separate query surface after anomaliesquery trade or order history before resuming strategywhether history retention or restart windows omit the event
Evidence hygieneAPI logs can leak credentials or strategy timingretain source URL, permission label, event id, time and stop rulewhether screenshots expose balances or positions

Source Map

  • Kraken Support: WebSocket API v1 - placing and cancelling orders (kraken-ws-trading)
  • Kraken API Center: Get API Key Info (kraken-api-key-info)
  • Kraken API Center: Dead man's switch (kraken-deadman-switch)
  • Kraken API Center: Get trade history (kraken-futures-history)

Control Notes

1. Token permission

Token permission is the point where public documentation must become an operating rule. In this package, it means WebSocket trading requires the correct API-key permission surface. The practical action is to verify create-ws-token and order permissions without exposing the key. The unresolved edge is whether an old key lacks the needed permission, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

2. Connection reuse

Connection reuse is the point where public documentation must become an operating rule. In this package, it means a private WebSocket session is intended to handle repeated order messages. The practical action is to reuse and monitor a stable authenticated connection. The unresolved edge is whether reconnect logic creates duplicate commands, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

3. Cancel acknowledgement

Cancel acknowledgement is the point where public documentation must become an operating rule. In this package, it means a cancel message acknowledgement is not the same as full portfolio reconciliation. The practical action is to store non-secret txid and cancel status only. The unresolved edge is whether an already-filled order was locally treated as cancelled, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

4. Dead-man timeout

Dead-man timeout is the point where public documentation must become an operating rule. In this package, it means the switch protects only when the refresh cadence is maintained. The practical action is to set timeout and refresh interval as explicit strategy parameters. The unresolved edge is whether network delay caused timer expiry or failed refresh, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

5. Fallback query

Fallback query is the point where public documentation must become an operating rule. In this package, it means final state needs a separate query surface after anomalies. The practical action is to query trade or order history before resuming strategy. The unresolved edge is whether history retention or restart windows omit the event, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

6. Evidence hygiene

Evidence hygiene is the point where public documentation must become an operating rule. In this package, it means API logs can leak credentials or strategy timing. The practical action is to retain source URL, permission label, event id, time and stop rule. The unresolved edge is whether screenshots expose balances or positions, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

Known Unknowns

  • whether an old key lacks the needed permission
  • whether reconnect logic creates duplicate commands
  • whether an already-filled order was locally treated as cancelled
  • whether network delay caused timer expiry or failed refresh
  • whether history retention or restart windows omit the event
  • whether screenshots expose balances or positions

Practical Takeaway

Kraken order automation should separate WebSocket session control from dead man's switch protection. Kraken support documentation says authenticated WebSocket trading uses a token retrieved through GetWebSocketsToken and that the authenticated connection can place and cancel orders. Kraken Futures API documentation describes a cancel-all-orders-after endpoint as a dead man's switch that must be refreshed or deactivated. The radar conclusion is to record token permission, connection reuse, cancel acknowledgement, timeout refresh cadence, fallback query and non-secret evidence before assuming a disconnected bot is safe. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, API key, pool route, stablecoin balance, tokenized asset or policy framework will work under every future condition.

Quellen

04
  1. Kraken SupportWebSocket API v1 - placing and cancelling orders · support.kraken.com
  2. Kraken API CenterGet API Key Info · docs.kraken.com
  3. Kraken API CenterDead man's switch · docs.kraken.com
  4. Kraken API CenterGet trade history · docs.kraken.com