Stop-loss hunting: how exchanges see your stops

What is stop-loss hunting?

Stop-loss hunting is when someone deliberately pushes price into a zone where a large number of stops are clustered, triggers those orders, and lets the price reverse. Traders get stopped out at the worst possible moment. The entity that initiated the move profits from the forced liquidation flow.

The mechanics are simple. When you place a stop on an exchange, you create a conditional instruction: "if price reaches X, sell at market." If enough traders set stops at similar levels – and they do, because everyone reads the same charts and sees the same support lines – those stops form a cluster. A large player who can see where the clusters sit has a predictable target. Push price 0.5% below obvious support, trigger the cascade, absorb the liquidity at a discount, let the price recover.

This is not a conspiracy theory. It is documented in both traditional and crypto markets. The difference in crypto is that the barriers to executing stop hunts are lower and protections for traders are nearly nonexistent.

How exchanges expose your stop orders

When you place a stop on a crypto exchange, one of two things happens. Either it sits in the public order book as a conditional order visible to anyone with Level 2 data, or it sits in a conditional order queue inside the matching engine. Either way, the exchange operator knows exactly where your stop is.

Market makers with API access see aggregated order book depth at every price level. Even on exchanges that don't directly expose conditional queues, the clustering of stops at obvious technical levels is trivially predictable. A market maker looking at BTC/USDT sees a thin gap between current price and the nearest support, followed by a dense cluster of sell orders just below it. The trade writes itself: sell enough to push through support, trigger the cascade, buy back cheaper.

You can see this on any chart. Sudden wicks that punch through support by a few tenths of a percent, trigger a burst of volume, then snap back within minutes. On low-liquidity pairs, these wicks appear with remarkable regularity at the round numbers, the prior swing lows, the moving average confluences that every retail trader watches.

A concrete example. BTC at $64,200 with clear support at $63,800. Thousands of stops between $63,700 and $63,800. A large sell order pushes price to $63,650. Every stop in that range triggers as a market sell, driving price briefly to $63,500. The selling pressure exhausts itself because it was artificial – once the stops have fired, there are no more sellers. Price recovers to $64,000 within 15 minutes. Every trader who had a stop at $63,750 sold the bottom. The entity that started the move bought at $63,500 and is already in profit.

The scale of the problem

Crypto markets operate in a regulatory environment that is fundamentally different from equities. No SEC-equivalent watches for manipulative practices on most exchanges. No surveillance system flags suspicious order book activity. No requirement for exchanges to separate their proprietary trading from their order matching.

In U.S. equities, stop hunting by a broker-dealer using client order information would violate SEC Rule 10b-5, FINRA rules on front-running, and potentially constitute market manipulation under the Securities Exchange Act. In crypto, the same behavior is, in most jurisdictions, just how the market works.

The 24/7 nature of crypto makes it worse. Traditional markets have defined hours and the major sessions overlap in ways that maintain reasonable liquidity. Crypto never closes. During low-liquidity periods – weekends, holidays, the gap between Asian and European sessions – the capital needed to move price through a stop cluster drops dramatically. A stop hunt requiring $50 million of sell pressure during peak hours might need only $5 million at 3 AM on a Sunday.

Futures are particularly vulnerable. Leveraged positions have liquidation prices on top of stop-losses, and the cascade effect amplifies: a stop triggers a market sell, which pushes price lower, which triggers another trader's liquidation, which adds more sell pressure. Exchange insurance funds and auto-deleveraging mechanisms exist because these cascades happen regularly.

Research from blockchain analytics firms has repeatedly shown that large liquidation events on major exchanges are preceded by unusual order flow – specifically, large market sells hitting the book within seconds of each other, consistent with coordinated stop hunting rather than organic price discovery.

Client-side stops don't help either

Some traders try to solve the hunting problem by not placing stops on the exchange at all. They use browser-based apps that monitor price and send a close order when the stop level is hit. The fatal flaw: it only works while the app is running.

A client-side stop lives in your browser tab, desktop app, or phone. Close the laptop, lose WiFi, let the battery die, navigate to another tab that throttles the WebSocket connection – and your stop no longer exists. Open position, no protection.

This is the worst of both worlds. You gave up the reliability of an exchange-side stop (which at least fires when your computer is off) without gaining any protection against stop hunting. And the moments when hunts are most likely – weekends, overnight, low-liquidity windows – are exactly when you are least likely to have the trading app open.

