Binance 与 Bybit 自成交防护和阻止成交控制对比
已验证事实边界
1. Binance Spot documentation describes Self Trade Prevention as a feature preventing a user or tradeGroupId from matching against itself. 2. Binance Spot documentation uses selfTradePreventionMode to define what happens when an order could cause a self-trade. 3. Binance account endpoints expose prevented-match evidence fields and account prevented-match queries for order review. 4. Bybit V5 documentation describes Self Match Prevention and smpType modes such as cancel taker, cancel maker and cancel both. 5. Bybit create-order documentation exposes smpType as an order parameter, while cancel-order documentation defines the cancel surface separately. 6. A safe comparison separates prevention configuration, account scope, cancellation consequence, prevented-match evidence and final order-state reconciliation.
收起完整分析
决策矩阵
文章表格:可横向滑动,或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Prevention mode | Binance uses selfTradePreventionMode while Bybit uses smpType language | record the configured mode before placing orders | whether a UI default differs from the API payload |
| Account scope | Binance references user and tradeGroupId while Bybit SMP behavior depends on account configuration | map the exact account, sub-account and group boundary | whether linked accounts share a prevention group |
| Order identity | prevented-match evidence is only useful when order ids and client ids are preserved | store non-secret order identifiers before retry or cancel | whether wrapper libraries replace client identifiers |
| Cancel consequence | cancel taker, cancel maker or cancel both have different inventory effects | simulate each mode with harmless fixtures before live use | whether partial fills change the risk meaning |
| Evidence after rejection | a prevention event is not the same as no exposure | query final order state and trade history after every prevention event | whether delayed fills arrive after the local bot has moved on |
| Secret hygiene | STP debugging can expose account and order metadata even without API secrets | log source URL, endpoint, mode, order state and timestamp only | whether screenshots reveal balances or strategy intent |
来源地图
- Binance Developer Documentation:Self-Trade Prevention FAQ(binance-stp-faq)
- Binance Developer Documentation:General REST API Information(binance-spot-rest)
- Binance Developer Documentation:Account Endpoints(binance-account-endpoints)
- Bybit API Documentation:Self Match Prevention(bybit-smp)
- Bybit API Documentation:Create Order(bybit-create-order)
- Bybit API Documentation:Cancel Order(bybit-cancel-order)
控制说明
1. Prevention mode
这一项要求读者把公开来源翻译成操作规则。这里的含义是:Binance uses selfTradePreventionMode while Bybit uses smpType language。可执行动作是:record the configured mode before placing orders。仍然未知的是:whether a UI default differs from the API payload。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。
2. Account scope
这里的含义是:Binance references user and tradeGroupId while Bybit SMP behavior depends on account configuration。可执行动作是:map the exact account, sub-account and group boundary。仍然未知的是:whether linked accounts share a prevention group。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
3. Order identity
这里的含义是:prevented-match evidence is only useful when order ids and client ids are preserved。可执行动作是:store non-secret order identifiers before retry or cancel。仍然未知的是:whether wrapper libraries replace client identifiers。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
4. Cancel consequence
这里的含义是:cancel taker, cancel maker or cancel both have different inventory effects。可执行动作是:simulate each mode with harmless fixtures before live use。仍然未知的是:whether partial fills change the risk meaning。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
5. Evidence after rejection
这里的含义是:a prevention event is not the same as no exposure。可执行动作是:query final order state and trade history after every prevention event。仍然未知的是:whether delayed fills arrive after the local bot has moved on。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
6. Secret hygiene
这里的含义是:STP debugging can expose account and order metadata even without API secrets。可执行动作是:log source URL, endpoint, mode, order state and timestamp only。仍然未知的是:whether screenshots reveal balances or strategy intent。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
仍需明确的未知项
- whether a UI default differs from the API payload
- whether linked accounts share a prevention group
- whether wrapper libraries replace client identifiers
- whether partial fills change the risk meaning
- whether delayed fills arrive after the local bot has moved on
- whether screenshots reveal balances or strategy intent
实用结论
Binance 与 Bybit 都记录了自成交防护控制,但可操作证据并不相同。Binance Spot 文档通过 selfTradePreventionMode、tradeGroupId、prevented-match 字段和账户 prevented-match 查询来描述 STP,同时其 REST API 文档把 signed trading requests 放在 API key 权限和 timestamp 控制内。Bybit V5 文档通过 smpType 描述 Self Match Prevention,例如 cancel taker、cancel maker、cancel both,并把该设置与下单和订单历史证据关联。实用结论是:在机器人把任一平台视为已防止自成交前,先证明 prevention mode、账户或 group 范围、订单标识、阻止数量、撤单后果和最终订单状态。 本文停在证据边界内,帮助读者决定下一步核验什么,而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。
相关专题与工具:任选两家交易所对比对比 Binance 与 Bybit
来源与证据
06- Self-Trade Prevention FAQ · developers.binance.com
- General REST API Information · developers.binance.com
- Account Endpoints · developers.binance.com
- Self Match Prevention
- Create Order
- Cancel Order