Why your stop-loss disappears — and what a system does about it

You set a stop-loss. You closed the tab. Two days later the position is still open, the market has moved against you, and the stop is not on the exchange. It was there when you placed it. Nobody cancelled it. It is simply gone.

This is one of the least-documented realities of automated crypto trading, and it has almost nothing to do with your strategy. It is an operational failure — the gap between instructing an exchange to hold a protective order and that order actually sitting on the book. This post is a walkthrough of how that gap opens, and what a system has to do to close it.

This is educational only. It describes how order plumbing behaves, not what you should trade or how much.

Your stop-loss does not live where you think it does

A stop-loss is not a setting. It is a separate order resting on the exchange, waiting for a trigger price. That distinction matters because it tells you who is actually responsible for it: the venue, not the platform that placed it, and certainly not the interface you typed it into.

Which means a stop-loss can be lost by anything that can lose an order. And exchanges lose orders.

Five ways an exchange loses your stop

1. The position changed underneath it. Most protective stops are placed as reduce-only orders sized to the position. Change the position — add to it, partially close it, let a take-profit leg fill — and the exchange may reject or drop the stop because it no longer squares with what you hold. The rejection comes back as an error meaning roughly “that order does not exist”, which is a confusing thing to receive about an order you placed successfully an hour ago.

2. A partial fill left a size mismatch. Your entry was a limit order for 1.0 BTC. Only 0.6 filled. If the stop was sized for 1.0, it is now either rejected outright or protecting a quantity you do not have. The position is real; the protection is fiction.

3. Sibling-order supersession. Stops and take-profits are often placed as a group. On some venues, modifying or filling one leg quietly invalidates another. Nothing errored. The book just has fewer orders on it than you think.

4. The request never landed. Every exchange rate-limits its API by request weight. Under a burst — several bots reacting to the same candle close — a placement call can be throttled, time out, or land while its acknowledgement is lost in transit. A lost acknowledgement is the dangerous case: the platform doesn’t know whether it succeeded, and optimism is the wrong default.

5. Maintenance and reconnects. Scheduled maintenance, contract settlement, and forced socket reconnects all end with an order book that may not look the way it did going in.

None of these are exotic. In aggregate they are routine — which is exactly why they need to be engineered for rather than hoped about.

”I placed a stop” is not the same as “a stop is on the book”

This is the load-bearing idea in the whole post.

Placing an order is a request. The acknowledgement you get back is a claim about the past — it says the request was accepted, not that the order is still live now. The only thing that constitutes evidence that your position is protected is a read-back: asking the exchange what orders it currently holds, and finding yours among them.

Most trading software never asks. It places the order, receives a success response, writes protected: true somewhere, and moves on. That flag then stays true forever, because nothing is watching to make it false again. The trader sees a green shield in the interface. The exchange has nothing.

A system that takes this seriously treats its own database as a claim and the exchange as the truth, and reconciles the two continuously.

Verify, recover, validate

Because the failure modes are independent, the checks have to be independent too. One check cannot cover all five cases above — each one opens the gap at a different moment. So Stralines runs three layers:

• Layer 1 — inline verification. Seconds after placement, read the order back from the exchange. This catches lost acknowledgements and outright rejections immediately, while the position is fresh and the market has not moved far.

• Layer 2 — a continuous recovery loop. Every two minutes, scan every open position and compare it against the orders the exchange actually holds. Anything missing gets re-placed. This is what catches the failures that happen later — the position change, the sibling supersession, the reconnect.

• Layer 3 — a validator. A stop can be placed successfully, verified successfully, and then purged by the exchange hours afterwards. The validator’s whole job is to notice that and flip the protection flag from true back to false — so the interface stops lying, and Layer 2 picks the work back up.

The reason this is three things and not one clever thing: independent failure modes need independent coverage. A single check placed at any one moment in the lifecycle is blind to everything that happens at the other moments.

Every bot on the platform inherits all three by default — the pre-built ones from the marketplace, the ones you compose yourself, and bring-your-own bots driven by external Pine Script or webhook signals. It is not a premium tier feature, because protection that some accounts get and others don’t isn’t protection.

What this does not fix

Recovery machinery closes an operational gap. It does not change market risk, and it would be dishonest to imply otherwise.

• A stop is not a promise of price. It triggers at a level and then executes at whatever the market offers. In a fast move, that can be meaningfully worse than the trigger.

• Gaps go through stops. If price jumps from above your stop to well below it without trading in between, there was no opportunity to fill at your level. No system on either side can conjure liquidity that wasn’t there.

• If the venue is fully down, nothing places anything. Your protection lives on the exchange, which is the good news when the platform goes offline — orders already resting keep working without us. It is the bad news when the exchange itself is the thing that’s unreachable.

• A recovered stop is a new order. It goes onto the book at the time of recovery, not retroactively. The window between the loss and the re-placement was genuinely unprotected. Shrinking that window from forever to about two minutes is the entire value on offer — not eliminating it.

How to check your own, right now

Independent of any platform, three habits are worth building:

1. Read the exchange, not the dashboard. Open the exchange’s own open-orders list. If your stop isn’t there, it doesn’t exist — no matter what any interface tells you.

2. Re-check after you touch a position. Manually adding, trimming, or partially closing is the single most common way to invalidate your own protection.

3. Re-check after a partial fill. If an entry filled partially, assume the protective orders are mis-sized until you have confirmed otherwise.

Further reading

• Position sizing and risk caps — why trade size, not stop placement, is the lever that actually bounds a drawdown.
• How automated trading bots work — the full signal-to-execution pipeline this failure mode sits inside.
• Security — the API key scope Stralines requests, and why it can place a stop but never move funds.

Closing

The interesting failures in automated trading are rarely the strategy. They are the small operational gaps between what a system believes and what a venue is actually holding — and a lost stop-loss is the most expensive of them, because you find out about it only when it was already needed.

Stralines is software for closing that particular gap: treat the exchange as the source of truth, read it back continuously, and never let a protection flag outlive the order it describes. That is the unglamorous end of trading engineering, and it is where the real damage gets prevented.

Nothing here is investment advice. Capital is at risk in any trading activity, and stop-loss orders reduce operational exposure — not market risk.