Binance cancelReplace 与 OKX 订单状态最终性控制对比
已验证事实边界
1. Binance says orderRateLimitExceededMode applies when the order rate limit is exceeded. 2. Binance says orderRateLimitExceededMode allows cancelReplace to cancel orders but does not allow placing new orders. 3. Binance lists REST POST /api/v3/order/cancelReplace and WebSocket order.cancelReplace as affected endpoints. 4. OKX says failed affected post-only placement now pushes only state canceled, without state live first. 5. OKX says regular limit, market, ioc and fok order types remain unchanged by the push-behavior adjustment.
收起完整分析
决策矩阵
文章表格:可横向滑动,或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Acknowledgement | the exchange has received or accepted an order message | separate transport acknowledgement from final order state | gateway latency and private matching details |
| Final state | the last usable order state after validation, book entry, fill or cancellation | wait for the explicit state update before reconciling | private account event timing |
| Post-only exception | an order type that can cancel when it would cross the book | treat live-then-canceled sequences as a special case | future matching-engine rules |
| Amend result | the source field that explains a successful or failed amendment | record amend result and source before retrying | venue-specific reject reason depth |
| Cancel result | confirmation that an order is canceled rather than merely requested | wait for canceled state before reusing exposure | network or session failure timing |
| Rate-limit mode | how requests behave when order-rate limits are hit | design retry budgets around documented limits | private account tier or subaccount limits |
| WebSocket channel | the feed that carries order-state updates | subscribe and reconcile before trusting UI-only state | connection drop handling |
| REST fallback | the secondary route for order checks or repair | use only with idempotent identifiers and logs | venue incident behavior |
| Evidence packet | non-secret request id, order id, timestamp and official URL | store operational evidence without API secrets | sensitive account values |
| Stop rule | when the article cannot support action | stop if accepted, live, filled and canceled states are conflated | future API changes |
来源地图
- Binance Support:Binance Spot API Service Upgrade (2024-06-06)(binance-cancelreplace)
- Binance Developers:Binance Spot API documentation(binance-spot-doc)
- OKX Europe:OKX WebSocket Orders Channel Push Behavior Adjustment Announcement(okx-websocket-orders)
- OKX Technical Support:OKX API guide(okx-api-guide)
控制说明
1. Acknowledgement
这一项要求读者把公开来源转换成操作规则。这里的含义是:the exchange has received or accepted an order message。可执行动作是:separate transport acknowledgement from final order state。仍然未知的是:gateway latency and private matching details。因此本文不会把未知部分包装成安全承诺、收益承诺、官方背书、审批保证、可用性保证或注册诱导。
2. Final state
这里的含义是:the last usable order state after validation, book entry, fill or cancellation。可执行动作是:wait for the explicit state update before reconciling。仍然未知的是:private account event timing。
3. Post-only exception
这里的含义是:an order type that can cancel when it would cross the book。可执行动作是:treat live-then-canceled sequences as a special case。仍然未知的是:future matching-engine rules。
4. Amend result
这里的含义是:the source field that explains a successful or failed amendment。可执行动作是:record amend result and source before retrying。仍然未知的是:venue-specific reject reason depth。
5. Cancel result
这里的含义是:confirmation that an order is canceled rather than merely requested。可执行动作是:wait for canceled state before reusing exposure。仍然未知的是:network or session failure timing。
6. Rate-limit mode
这里的含义是:how requests behave when order-rate limits are hit。可执行动作是:design retry budgets around documented limits。仍然未知的是:private account tier or subaccount limits。
7. WebSocket channel
这里的含义是:the feed that carries order-state updates。可执行动作是:subscribe and reconcile before trusting UI-only state。仍然未知的是:connection drop handling。
8. REST fallback
这里的含义是:the secondary route for order checks or repair。可执行动作是:use only with idempotent identifiers and logs。仍然未知的是:venue incident behavior。
9. Evidence packet
这里的含义是:non-secret request id, order id, timestamp and official URL。可执行动作是:store operational evidence without API secrets。仍然未知的是:sensitive account values。
10. Stop rule
这里的含义是:when the article cannot support action。可执行动作是:stop if accepted, live, filled and canceled states are conflated。仍然未知的是:future API changes。
实用结论
本文最有价值的地方是克制。Binance 与 OKX 暴露的是不同的 API 订单修复问题。Binance Spot API 升级说明,orderRateLimitExceededMode 会在订单速率限制超出时允许 cancelReplace 撤单,但不允许继续下新订单,涉及 REST POST /api/v3/order/cancelReplace 与 WebSocket order.cancelReplace。OKX 的 WebSocket 更新则收窄 post-only 与 RPI 工作流中的状态解释:失败下单可只显示 canceled,成功入簿后才延迟推送 state live。决策重点不是哪个平台绝对更安全,而是交易机器人是否能区分修复撤单、新订单准入、入簿确认和最终状态。 用户应获得一个更清楚的核验路径,而不是一个看似肯定、实则无法由公开证据承担的承诺。
相关专题与工具:任选两家交易所对比对比 Binance 与 OKX
来源与证据
04- Binance Spot API Service Upgrade (2024-06-06)
- Binance Spot API documentation · developers.binance.com
- OKX WebSocket Orders Channel Push Behavior Adjustment Announcement · okx.com
- OKX API guide · okx.com