The version of this that most people build looks fine on paper and loses money in practice. You check three timeframes, you want them all bullish, you enter when the fast one flips. Reasonable. Then you run it and half your entries land near the top of the move, because by the time all three agree the trade is mostly over. The idea is right. The wiring is where it goes wrong.
The fix I keep coming back to is splitting the entry into two jobs that do not overlap. One layer decides whether you are allowed to trade at all. The other decides when. Once you stop asking a single timeframe to do both, most of the lag problem sorts itself out.
The gate and the trigger are different questions
The gate is a slow question. On your higher timeframe, is momentum pointed the way you want to trade? That is it. You are not timing anything here. You are asking permission. The higher timeframe is a filter that is either open or closed, and it changes slowly enough that you can check it, cache the answer, and move on.
The trigger is a fast question. On your lower timeframe, has a fresh push started right now? This layer is allowed to be twitchy because the gate is protecting it. A trigger that would be far too noisy on its own becomes usable once it can only fire in the direction the higher timeframe already blessed.
The reason to keep these separate in code, not just in your head, is that you will want to tune them independently. The gate wants to be slow and stable so it does not flicker on and off. The trigger wants to be quick and a little sensitive so you actually catch the entry instead of chasing it. If both live inside one indicator you cannot move one without dragging the other.
Coding the gate-plus-trigger logic
The structure is boring, which is a good sign. You compute a gate on the higher timeframe, resample or align it down to your trading timeframe, and then only evaluate the trigger on bars where the gate is open. In rough pseudocode:
- Compute higher-timeframe momentum. Something slow. A longer moving-average slope, or a longer-lookback rate of change. The output you care about is a boolean: gate_long is true when that momentum is above your threshold, gate_short when below.
- Forward-fill that boolean down to the lower timeframe so every fast bar knows the current state of the slow gate. This is the step people get wrong. If you compare a 4-hour value against a 15-minute bar without aligning them, you leak future information and your backtest lies to you.
- Compute the fast trigger on the lower timeframe. A short-lookback momentum cross, a break of the prior few bars, whatever your fast signal is.
- Enter long only when gate_long is true and the trigger fires long on that bar. Same logic mirrored for shorts. If the gate is closed, the trigger is ignored entirely.
The one thing worth being paranoid about is timestamp alignment. When you forward-fill the higher-timeframe gate, make sure each fast bar sees the last closed higher-timeframe value, not the one that is still forming. A 4-hour bar is not final until it closes, and using its in-progress value is the most common way people accidentally build a system that only works in hindsight. If you are backtesting this on Blockcircle or anywhere else, that single check is the difference between a curve you can trust and one you cannot.
Setting the thresholds for each layer
Each layer gets its own threshold, and they are not the same kind of number. The gate threshold controls how selective you are about the regime. Set it near zero, so the gate opens the moment higher-timeframe momentum is barely positive, and you will be in a lot of chop. Push it further from zero, demanding clearly positive momentum before the gate opens, and you trade less but the trades sit inside cleaner trends. I tend to start the gate a little stricter than feels comfortable and loosen it only if I am getting too few trades to evaluate.
The trigger threshold controls how eager you are to pull the trigger once you are allowed to. Here I go the other way. Because the gate is doing the heavy filtering, the trigger can be loose. A tight trigger threshold on top of a strict gate is how you end up with a system that is technically correct and almost never trades. Loose trigger, strict gate, is usually the more useful pairing. You want the gate to say no often and the trigger to say yes readily once the gate says yes.
A rule of thumb that has held up for me: tune the gate first, in isolation, until the regimes it selects look like the ones you actually want to trade. Only then add the trigger and tune it for timing. Tuning both at once is how you convince yourself a curve is good when really you just found a lucky pair of numbers.
The lag trap, and how many timeframes is too many
Here is the failure mode that started this whole thing. Every timeframe you add to the agreement requirement pushes your entry later. Two agreeing is a real filter. Three can still be fine. By the time you are demanding four or five timeframes all point the same way, you have built a machine that only gets confirmation after the easy part of the move is gone. The trade you enter is the one everyone else already entered, at a worse price, with less room left.
So the requirement is not to stack timeframes. It is to pick the fewest that carry information. In practice that is usually one gate and one trigger, maybe a second gate one step up if you genuinely trade across regimes. The moment you find yourself adding a fourth timeframe because the third did not filter enough, the problem is almost never that you need more agreement. It is that your gate threshold is too loose or your trigger is firing on noise.
A few checks I run before trusting one of these:
- Look at where entries land inside the move. If most of them cluster near the end of the run rather than the start, you have too much agreement required or too much lag in the gate. Widen the gap between the timeframes or drop one.
- Count how often the gate is open versus how often you actually enter. If the gate is open most of the time, it is not really gating anything and you should tighten its threshold.
- Turn the trigger off and enter on gate alone, then turn the gate off and enter on trigger alone. The combined version should beat both. If it does not, the two layers are fighting, not cooperating.
None of this is exotic. The whole trick is refusing to let one timeframe answer two questions, and being honest about how much later every added confirmation makes you. Get the gate slow and strict, the trigger fast and loose, and keep the count of agreeing timeframes as low as the data lets you. That is most of the edge, and it is mostly discipline rather than cleverness.