Bybit Self Match Prevention：smpType 与订单历史准备清单
已验证事实边界
1. Bybit V5 documentation describes Self Match Prevention as a function where users can choose an execution method when placing an order. 2. Bybit create-order documentation exposes smpType as part of the order request surface. 3. Bybit cancel-order documentation defines cancellation separately from SMP configuration. 4. Bybit order-history documentation is the evidence surface for reviewing final order lifecycle state after a prevention or cancellation event. 5. Bybit V5 changelog material records API field changes over time, so integrations should verify current response fields instead of relying on old wrappers. 6. A Bybit SMP runbook should separate requested mode, accepted order, cancel result, order-history state and non-secret audit log.
收起完整分析
决策矩阵
文章表格：可横向滑动，或聚焦表格区域后使用方向键。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Mode selection | smpType is chosen at order entry rather than inferred later | pin the mode in the strategy config and evidence log | whether the trading UI uses a different default |
| Accepted request | an order request can be rejected before SMP ever matters | record accepted order id or rejection class | whether a retry created a replacement order |
| Cancel path | cancel endpoints are evidence surfaces separate from prevention settings | keep cancel request and final state together | whether a cancel raced with execution |
| History review | order history is needed to prove the final lifecycle result | query history after lost responses or prevention events | whether archived order retention is enough for audit needs |
| Changelog drift | API fields can change across V5 updates | refresh wrappers against current docs before production changes | whether a client library hides new fields |
| Operational log | useful evidence should not expose keys, balances or full strategy logic | redact payloads and preserve only source, endpoint, id and state | whether debug logs leak account structure |
来源地图
- Bybit API Documentation：Self Match Prevention（bybit-smp）
- Bybit API Documentation：Create Order（bybit-create-order）
- Bybit API Documentation：Cancel Order（bybit-cancel-order）
- Bybit API Documentation：Get Order History（bybit-order-history）
- Bybit API Documentation：V5 Changelog（bybit-v5-changelog）
控制说明
1. Mode selection
这一项要求读者把公开来源翻译成操作规则。这里的含义是：smpType is chosen at order entry rather than inferred later。可执行动作是：pin the mode in the strategy config and evidence log。仍然未知的是：whether the trading UI uses a different default。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。
2. Accepted request
这里的含义是：an order request can be rejected before SMP ever matters。可执行动作是：record accepted order id or rejection class。仍然未知的是：whether a retry created a replacement order。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
3. Cancel path
这里的含义是：cancel endpoints are evidence surfaces separate from prevention settings。可执行动作是：keep cancel request and final state together。仍然未知的是：whether a cancel raced with execution。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
4. History review
这里的含义是：order history is needed to prove the final lifecycle result。可执行动作是：query history after lost responses or prevention events。仍然未知的是：whether archived order retention is enough for audit needs。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
5. Changelog drift
这里的含义是：API fields can change across V5 updates。可执行动作是：refresh wrappers against current docs before production changes。仍然未知的是：whether a client library hides new fields。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
6. Operational log
这里的含义是：useful evidence should not expose keys, balances or full strategy logic。可执行动作是：redact payloads and preserve only source, endpoint, id and state。仍然未知的是：whether debug logs leak account structure。
操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。
仍需明确的未知项
- whether the trading UI uses a different default
- whether a retry created a replacement order
- whether a cancel raced with execution
- whether archived order retention is enough for audit needs
- whether a client library hides new fields
- whether debug logs leak account structure
实用结论
Bybit Self Match Prevention 应被视为订单生命周期控制，而不是证明策略安全的标签。Bybit V5 文档通过下单时选择的执行方式解释 SMP，create-order 文档也把 smpType 暴露为请求参数。撤单和订单历史端点仍是独立证据表面，因此准备度测试必须证明请求了什么、哪个订单被触及、什么被撤销，以及最终订单历史如何记录。实用结果是一份不含秘密的运行手册，用于 mode selection、重放处理、撤单证据和事件后对账。 本文停在证据边界内，帮助读者决定下一步核验什么，而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。