Binance 与 OKX API Timestamp Signatures：重放与时钟漂移风险雷达
已验证事实边界
1. Binance WebSocket API request-security documentation describes SIGNED request security and timestamp-related request validation. 2. Binance WebSocket API documentation includes general API information that shapes request handling and error interpretation. 3. OKX REST authentication documentation describes signed requests using timestamp, method, request path and body as signature inputs. 4. OKX trade WebSocket documentation is a separate private order route surface and should not be conflated with REST signing. 5. Timestamp drift, receive-window assumptions and signature canonicalization are distinct failure causes that can look similar to users. 6. Public API documentation does not prove private account permission, order acceptance, withdrawal acceptance, support recovery or future rate limits.
收起完整分析
决策矩阵
文章表格：可横向滑动，或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Clock source | client and server time assumptions can decide whether a signed request is accepted | log non-secret local time, server time probe, skew and retry decision | future latency and server-side tolerance |
| Signature input | the signed bytes differ by venue, route and request body rules | store the canonical string shape without storing the secret key | whether a library changes serialization in a future version |
| Replay window | timestamp and receive-window controls are replay protection, not execution guarantees | separate authentication success from order, transfer or withdrawal success | private risk checks after authentication |
| Retry label | time drift, bad signature, permission and rate limit errors require different recovery paths | write user-facing labels that do not ask for secrets or screenshots of credentials | support diagnosis for private-account failures |
| Stop condition | a retry loop can become dangerous if it hides auth failures behind generic network errors | stop after bounded retries and require a signed-request audit without secrets | future venue changes and account-side restrictions |
来源地图
- 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）
控制说明
1. Clock source
这一项要求读者把公开来源翻译成操作规则。这里的含义是：client and server time assumptions can decide whether a signed request is accepted。可执行动作是：log non-secret local time, server time probe, skew and retry decision。仍然未知的是：future latency and server-side tolerance。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。
2. Signature input
这里的含义是：the signed bytes differ by venue, route and request body rules。可执行动作是：store the canonical string shape without storing the secret key。仍然未知的是：whether a library changes serialization in a future version。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
3. Replay window
这里的含义是：timestamp and receive-window controls are replay protection, not execution guarantees。可执行动作是：separate authentication success from order, transfer or withdrawal success。仍然未知的是：private risk checks after authentication。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
4. Retry label
这里的含义是：time drift, bad signature, permission and rate limit errors require different recovery paths。可执行动作是：write user-facing labels that do not ask for secrets or screenshots of credentials。仍然未知的是：support diagnosis for private-account failures。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
5. Stop condition
这里的含义是：a retry loop can become dangerous if it hides auth failures behind generic network errors。可执行动作是：stop after bounded retries and require a signed-request audit without secrets。仍然未知的是：future venue changes and account-side restrictions。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
仍需明确的未知项
- 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
实用结论
Binance 与 OKX 都要求私有 API 请求签名，但它们的 replay-control 证据必须按平台认证规则分别记录。Binance WebSocket API security 文档描述 SIGNED request 的 timestamp 与 recvWindow 等参数；OKX API 文档描述由 timestamp、method、request path 和 body 组成的签名输入。实际雷达结论是：交易机器人在 time-drift 失败后重试私有订单或提现前，应记录平台、时钟来源、timestamp 格式、receive-window 假设、request body canonicalization、signature input 和拒绝标签。 本文停在证据边界内，帮助读者决定下一步核验什么，而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。
相关专题与工具:对比 Binance 与 OKXDrift 平台档案与费率交易所 API 与行情数据核查
来源与证据
04- WebSocket API Request Security · developers.binance.com
- WebSocket API General API Information · developers.binance.com
- REST Authentication · okx.com
- Trade WebSocket Place Order · okx.com