Riset terverifikasi sumber: Bybit SELF Match Prevention
Isi artikel ditampilkan dalam bahasa Inggris asli yang telah diverifikasi. Terjemahan ditambahkan setelah tinjauan sumber.
Verified Fact Boundary
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.
Tampilkan lebih sedikit
Decision Matrix
Tabel artikel: gulir secara horizontal atau fokuskan area tabel dan gunakan tombol panah.
| 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 |
Source Map
- 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)
Control Notes
1. Mode selection
Mode selection is the point where public documentation must become an operating rule. In this package, it means smpType is chosen at order entry rather than inferred later. The practical action is to pin the mode in the strategy config and evidence log. The unresolved edge is whether the trading UI uses a different default, 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. Accepted request
Accepted request is the point where public documentation must become an operating rule. In this package, it means an order request can be rejected before SMP ever matters. The practical action is to record accepted order id or rejection class. The unresolved edge is whether a retry created a replacement order, 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. Cancel path
Cancel path is the point where public documentation must become an operating rule. In this package, it means cancel endpoints are evidence surfaces separate from prevention settings. The practical action is to keep cancel request and final state together. The unresolved edge is whether a cancel raced with execution, 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. History review
History review is the point where public documentation must become an operating rule. In this package, it means order history is needed to prove the final lifecycle result. The practical action is to query history after lost responses or prevention events. The unresolved edge is whether archived order retention is enough for audit needs, 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. Changelog drift
Changelog drift is the point where public documentation must become an operating rule. In this package, it means API fields can change across V5 updates. The practical action is to refresh wrappers against current docs before production changes. The unresolved edge is whether a client library hides new fields, 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.
6. Operational log
Operational log is the point where public documentation must become an operating rule. In this package, it means useful evidence should not expose keys, balances or full strategy logic. The practical action is to redact payloads and preserve only source, endpoint, id and state. The unresolved edge is whether debug logs leak account structure, 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
- 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
Practical Takeaway
Bybit Self Match Prevention should be treated as an order-lifecycle control, not a label that proves a strategy is safe. Bybit V5 documentation explains SMP through execution choices selected when placing an order, and the create-order documentation exposes smpType in the request surface. Cancellation and order-history endpoints remain separate evidence surfaces, so a readiness test must prove what was requested, which order was touched, what was canceled, and what the final order history says. The practical result is a non-secret runbook for mode selection, replay handling, cancel evidence and post-event reconciliation. 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.