Updated
Killzone Sweep [UgurTash]
Killzone Sweep: Sessions, Liquidity Raids and Depth Statistics [UgurTash]
## What this is
Three things in one script, and they are built to be read in this order.
A **session framework**: four blocks (Asia, London, New York AM, New York PM), each with an inner kill zone, each read on the clock of the market that produces it.
A **liquidity sweep engine** that detects every raid on a tracked level and measures it, rather than assuming it reverses.
A **statistics panel** that reports what those raids actually did on your symbol, bucketed by depth, net of the round trip cost you set.
The point of the third part is to tell you whether the first two are worth trading on this instrument. On many symbols the answer will be no, and that is a result, not a failure of the tool.
## The premise, stated plainly
This is not "a level was swept, therefore price reverses". Order flow research (Osler, Journal of Finance) separates two kinds of resting order: triggering stop orders propagates a move, triggering take profit orders reverses it. Both leave the same footprint on a chart. A mechanical sweep then reverse rule, measured honestly, comes out negative.
What distinguishes the two outcomes empirically is **depth**, and every sweep here is measured on two independent axes:
**Extension**, from the reference open (session open by default) to the swept extreme, in ATR. How far price had already travelled before it took the level.
**Penetration**, from the swept level to the swept extreme, in ATR. How hard it went through once it got there.
A level tagged by half an ATR of extension and two ticks of penetration is not the same event as one reached after three ATR and pushed half an ATR beyond. The panel keeps them apart and reports each bucket separately.
## Why this is not another kill zone script
Three parts of it are not cosmetic variations on the genre.
**Each session is read on its own market clock.** Asia on Tokyo time, London on London time, both New York blocks on New York time. Tokyo does not observe daylight saving, London and New York do, and they change on different dates. A script that writes all four windows in one timezone is correct for roughly half the year and an hour out for the rest. This removes that instead of documenting it.
**A sweep is defined over a reclaim window in minutes, not as a single bar wick.** A bar based definition is a property of the bar, not of the market: on 15m one wick qualifies, while on 5m the same excursion is three bars and the middle one closes beyond the level, which retires it as a break and produces no event at all. Same price action, opposite answer. The resolution horizon is in minutes for the same reason.
**The statistics are conditional and they charge a cost.** Not one headline win rate, but a per bucket breakdown with a t statistic beside every number and a round trip toll subtracted from every resolved trade.
## How a sweep becomes a measured outcome
The pool is built from the previous day's high and low and from completed session highs and lows, up to 24 live levels. A level that is closed through is retired, because a pool that has been broken is not liquidity any more.
A raid is registered when price breaches a level and closes back inside it within the **reclaim window** (30 minutes by default).
From there the **entry trigger** decides what counts as the trade:
**None** enters at the close of the reclaiming bar. Earliest entry, widest stop, and the rule the raw statistics are built on.
**Displacement close** (the default) waits for a close beyond the reclaim bar's opposite extreme. The cheap version of a structure shift, separating a raid the market rejected from one it merely paused at.
**Displacement plus FVG retracement** then waits for price to return into the imbalance that displacement left. Better price and a tighter stop, at the cost of every setup price never comes back to.
The stop sits beyond the extreme reached during the raid, plus 0.25 ATR. The target is either a fixed R (2.0 by default) or the nearest unraided pool on the opposite side, in which case each trade carries its own R and the panel reports the real number. An event still open after the horizon (1440 minutes) is booked as unresolved and excluded. A bar that touches both stop and target is booked as a loss, because a chart carries no intrabar ordering.
## The cost column is the part most panels leave out
Commission, spread and slippage are a fixed toll in percent of price, while risk is whatever the stop width happens to be. So the toll in R is cost divided by stop width, and it does not shrink when you tighten your stop. At the default 0.095 percent (one round trip at Binance USDT-M taker rates plus a tick), a 1 percent wide stop gives up about 0.10R and a 0.10 percent wide stop gives up about 0.95R.
This matters more than it sounds, because it reverses a conclusion. Any setting that produces tighter stops raises the win rate, since a fixed R target sits closer in absolute price. Gross, it looks better. Net, it can be the worst cell in the panel. Set this field to your own venue's number before reading anything else, and set it to 0 only if you want to see the flattering version.
## Reading the panel
Seven columns per row:
**n**, the sample. Under 30 it turns amber, because that row is a story rather than a measurement.
**win%**, the hit rate of the fixed R trade. Not the answer column: a win rate can always be bought by shrinking the target.
**R/trade**, net of cost. This is the answer column, and it is only coloured when the t beside it clears 2.
**t**, mean R divided by its own standard error. Below 2 the row cannot be told apart from a coin whatever R says, so both numbers go grey. Read it with the number of rows in mind: keeping the best of ten cells is not the same test as looking at one, and under pure noise the best of ten sits at t = 1.5 half the time. A lone row at 1.4 in a panel of ten is what noise looks like.
**unres%**, never reached stop or target inside the horizon. A large share means the stop and target do not fit this timeframe, and every other number in the row comes from the minority that resolved.
**rev%**, the published 50 percent retrace statistic. It is not a trade you could take and it flatters shallow events by construction. Kept so the familiar number is visible next to one that is harder to game.
Sections can be switched on independently: every sweep, extension buckets, penetration buckets, session, day of week, higher timeframe bias, premium and discount, SMT, and position within the session. Bucket edges are fitted automatically to the first 150 sweeps on the symbol (40th, 70th and 90th percentile), and nothing is counted until that calibration finishes so every counted event shares the same edges.
## Signals
A sweep draws a dot. A sweep that also passes every enabled gate draws an arrow and a setup zone. The dot is a measurement mark, the arrow says the setup exists, and only R/trade says whether it pays.
What gates an arrow: which extension and penetration buckets you allow, direction, day of week, inside an enabled session or anywhere, and optionally a cap on repeated same side raids within one session (a session that keeps raiding one side is trending through those levels, not reverting off them).
**One trade at a time** gates the arrows, the alerts and the drawn setups, but deliberately not the statistics. A panel that only counts the events that happened to arrive while the engine was idle is sampling its own history non randomly, and its buckets stop meaning anything.
**The adaptive gate** is the one filter here that is not fitted. It reads only events that had already resolved before the current bar, so on any given bar it knows exactly what a trader standing there would have known. A bucket is allowed to signal while its own walk forward record clears the bar you set (100 resolved events, t of 2 by default), and it switches off again when it stops clearing it. Early history produces nothing at all. Choosing a session or a depth bucket by reading the finished panel is the dishonest version of the same idea, because the panel already knows how every one of those trades ended.
## Filters, all off by default
Higher timeframe bias (EMA, HTF candle or midnight open), premium and discount halves, an SMT check against a correlated symbol, and position within the session.
They are off because a filter can only ever remove setups, so with all of them off the engine behaves as if they did not exist and each one can be switched on alone and read off the panel. Each also has its own panel section, counted whether the filter is on or off, which shows what it would have done before you commit to it.
That comparison is in sample on this symbol's history, so treat a clean split over 200 events as a candidate rather than a finding, and prefer filters that also have a reason behind them. Turn one on at a time. Switch on five and you will never know which one did it, and you will have fitted all five to the same history.
## Trade management, also off by default
Breakeven at a chosen R, a partial at the first target with the runner protected at entry and sent to a second target, and a percentage trailing stop that activates after a chosen R. With all three off, a trade ends at its target, its stop, or the horizon.
## On the chart
Session boxes are drawn out to the scheduled close the moment the session opens, so you can see how much of the block is left instead of watching it grow candle by candle. The part after the kill zone carries a fainter share of the same colour (two non overlapping areas, so it is genuinely lighter rather than a second layer stacked on top). Session high and low lines are dotted, run to the same scheduled close, and are drawn from the same extremes the engine turns into liquidity pools, so what you see is what it trades.
Also available: session mid line, range projections from a chosen session, FVG boxes with an automatic height threshold, previous day high, low and equilibrium, higher timeframe candles on the right with a close countdown, and the midnight open. The session layer hides itself above a timeframe you choose (60 minutes by default), since a three hour block means nothing on a daily chart.
## Alerts
Nine named conditions (buyside and sellside raided, long and short setup armed, long and short entry, partial banked, take profit, stop loss), and every stage also fires through `alert()`, so a single "Any alert() function call" alert covers the whole engine and its message carries the measured depths. Signals evaluate on closed bars, so set the trigger to Once Per Bar Close. Note that TradingView captures your settings when the alert is created and keeps using them, so configure the script first and create the alert afterwards.
## How to use it, in order
1. Set the round trip cost to your venue's number.
2. Leave every filter off and let the bucket calibration finish, then read the "every sweep" row. That is your baseline.
3. Read R/trade together with t. Ignore win% as a decision input.
4. Turn on one filter or one gate, compare its two rows, then decide.
5. If nothing clears t = 2 anywhere, the honest conclusion is that this symbol does not pay this idea. The panel is doing its job when it tells you that.
## Honest limitations
The panel is not a backtest. No order is placed. The round trip cost is charged, which was the largest omission, but queue position, partial fills, funding and the intrabar path are still missing and all of them run in the same optimistic direction.
An FVG limit is assumed to fill exactly at its level with no queue and no rejection, which flatters FVG mode specifically.
The SMT test compares N bar extremes, not matched swing pivots. It is a screen, and it needs the peer to share trading hours.
Bias reads the last closed higher timeframe bar, so it does not repaint, but it is one bar stale by construction.
Auto bucket edges are fitted to the first 150 sweeps of whatever history your chart loaded, so rows are only comparable within one calibration.
The reclaim window makes timeframes agree far better than a single bar definition, but not perfectly, since closes are quantised by bar size.
A bucket with n under roughly 30 is a story, not a measurement.
*Nothing here is financial advice.*
## What this is
Three things in one script, and they are built to be read in this order.
A **session framework**: four blocks (Asia, London, New York AM, New York PM), each with an inner kill zone, each read on the clock of the market that produces it.
A **liquidity sweep engine** that detects every raid on a tracked level and measures it, rather than assuming it reverses.
A **statistics panel** that reports what those raids actually did on your symbol, bucketed by depth, net of the round trip cost you set.
The point of the third part is to tell you whether the first two are worth trading on this instrument. On many symbols the answer will be no, and that is a result, not a failure of the tool.
## The premise, stated plainly
This is not "a level was swept, therefore price reverses". Order flow research (Osler, Journal of Finance) separates two kinds of resting order: triggering stop orders propagates a move, triggering take profit orders reverses it. Both leave the same footprint on a chart. A mechanical sweep then reverse rule, measured honestly, comes out negative.
What distinguishes the two outcomes empirically is **depth**, and every sweep here is measured on two independent axes:
**Extension**, from the reference open (session open by default) to the swept extreme, in ATR. How far price had already travelled before it took the level.
**Penetration**, from the swept level to the swept extreme, in ATR. How hard it went through once it got there.
A level tagged by half an ATR of extension and two ticks of penetration is not the same event as one reached after three ATR and pushed half an ATR beyond. The panel keeps them apart and reports each bucket separately.
## Why this is not another kill zone script
Three parts of it are not cosmetic variations on the genre.
**Each session is read on its own market clock.** Asia on Tokyo time, London on London time, both New York blocks on New York time. Tokyo does not observe daylight saving, London and New York do, and they change on different dates. A script that writes all four windows in one timezone is correct for roughly half the year and an hour out for the rest. This removes that instead of documenting it.
**A sweep is defined over a reclaim window in minutes, not as a single bar wick.** A bar based definition is a property of the bar, not of the market: on 15m one wick qualifies, while on 5m the same excursion is three bars and the middle one closes beyond the level, which retires it as a break and produces no event at all. Same price action, opposite answer. The resolution horizon is in minutes for the same reason.
**The statistics are conditional and they charge a cost.** Not one headline win rate, but a per bucket breakdown with a t statistic beside every number and a round trip toll subtracted from every resolved trade.
## How a sweep becomes a measured outcome
The pool is built from the previous day's high and low and from completed session highs and lows, up to 24 live levels. A level that is closed through is retired, because a pool that has been broken is not liquidity any more.
A raid is registered when price breaches a level and closes back inside it within the **reclaim window** (30 minutes by default).
From there the **entry trigger** decides what counts as the trade:
**None** enters at the close of the reclaiming bar. Earliest entry, widest stop, and the rule the raw statistics are built on.
**Displacement close** (the default) waits for a close beyond the reclaim bar's opposite extreme. The cheap version of a structure shift, separating a raid the market rejected from one it merely paused at.
**Displacement plus FVG retracement** then waits for price to return into the imbalance that displacement left. Better price and a tighter stop, at the cost of every setup price never comes back to.
The stop sits beyond the extreme reached during the raid, plus 0.25 ATR. The target is either a fixed R (2.0 by default) or the nearest unraided pool on the opposite side, in which case each trade carries its own R and the panel reports the real number. An event still open after the horizon (1440 minutes) is booked as unresolved and excluded. A bar that touches both stop and target is booked as a loss, because a chart carries no intrabar ordering.
## The cost column is the part most panels leave out
Commission, spread and slippage are a fixed toll in percent of price, while risk is whatever the stop width happens to be. So the toll in R is cost divided by stop width, and it does not shrink when you tighten your stop. At the default 0.095 percent (one round trip at Binance USDT-M taker rates plus a tick), a 1 percent wide stop gives up about 0.10R and a 0.10 percent wide stop gives up about 0.95R.
This matters more than it sounds, because it reverses a conclusion. Any setting that produces tighter stops raises the win rate, since a fixed R target sits closer in absolute price. Gross, it looks better. Net, it can be the worst cell in the panel. Set this field to your own venue's number before reading anything else, and set it to 0 only if you want to see the flattering version.
## Reading the panel
Seven columns per row:
**n**, the sample. Under 30 it turns amber, because that row is a story rather than a measurement.
**win%**, the hit rate of the fixed R trade. Not the answer column: a win rate can always be bought by shrinking the target.
**R/trade**, net of cost. This is the answer column, and it is only coloured when the t beside it clears 2.
**t**, mean R divided by its own standard error. Below 2 the row cannot be told apart from a coin whatever R says, so both numbers go grey. Read it with the number of rows in mind: keeping the best of ten cells is not the same test as looking at one, and under pure noise the best of ten sits at t = 1.5 half the time. A lone row at 1.4 in a panel of ten is what noise looks like.
**unres%**, never reached stop or target inside the horizon. A large share means the stop and target do not fit this timeframe, and every other number in the row comes from the minority that resolved.
**rev%**, the published 50 percent retrace statistic. It is not a trade you could take and it flatters shallow events by construction. Kept so the familiar number is visible next to one that is harder to game.
Sections can be switched on independently: every sweep, extension buckets, penetration buckets, session, day of week, higher timeframe bias, premium and discount, SMT, and position within the session. Bucket edges are fitted automatically to the first 150 sweeps on the symbol (40th, 70th and 90th percentile), and nothing is counted until that calibration finishes so every counted event shares the same edges.
## Signals
A sweep draws a dot. A sweep that also passes every enabled gate draws an arrow and a setup zone. The dot is a measurement mark, the arrow says the setup exists, and only R/trade says whether it pays.
What gates an arrow: which extension and penetration buckets you allow, direction, day of week, inside an enabled session or anywhere, and optionally a cap on repeated same side raids within one session (a session that keeps raiding one side is trending through those levels, not reverting off them).
**One trade at a time** gates the arrows, the alerts and the drawn setups, but deliberately not the statistics. A panel that only counts the events that happened to arrive while the engine was idle is sampling its own history non randomly, and its buckets stop meaning anything.
**The adaptive gate** is the one filter here that is not fitted. It reads only events that had already resolved before the current bar, so on any given bar it knows exactly what a trader standing there would have known. A bucket is allowed to signal while its own walk forward record clears the bar you set (100 resolved events, t of 2 by default), and it switches off again when it stops clearing it. Early history produces nothing at all. Choosing a session or a depth bucket by reading the finished panel is the dishonest version of the same idea, because the panel already knows how every one of those trades ended.
## Filters, all off by default
Higher timeframe bias (EMA, HTF candle or midnight open), premium and discount halves, an SMT check against a correlated symbol, and position within the session.
They are off because a filter can only ever remove setups, so with all of them off the engine behaves as if they did not exist and each one can be switched on alone and read off the panel. Each also has its own panel section, counted whether the filter is on or off, which shows what it would have done before you commit to it.
That comparison is in sample on this symbol's history, so treat a clean split over 200 events as a candidate rather than a finding, and prefer filters that also have a reason behind them. Turn one on at a time. Switch on five and you will never know which one did it, and you will have fitted all five to the same history.
## Trade management, also off by default
Breakeven at a chosen R, a partial at the first target with the runner protected at entry and sent to a second target, and a percentage trailing stop that activates after a chosen R. With all three off, a trade ends at its target, its stop, or the horizon.
## On the chart
Session boxes are drawn out to the scheduled close the moment the session opens, so you can see how much of the block is left instead of watching it grow candle by candle. The part after the kill zone carries a fainter share of the same colour (two non overlapping areas, so it is genuinely lighter rather than a second layer stacked on top). Session high and low lines are dotted, run to the same scheduled close, and are drawn from the same extremes the engine turns into liquidity pools, so what you see is what it trades.
Also available: session mid line, range projections from a chosen session, FVG boxes with an automatic height threshold, previous day high, low and equilibrium, higher timeframe candles on the right with a close countdown, and the midnight open. The session layer hides itself above a timeframe you choose (60 minutes by default), since a three hour block means nothing on a daily chart.
## Alerts
Nine named conditions (buyside and sellside raided, long and short setup armed, long and short entry, partial banked, take profit, stop loss), and every stage also fires through `alert()`, so a single "Any alert() function call" alert covers the whole engine and its message carries the measured depths. Signals evaluate on closed bars, so set the trigger to Once Per Bar Close. Note that TradingView captures your settings when the alert is created and keeps using them, so configure the script first and create the alert afterwards.
## How to use it, in order
1. Set the round trip cost to your venue's number.
2. Leave every filter off and let the bucket calibration finish, then read the "every sweep" row. That is your baseline.
3. Read R/trade together with t. Ignore win% as a decision input.
4. Turn on one filter or one gate, compare its two rows, then decide.
5. If nothing clears t = 2 anywhere, the honest conclusion is that this symbol does not pay this idea. The panel is doing its job when it tells you that.
## Honest limitations
The panel is not a backtest. No order is placed. The round trip cost is charged, which was the largest omission, but queue position, partial fills, funding and the intrabar path are still missing and all of them run in the same optimistic direction.
An FVG limit is assumed to fill exactly at its level with no queue and no rejection, which flatters FVG mode specifically.
The SMT test compares N bar extremes, not matched swing pivots. It is a screen, and it needs the peer to share trading hours.
Bias reads the last closed higher timeframe bar, so it does not repaint, but it is one bar stale by construction.
Auto bucket edges are fitted to the first 150 sweeps of whatever history your chart loaded, so rows are only comparable within one calibration.
The reclaim window makes timeframes agree far better than a single bar definition, but not perfectly, since closes are quantised by bar size.
A bucket with n under roughly 30 is a story, not a measurement.
*Nothing here is financial advice.*
Release Notes
Update: Independent Session Visuals and Signal Timing- Session and kill zone visibility controls are now independent of signal calculations. Hiding these visuals no longer removes signals or disables the underlying session references and liquidity tracking.
- Added "Signal timing" under "5 - Signals":
- Sessions only: Allows signal setups only within the configured session windows. This is the default.
- Always: Also allows signal setups outside the configured session windows.
The sweep detection, entry confirmation, filters, stop-loss, and target rules remain unchanged. All existing signal conditions must still be met in either timing mode.
Release Notes
Update: Take Profit SettingsAll take-profit controls are now grouped under "4b - Take Profit":
- TP mode: Fixed R or Opposite liquidity.
- Fixed RR / fallback RR: The fixed target, also used when no qualifying liquidity level is available.
- Liquidity: minimum RR: The minimum reward-to-risk ratio required for a liquidity target. This is a threshold, not a fixed target.
- Partial Take Profit, Partial Size, and Second Target.
Added clearer tooltips and examples to explain each setting.
Default values, target calculations, and signal logic remain unchanged.
For more you can follow me on X. @UgurTash
Disclaimer
The information and publications are not meant to be, and do not constitute, financial, investment, trading, or other types of advice or recommendations supplied or endorsed by TradingView. Read more in the Terms of Use.
For more you can follow me on X. @UgurTash
Disclaimer
The information and publications are not meant to be, and do not constitute, financial, investment, trading, or other types of advice or recommendations supplied or endorsed by TradingView. Read more in the Terms of Use.