출처 검증 리서치: Exchange Order Final State

Decision Matrix

Source Map

• Binance Developer Documentation: Account Endpoints (binance-account-endpoints)
• OKX Technical Documentation: OKX API v5 Documentation (okx-api-docs)
• Kraken API Center: Get Order Info (kraken-orders-info)
• Bybit API Documentation: Get Order History (bybit-order-history)
• Bybit API Documentation: Cancel Order (bybit-cancel-order)

Control Notes

1. Final-state source

Final-state source is the point where public documentation must become an operating rule. In this package, it means each venue exposes a different authoritative lookup path. The practical action is to name the endpoint or channel that closes the incident. The unresolved edge is whether archived states are available after retention limits, 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. Lost response

Lost response is the point where public documentation must become an operating rule. In this package, it means network timeout is not an order outcome. The practical action is to query venue-side state before retrying a mutating request. The unresolved edge is whether the first request later succeeds, 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. Fill check

Fill check is the point where public documentation must become an operating rule. In this package, it means cancelled does not always mean no prior fill. The practical action is to query fills or trade history after cancellation. The unresolved edge is whether partial fills create hedge obligations, 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. Error semantics

Error semantics is the point where public documentation must become an operating rule. In this package, it means reject codes can mean timing, permissions, limits or invalid object state. The practical action is to map error class before automated recovery. The unresolved edge is whether wrapper libraries collapse distinct errors, 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. Evidence log

Evidence log is the point where public documentation must become an operating rule. In this package, it means useful evidence is non-secret and repeatable. The practical action is to record URL, timestamp, endpoint, ids and final state only. The unresolved edge is whether screenshots leak balances or strategy details, 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. Stop rule

Stop rule is the point where public documentation must become an operating rule. In this package, it means automation needs a written condition for halting retries. The practical action is to stop when state is ambiguous or source is unavailable. The unresolved edge is whether downstream systems keep acting on stale local state, 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 archived states are available after retention limits
• whether the first request later succeeds
• whether partial fills create hedge obligations
• whether wrapper libraries collapse distinct errors
• whether screenshots leak balances or strategy details
• whether downstream systems keep acting on stale local state

Practical Takeaway

NexuAlpha’s current order-finality radar treats exchange order APIs as reconciliation surfaces rather than execution promises. Binance account endpoints, OKX API documentation, Kraken order-info documentation and Bybit order-history documentation all provide ways to inspect order state after placement, cancellation, rejection or timeout, but the fields, retention behavior and error semantics differ. The practical radar outcome is to require every automation runbook to define the final-state source, the retry stop rule, the fill-history check, the cancellation proof and the non-secret evidence log before using local state as truth. 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.