Binance and OKX API Timestamp Signatures: Replay and Drift Risk Radar

Decision Matrix

Source Map

• Binance Developers: WebSocket API Request Security (binance-request-security)
• Binance Developers: WebSocket API General API Information (binance-general-api)
• OKX: REST Authentication (okx-rest-auth)
• OKX: Trade WebSocket Place Order (okx-trade-ws-place-order)

Control Notes

1. Clock source

Clock source is the point where public documentation must become an operating rule. In this package, it means client and server time assumptions can decide whether a signed request is accepted. The practical action is to log non-secret local time, server time probe, skew and retry decision. The unresolved edge is future latency and server-side tolerance, 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. Signature input

Signature input is the point where public documentation must become an operating rule. In this package, it means the signed bytes differ by venue, route and request body rules. The practical action is to store the canonical string shape without storing the secret key. The unresolved edge is whether a library changes serialization in a future version, 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. Replay window

Replay window is the point where public documentation must become an operating rule. In this package, it means timestamp and receive-window controls are replay protection, not execution guarantees. The practical action is to separate authentication success from order, transfer or withdrawal success. The unresolved edge is private risk checks after authentication, 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. Retry label

Retry label is the point where public documentation must become an operating rule. In this package, it means time drift, bad signature, permission and rate limit errors require different recovery paths. The practical action is to write user-facing labels that do not ask for secrets or screenshots of credentials. The unresolved edge is support diagnosis for private-account failures, 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. Stop condition

Stop condition is the point where public documentation must become an operating rule. In this package, it means a retry loop can become dangerous if it hides auth failures behind generic network errors. The practical action is to stop after bounded retries and require a signed-request audit without secrets. The unresolved edge is future venue changes and account-side restrictions, 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

• future latency and server-side tolerance
• whether a library changes serialization in a future version
• private risk checks after authentication
• support diagnosis for private-account failures
• future venue changes and account-side restrictions

Practical Takeaway

Binance and OKX both require signed private API requests, but their replay-control evidence should be recorded as venue-specific authentication rules. Binance WebSocket API security documentation describes SIGNED request parameters such as timestamp and recvWindow. OKX API documentation describes request signing with timestamp, method, request path and body. The practical radar finding is that bots should store venue, clock source, timestamp format, receive-window assumption, request body canonicalization, signature input and reject labels before retrying private orders or withdrawals after a time-drift failure. 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.