Recherche vérifiée par sources: Bybit SMP Trade Group
Le corps de l'article est affiché dans sa version anglaise vérifiée. La traduction sera ajoutée après revue des sources.
Verified Fact Boundary
1. Bybit self-match-prevention documentation describes execution policies including cancel maker, cancel taker and cancel both. 2. Bybit SMP documentation describes SMP Trade Group behavior and UID-level relationships. 3. Bybit changelog records updates to SMP behavior for compliant sites and derivative or spot contexts. 4. Bybit user-setting configuration documentation exposes smpType as a trade-behaviour field. 5. Bybit place-order documentation includes smpType and client order identity fields in the order-control surface. 6. The public documentation does not prove a private account's institution status, group membership, live order cleanup, future site behavior or final execution outcome.
Réduire
Decision Matrix
Tableau de l’article : faites défiler horizontalement ou placez le focus sur le tableau et utilisez les flèches.
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| SMP policy | self-match prevention is an execution policy with several possible outcomes, not one universal cancel rule | write the intended maker/taker/cancel-both policy before order placement | whether the live match path will encounter the intended counterparty condition |
| Trade-group boundary | SMP group membership can change the matching relationship across UIDs and subaccounts | record UID, group assumption and standing-order cleanup before changing groups | private institutional eligibility and support-managed group changes |
| Site-specific behavior | Bybit documentation records compliant-site behavior that can differ from global assumptions | record account site and product type before applying a default smpType | future regional rollout and product availability |
| Order identity | smpType interacts with ordinary order controls such as orderLinkId and order-state reporting | store non-secret client order id, request id and final order-state evidence separately | race conditions, rejected orders and later order-book state |
| Stop condition | SMP cannot be treated as reliable if group, site, product and standing-order state are unknown | pause automation until account site, UID scope, default policy and cleanup rule are written | private account status, support outcome and future API revisions |
Source Map
- Bybit API Documentation: Self Match Prevention (bybit-smp)
- Bybit API Documentation: V5 Changelog (bybit-v5-changelog)
- Bybit API Documentation: Get Trade Behaviour Config (bybit-user-setting-config)
- Bybit API Documentation: Place Order (bybit-place-order)
Control Notes
1. SMP policy
SMP policy is the point where public documentation must become an operating rule. In this package, it means self-match prevention is an execution policy with several possible outcomes, not one universal cancel rule. The practical action is to write the intended maker/taker/cancel-both policy before order placement. The unresolved edge is whether the live match path will encounter the intended counterparty condition, 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. Trade-group boundary
Trade-group boundary is the point where public documentation must become an operating rule. In this package, it means SMP group membership can change the matching relationship across UIDs and subaccounts. The practical action is to record UID, group assumption and standing-order cleanup before changing groups. The unresolved edge is private institutional eligibility and support-managed group changes, 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. Site-specific behavior
Site-specific behavior is the point where public documentation must become an operating rule. In this package, it means Bybit documentation records compliant-site behavior that can differ from global assumptions. The practical action is to record account site and product type before applying a default smpType. The unresolved edge is future regional rollout and product availability, 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. Order identity
Order identity is the point where public documentation must become an operating rule. In this package, it means smpType interacts with ordinary order controls such as orderLinkId and order-state reporting. The practical action is to store non-secret client order id, request id and final order-state evidence separately. The unresolved edge is race conditions, rejected orders and later order-book state, 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. Stop condition
Stop condition is the point where public documentation must become an operating rule. In this package, it means SMP cannot be treated as reliable if group, site, product and standing-order state are unknown. The practical action is to pause automation until account site, UID scope, default policy and cleanup rule are written. The unresolved edge is private account status, support outcome and future API revisions, 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 live match path will encounter the intended counterparty condition
- private institutional eligibility and support-managed group changes
- future regional rollout and product availability
- race conditions, rejected orders and later order-book state
- private account status, support outcome and future API revisions
Practical Takeaway
Bybit's self-match-prevention documentation turns SMP into an account and order-control question rather than a generic safety badge. Bybit describes SMP execution policies, UID-level and trade-group behavior, user setting configuration and order parameters such as smpType. Its changelog also records site-specific SMP behavior updates. The practical checklist is to record account site, UID group, default smpType, orderLinkId policy, standing-order cleanup rule and WebSocket order-state evidence before relying on SMP to prevent self-trading. 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.