Some desktop apps run as persistent background processes, but they still depend on your machine staying on, staying connected, not crashing. A power outage, a forced system update, or a network interruption at the wrong moment leaves you exposed. For prop firms, relying on each trader's laptop to enforce risk controls is not viable.

Hidden stops: the server-side solution

The solution is to move the stop to a server you control – one that is not the exchange. Your stop exists only on your risk server. The exchange has no knowledge of it. No conditional order in the book, no entry in the stop queue, no data point for market makers to aggregate. As far as the exchange is concerned, you have an open position with no stop.

When price hits your stop level, the server sends a market order to close the position. The exchange sees a regular market sell – identical to any other. It has no way to know this was triggered by a stop, because the stop never existed on the exchange. No footprint to hunt.

This is what "hidden stop-loss" means in practice. Not a special order type. Not an "iceberg" order that hides size but still sits in the book. It is the complete absence of stop information on the exchange, combined with server-side logic that monitors price and executes when the condition is met.

The server needs a persistent WebSocket connection to the exchange's market data feed, receiving every trade tick. It runs 24/7, independent of any trader's machine. It sends orders with low latency. And it processes price data in real time, not on a polling interval.

How it works in practice

The execution flow has four steps.

You set a stop at price X. This gets stored in the risk server's database. No order is sent to the exchange. The order book doesn't change.

The server monitors every trade tick from the exchange via WebSocket. Each tick arrives with a price and timestamp. The server compares it against all active stop levels for all open positions.

When the last trade price crosses your stop level – say, drops to or below $63,750 for a long position – the server triggers. This check runs on every single tick. Not on an interval, not on candle close.

The server sends a market order to close the position. The exchange receives a standard market sell, fills it against the book. There is no way to distinguish this from a discretionary sell placed by a human.

The entire process, from price crossing the stop level to the market order hitting the exchange, takes under one second. For a server in the same region as the exchange: 10-50 milliseconds. Different region: 100-300 milliseconds. Functionally equivalent to an exchange-native stop.

The difference is what happened before the trigger. An exchange stop spent hours or days in the order book, advertising the exit level. A server-side hidden stop spent that same time as a row in a private database, invisible to everyone.

Trailing stops and break-even: also hidden

The same mechanism handles more complex stop behavior. Trailing stops, break-even moves, multi-level take-profit plans – all run as server-side logic that adjusts internal stop levels and sends market orders only when a level is hit.

A trailing stop with a 1% trail: the position moves in your favor, the server updates the stop level in its database. No order modification goes to the exchange, because no order exists there. Price moves from $64,000 to $65,000, the stop silently moves from $63,360 to $64,350. The exchange sees nothing. If price reverses to $64,350, the server sends a market sell. One market order, no history of trailing modifications leading up to it.

Break-even works the same way. Price reaches a profit target, the server moves the stop to entry (or entry plus fees). Internal database update, zero exchange footprint. Multi-level take-profits – close 25% at target 1, 25% at target 2, trail the rest – execute as individual market orders at the moment each target is reached.

To anyone analyzing exchange trade history, the result looks like a series of unrelated market orders placed at different times. No visible pattern linking them to a stop-loss strategy. This is useful beyond stop hunting prevention – it also prevents algorithms from reverse-engineering your risk management approach from your order history.

What about slippage?

Server-side stops use market orders, and market orders are subject to slippage. When the server sends a market sell, it fills against the current bid side. If the book is thin, you get filled slightly worse than the intended stop level.

But context matters. Exchange-native stops also convert to market orders when triggered. The fill mechanics are identical. The only additional slippage from a server-side stop comes from the sub-second latency of sending the order.

On BTC/USDT with $10 billion in daily volume, the order book within 0.1% of current price typically has enough liquidity to fill positions up to several hundred thousand dollars without meaningful slippage. On lower-liquidity altcoins, slippage is a real concern – but it is the same concern whether your stop is on the exchange or on your server.

The better question: what costs more, an occasional 0.01-0.05% of extra slippage, or getting stopped out by a hunt that would not have reached your level if your stop had been invisible? A hunt that moves price 0.5% past your stop and reverses costs you the entire position, not a few basis points. If the hidden stop prevents even one hunt per month, the tradeoff is obvious.

One scenario where exchange stops have an edge: stop-limit orders. Some exchanges let you place a limit order instead of a market order when the trigger is hit. This eliminates slippage but introduces the risk of the limit not filling during a fast move. Server-side execution uses market orders – guaranteed fill, not guaranteed price. For most traders, the guaranteed fill is the right choice. An unfilled limit stop during a crash is worse than a fill with slippage.