What Matters
A chart touching your stop level does not prove the order was eligible to trigger. The selected price reference may differ from the chart, an applicable protection rule may delay activation, or the order may have triggered without filling. Check those stages separately before concluding that the platform ignored your stop.
DN Evidence Block
Reviewed: 5 November 2026. Scope: Bybit’s documented TP/SL Price Protection and related execution rules. Original DN tool: Stop Trigger Evidence Worksheet, with an illustrative spread calculation and incident classification.
Key finding: Bybit documents a spread filter that can delay eligible last-price TP/SL triggers. Its scope excludes mark/index triggers and API-placed orders. [1]
Method: official documentation review and decimal arithmetic, not live order testing. The 2027 guide reflects evidence available on this review date. A calculation consistent with blocking is not proof of an actual matching-engine decision.
Start with the order, not the candle
The useful incident question is: which instruction, for which position, was active at the relevant time? Record the account, contract, position side, stop identifier, trigger direction and trigger reference. A chart screenshot without those details cannot establish what the order should have done.
A stop-loss has at least three checkpoints: the reference price meets its condition; the instruction becomes an executable order under the applicable rules; that order fills. A fourth check is the resulting position. These stages can disagree with the impression given by one chart candle.
Preserve the original configuration before changing it. A current toggle or edited stop does not establish the setting that existed during the incident. Record event times and time zones, and retain order-history and execution references.
What Bybit’s TP/SL Price Protection actually covers
The documented feature covers eligible perpetual and futures TP/SL. Activation requires both the price condition and an acceptable last-versus-mark spread; an earlier price touch does not remove those checks. [1]
That is a specific activation filter. It is not a guarantee of the eventual fill price or a general promise against losses. It should not be confused with a limit price, slippage tolerance, liquidation controls or protections on another venue.
Scope matters: record the applicable rule and creation route. A preference displayed in one workflow is not evidence that it governs every instruction.
DN Stop Trigger Evidence Worksheet
Copy this manual tool into an incident note. For each row, write the evidence, timestamp and result: verified, mismatch or unknown. It does not connect to an exchange or submit orders.
| Checkpoint | Evidence to collect | Question it resolves |
|---|---|---|
| Identity and scope | Account, symbol, product, order/position IDs, position side, app/web/API route | Are we investigating the intended instruction? |
| Trigger reference | Last, mark or index; trigger value and direction; active time | Which price needed to cross which level? |
| Protection eligibility | Feature scope, enabled state at the time, pair-specific threshold | Could this protection rule apply? |
| Price evidence | Time-aligned reference prices and source precision | Was the trigger met and was the spread within range? |
| Lifecycle | Untriggered, triggered, rejected, canceled or filled; event timestamps/reasons | Where did the workflow stop? |
| Execution | Unique fill IDs, quantities, prices and remaining order quantity | Did any exit actually execute? |
| Current exposure | Remaining position and other active closing orders | What is still exposed now? |
DN decision rule: classify the last verified stage, and leave the next stage unresolved until supported by records. Do not promote a plausible explanation into a confirmed root cause.
Worked example: trigger touched, spread outside the assumed threshold
Synthetic illustration, not a current BTCUSDT setting. Assume a long position has an eligible, enabled last-price stop at 98,000 USDT. Assume the relevant pair’s protection threshold is 1.00%. At one observation, last price is 97,800 and mark price is 99,000.
Using the documented spread formula:
Absolute spread (%) = |last − mark| ÷ mark × 100
The result is |97,800 − 99,000| ÷ 99,000 × 100 = 1.212121…%, or 1.21% rounded to two decimal places. This exceeds the assumed 1.00% threshold even though last price is below the stop. Under the assumed conditions, the observation is consistent with a protection block.
| Illustrative observation | Last / mark (USDT) | Spread | What can be inferred |
|---|---|---|---|
| A | 97,800 / 99,000 | 1.21% | Stop condition met; spread outside the assumed threshold |
| B | 98,200 / 98,600 | 0.41% | Spread inside range, but last price above the sell-stop level |
| C | 97,900 / 98,500 | 0.61% | Both assumed checks satisfied at this observation; execution still unproven |
Observation B explains why a delayed stop is not necessarily a queued promise to execute later. C is only a logical illustration of the two checks. A fill requires separate evidence. These snapshots do not reconstruct all intervening ticks or establish the provider’s actual evaluation order.
Never substitute a made-up threshold for the contract’s real rule. Use time-aligned data with sufficient precision. Candle extremes for last and mark may occur at different moments; combining them can invent a spread that never existed.
A different chart price is a separate explanation
Bybit’s execution FAQ distinguishes last, mark and index trigger references. It also explains that isolated-margin liquidation uses mark price, while cross and portfolio liquidation depends on account maintenance-margin conditions. A last-price chart is therefore not a complete liquidation record. [2]
Record the reference actually selected on the stop. A candle on another exchange, a spot chart for a perpetual contract or a chart with a different reference cannot establish that this instruction’s condition was met. Check the exact contract and event period.
This is not a recommendation to switch every stop to mark price. Changing the reference changes the strategy’s activation rule; it does not guarantee an exit before liquidation or a fill at the displayed mark.
Triggered but unfilled is not the same incident
Bybit’s TP/SL guide says a limit exit can be placed after its trigger condition is met, but execution still depends on matching at the limit price. [3] A stop can activate successfully while the resulting limit order remains unfilled. Look for its order record before investigating a trigger filter.
For example, a hypothetical sell stop-limit might activate at 98,000 with a 97,900 limit. If executable bids have moved below 97,900, it may not fill at that point. That is an execution-price constraint, not evidence of a blocked trigger.
The API documentation separately describes conditional-order margin checks, asynchronous order acceptance and market orders processed under IOC-style price protections. [4] “Market” should not be treated as a universal guarantee that the whole position closed. Confirm fills and the remaining position.
For incomplete executions, use DN’s canceled-order and partial-fill worksheet. For an exit rejected by position constraints, use the reduce-only audit. Those are different branches of the investigation.
What to send support when records disagree
Prepare a compact incident packet: product and symbol; redacted order and position identifiers; creation route; original trigger settings; relevant preference evidence; UTC event interval; order-status changes; and fill references. Describe the discrepancy in one sentence, such as “the selected reference crossed the level, but the record remained untriggered.”
Ask which condition prevented progress and which event record supports the answer. Keep screenshots as supporting evidence, not a replacement for the order’s lifecycle. Do not send API secrets, private keys or account passwords. An unexplained incident should remain unexplained until the evidence supports a narrower conclusion.
The trade-off to document before the next position
A filter intended to reject anomalous price movements can conflict with a strategy that prioritizes exiting during a dislocation. That is a design trade-off to document, not proof that either setting is always better.
Write down what the stop is expected to do, which reference activates it, which filters can delay it and how the team verifies remaining exposure. Do not disable safeguards impulsively during a live incident without understanding the consequences. For broader venue requirements, use DN Pathfinder.
Affiliate disclosure: linked DN tools and comparisons may contain affiliate links. No signup is needed for this worksheet. Bybit is used as a documented case study, not a venue recommendation.
Methodology and limitations
DN reviewed four official Bybit documents and checked the three synthetic spread calculations with decimal arithmetic. The worksheet is an original incident-record framework, not a venue ranking, backtest or live reliability benchmark. We did not validate a user’s setting, pair threshold, event sequence or trading outcome. The arithmetic cannot reconstruct a missing tick stream or prove liability. Version 1.0, 5 November 2026. Report corrections with a public source through DN’s contact page.
Frequently Asked Questions
Can price protection prevent a stop-loss from triggering?
For eligible orders under the documented Bybit feature, yes. Confirm the feature’s scope, enabled state and relevant threshold before attributing an incident to it.
Does a chart touching the stop prove it should trigger?
No. The selected reference, contract, timing and applicable activation rules must match the evidence.
Does a triggered stop guarantee a full exit?
No. Check the resulting order, execution records and remaining position.
Should I turn price protection off?
There is no universal answer. Review the strategy’s activation requirements, the feature’s trade-offs and the consequences for any live position.
Can this worksheet prove why my stop failed?
No. It organizes evidence and identifies missing records. Actual root-cause confirmation requires the relevant settings and event history.
Primary sources
- Bybit: TP/SL Price Protection, updated 13 September 2026.
- Bybit: Order Execution and Liquidation FAQ, updated 25 September 2026.
- Bybit: Take Profit and Stop Loss, updated 8 October 2026.
- Bybit API: Place Order.
All sources reviewed 5 November 2026. Operational education, not individualized investment advice. Products and rules vary by account and jurisdiction.
