Nghiên cứu đã kiểm chứng nguồn: Binance VS Bybit SELF

Decision Matrix

Source Map

• 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)

Control Notes

1. Prevention mode

Prevention mode is the point where public documentation must become an operating rule. In this package, it means Binance uses selfTradePreventionMode while Bybit uses smpType language. The practical action is to record the configured mode before placing orders. The unresolved edge is whether a UI default differs from the API payload, 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. Account scope

Account scope is the point where public documentation must become an operating rule. In this package, it means Binance references user and tradeGroupId while Bybit SMP behavior depends on account configuration. The practical action is to map the exact account, sub-account and group boundary. The unresolved edge is whether linked accounts share a prevention group, 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. Order identity

Order identity is the point where public documentation must become an operating rule. In this package, it means prevented-match evidence is only useful when order ids and client ids are preserved. The practical action is to store non-secret order identifiers before retry or cancel. The unresolved edge is whether wrapper libraries replace client identifiers, 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. Cancel consequence

Cancel consequence is the point where public documentation must become an operating rule. In this package, it means cancel taker, cancel maker or cancel both have different inventory effects. The practical action is to simulate each mode with harmless fixtures before live use. The unresolved edge is whether partial fills change the risk meaning, 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. Evidence after rejection

Evidence after rejection is the point where public documentation must become an operating rule. In this package, it means a prevention event is not the same as no exposure. The practical action is to query final order state and trade history after every prevention event. The unresolved edge is whether delayed fills arrive after the local bot has moved on, 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. Secret hygiene

Secret hygiene is the point where public documentation must become an operating rule. In this package, it means STP debugging can expose account and order metadata even without API secrets. The practical action is to log source URL, endpoint, mode, order state and timestamp only. The unresolved edge is whether screenshots reveal balances or strategy intent, 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 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

Practical Takeaway

Binance and Bybit both document self-trade prevention controls, but the operating evidence is not identical. Binance Spot documentation frames STP through selfTradePreventionMode, tradeGroupId, prevented-match fields and account prevented-match queries, while its REST API documentation keeps signed trading requests inside API-key permission and timestamp controls. Bybit V5 documentation describes Self Match Prevention through smpType choices such as cancel taker, cancel maker and cancel both, then ties the setting to order creation and order-history evidence. The useful decision is to prove the prevention mode, account or group scope, order identifier, prevented quantity, cancel consequence and final order state before a bot treats either venue as protected from self-matching. 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.