Исследование с проверкой источников: Coinbase VS Kraken Order

Decision Matrix

Source Map

• Coinbase Developer Platform: Create API Keys on Coinbase Developer Platform (coinbase-auth)
• Coinbase Developer Platform: Advanced Trade API Endpoints (coinbase-endpoints)
• Kraken API Center: Cancel All Orders (kraken-cancel-all)
• Kraken API Center: Dead man's switch (kraken-deadman)

Control Notes

1. Preview surface

Preview surface is the point where public documentation must become an operating rule. In this package, it means Coinbase exposes an order preview endpoint while Kraken evidence here centers cancel scopes and timers. The practical action is to require a preview or dry-run equivalent before live order creation. The unresolved edge is whether every order type has a complete preview path, 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. Permission scope

Permission scope is the point where public documentation must become an operating rule. In this package, it means API keys differ by view, trade, transfer or cancel permissions. The practical action is to start with read-only or the smallest trade permission needed. The unresolved edge is whether inherited portfolio or sub-account scope is obvious, 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 scope

Cancel scope is the point where public documentation must become an operating rule. In this package, it means batch cancel, cancel-all and dead-man controls remove different sets of orders. The practical action is to write down which orders the cancel command can touch. The unresolved edge is whether partially filled orders leave residual exposure, 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. Timer behavior

Timer behavior is the point where public documentation must become an operating rule. In this package, it means a dead man's switch depends on continuous refresh and timeout interpretation. The practical action is to test timer refresh, zero deactivation and outage behavior outside production. The unresolved edge is whether network jitter causes unwanted cancellation, 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. Final order state

Final order state is the point where public documentation must become an operating rule. In this package, it means accepted, open, pending, canceled and filled states are not interchangeable. The practical action is to query final state before retrying or replacing an order. The unresolved edge is whether stale local state hides an executed fill, 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 debug logs are useful only if they omit secrets and balances. The practical action is to store endpoint, request id, client id, non-secret timestamps and result class. The unresolved edge is what private support data may still be required, 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 every order type has a complete preview path
• whether inherited portfolio or sub-account scope is obvious
• whether partially filled orders leave residual exposure
• whether network jitter causes unwanted cancellation
• whether stale local state hides an executed fill
• what private support data may still be required

Practical Takeaway

Coinbase Advanced Trade and Kraken expose different order-control surfaces, so the useful comparison is not brand preference but failure-mode coverage. Coinbase documents Advanced Trade v3 endpoints for create order, batch cancel, list orders, fills, get order and preview orders, with API-key permissions split across view, trade and transfer. Kraken documents spot cancel-all permissions and a futures dead man's switch endpoint that can cancel orders after a timer if the user stops refreshing it. A safe decision record compares preview, permission, cancel scope, timer behavior, final order state, partial fills and non-secret evidence before any production automation places orders. 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.