Multi-Timeframe (MTF)

Multi-Timeframe (MTF) allows a single strategy to reference price data from multiple timeframes simultaneously. This is a core concept in technical analysis — higher timeframes define the trend and context, while lower timeframes define precise entry points.

Without MTF

Every node in your strategy uses the same symbol, bar type, and timeframe defined in the Data Source node. A 1h strategy means every indicator computes on 1h bars — the SMA, the RSI, the MACD, all of them. You get a single-dimensional view of the market.

With MTF

Individual nodes can override their data feed to use different timeframes. This lets you build strategies that mirror how professional traders think:

This mirrors how professional traders think: “The 4h trend is up, the 1h is oversold, I’ll enter on the 15m when price confirms.”

MTF is enabled at the Data Source node level. This is a global switch that unlocks MTF capabilities across the entire strategy.

Multi-Timeframe Toggle

Set the Multi-Timeframe toggle to ON (default: OFF) in the Data Source node’s inspector panel.

When enabled, several things happen:

• The Data Source node displays a Multi-Timeframe Enabled badge on its body, making it visually obvious that MTF is active.
• Compatible nodes (Indicator, Pattern, Condition, Filter, and all Market Structure types) show additional MTF override fields in their inspector panels — Symbol, Bar Type, and Timeframe selectors that default to “Same as Data Source.”
• The data source connection requirement is relaxed for MTF-capable nodes — they can fetch their own data at their individually configured timeframe rather than relying on the physical edge from the Data Source.

Trigger Bar

The has_trigger_bar toggle is related to MTF but distinct. It enables a lower timeframe specifically for execution timing:

• When enabled, a trigger_bar configuration section appears with its own Symbol, Bar Type, and Timeframe selectors.
• The strategy logic runs on the main timeframe (as defined in the Data Source), but entries and exits are executed on the trigger bar’s timeframe within each main bar’s period.
• Example: Strategy runs on 1h bars, trigger bar is 5m. If a 1h bar generates an entry signal at 10:00, the backtest examines 5m bars between 10:00–10:55 to find the optimal entry price within that hour. This dramatically improves entry precision without changing the strategy logic.

When MTF is enabled on the Data Source, compatible nodes show additional MTF override fields in their inspector panel. Each node can independently diverge from the main data source’s settings.

Nodes with MTF Override Support

• Indicator
• Pattern
• Condition (when left or right type is “price”)
• Filter (Trend, Volatility, Volume, Regime)
• Fibonacci
• Pivot Points
• Price Levels
• Volume Profile
• SMC

MTF Override Fields (per node)

How It Works

When a node has MTF overrides set (any field differs from the data source default), the node fetches its own data stream at the specified configuration, completely independent of the main data source. The node’s left handle no longer needs a data source connection — it reads directly from the exchange API at its configured resolution. Each MTF-configured node is a self-contained data consumer.

Independence

Each MTF-overridden node is independent. In a single strategy, you can have:

• One indicator at 4h (trend context)
• Another indicator at 1h (entry signal)
• A third indicator at 15m (fine-tuned confirmation)
• All processing their own independent data streams

There is no practical limit on the number of distinct timeframe overrides, though each unique (symbol, bar_type, timeframe) combination requires a separate data fetch (see performance considerations in Step 6).

Enabling MTF fundamentally changes how connections work on the canvas. The validation rules adapt to accommodate nodes that are self-sufficient for their data needs.

With MTF OFF (Default)

1. Data Source MUST physically connect to every indicator, pattern, and market-structure node’s left handle.
2. All nodes share the same data stream — one symbol, one bar type, one timeframe.
3. Validation Rule 8 enforces data source connectivity strictly.

With MTF ON

1. Data Source connection becomes OPTIONAL for MTF-capable nodes.
2. A node with MTF overrides set does NOT need a left handle connection — it is self-sufficient and fetches its own data.
3. A node without MTF overrides (inheriting all settings from the data source) still needs the data source connection — it has no independent data source configured.
4. Validation Rule 8 is relaxed — nodes with active MTF overrides skip the connectivity check because they satisfy the data requirement through their own configuration.

Mixed Mode

You can mix MTF and non-MTF nodes in the same strategy. The canvas supports hybrid layouts where:

• Some nodes are self-connected via MTF overrides (no left edge to the data source).
• Other nodes get their data from the main data source via physical edges (traditional connection).
• Signal-flow edges (indicator → condition, condition → logic, logic → entry) continue to work exactly the same regardless of whether the source node uses MTF.

This mixed mode is powerful: you can have a 4h SMA as a trend context indicator (MTF, self-connected) feeding into a condition that also receives a 1h RSI (from the main data source), with both conditions gating the same entry.

Edge Removal on MTF Change

When you enable MTF on a node and set a differing timeframe (or symbol, or bar type), any existing Data Source → Node edge on the left handle is automatically removed. The node no longer needs it, and keeping the edge would create ambiguity about which data source the node should use. Conversely, when you clear the MTF override (resetting all fields to “Same as Data Source”), the edge must be manually reconnected — the system does not automatically restore it.

Condition nodes have unique MTF behavior because they bridge indicators/patterns (computational nodes) with price data (reference data). Their MTF settings depend on what’s connected to them.

Left Side = Price

This occurs when a level node (Fibonacci, Pivots, Price Levels, Volume Profile) connects to right, which auto-sets left.type to “price”. In this scenario:

• The condition shows MTF fields (Symbol, Bar Type, Timeframe) in its inspector.
• These fields inherit from the data source by default but can be overridden.
• Example: “4h price crosses above daily pivot.” The condition needs to know whether “price” means 4h price or 1h price. Override the condition’s timeframe to 4h so the price comparison happens on 4h bars, aligning with the higher-timeframe context.

Left Side = Indicator / Pattern / Signal

When the condition receives a value or signal from an indicator or other computational node on its left handle:

• The condition does NOT need its own MTF settings — the connected source node handles its own MTF configuration independently.
• The condition simply receives the computed value (which was derived at whatever timeframe the source node used) and evaluates it against the configured operator and right-side value.
• The condition is timeframe-agnostic in this mode — it doesn’t care whether the RSI value came from 1h or 4h bars, it just checks if RSI < 30.

Trigger Bar Interaction

When the data source has a trigger bar configured AND a condition uses “price” on the left side, the condition evaluates on the trigger bar’s timeframe for precise signal timing. This means:

• The main logic (indicator calculations) runs on the strategy’s main timeframe.
• The condition’s price comparison (e.g., “price > SMA 50”) executes on the trigger bar timeframe within each main bar’s window.
• This gives you the best of both worlds: higher-timeframe signal generation with lower-timeframe execution precision.

Filters have special MTF considerations because their data requirements differ from regular computational nodes. Each filter type behaves differently under MTF.

Trend Filter

When MTF is enabled on the Data Source:

• The trend filter can have its own MTF override (Symbol, Bar Type, Timeframe) in its inspector.
• The connected indicator inherits its data from the trend filter’s configuration, not from the main data source. This means the indicator attached to a 4h trend filter also runs on 4h bars.
• Practical use: Configure a trend filter at 4h with an SMA 50 attached. The filter evaluates “is price above 4h SMA 50?” regardless of what timeframe the rest of the strategy uses. This is how you implement a “4h trend filter” while entry signals come from 1h conditions.

Volatility / Volume / Regime Filters

These filters connect to a data source via filter-ds handle:

• When MTF is enabled, the filter can override its own data source settings — Symbol, Bar Type, Timeframe.
• With MTF override set, the required data source connection to filter-ds is relaxed — the filter fetches its own data at its configured resolution and computes its metric (volume ratio, volatility percentile, regime state) independently.
• Without MTF override on the filter, it still needs the filter-ds connection to receive price data.
• Example: A volatility filter at 1d can assess whether today is a high-volatility day, while the strategy trades on 1h bars. The filter gates entries during high-volatility periods regardless of the entry timeframe.

Time Filter

The time filter is unaffected by MTF. Time is universal — a session filter that only allows entries between 09:30–16:00 EST works the same regardless of what timeframe the strategy runs on. The time filter has no data requirements and therefore has no MTF override fields.

Filter-to-Entry Connections

Regardless of whether a filter uses MTF, the filter’s gate output handle still connects to Entry/Exit filter-0..4 handles exactly as in non-MTF mode. MTF only affects where the filter gets its data — not how its output is consumed.

DO:

• Use higher timeframes (4h, 1d) for trend/context filters and lower timeframes (1h, 15m) for entry signals. This aligns with how markets actually work: the dominant trend is set on higher timeframes, and entries are timed on lower ones.
• Keep the number of distinct timeframes reasonable (2–3 max). Each additional timeframe adds API calls and computational cost during backtesting. A strategy with 1h + 4h + 1d is usually sufficient. Adding 5m, 15m, 30m, 1h, 4h, and 1d all at once is overkill and produces diminishing returns.
• Use the trigger bar for execution precision rather than adding a third MTF indicator. If all you need is better entry timing within a 1h bar, the trigger bar at 5m or 15m is more efficient than creating separate 5m indicator nodes.
• Name your nodes with timeframe hints in the alias. Use names like “SMA 50 (4h)”, “RSI 14 (1h)”, or “Trend Filter (1d)”. This makes the canvas self-documenting and helps you (and others) understand the strategy at a glance.
• Test MTF strategies thoroughly. Multi-timeframe logic can have subtle timing interactions — a 4h bar closes at a different time than a 1h bar, causing signals to appear at different moments. Always backtest across multiple date ranges and market regimes before deploying.
• Start simple and add MTF incrementally. Begin with a working single-timeframe strategy, then add one higher-timeframe trend filter. Verify the backtest improves. Then add a lower-timeframe trigger. This incremental approach makes it easy to isolate which MTF layer is helping (or hurting).

DON’T:

• Don’t use MTF to reference completely different symbols unless you fully understand the correlation risks. BTC dominance as a filter for ETH trades may seem clever, but the correlation breaks down in volatile markets. Test cross-symbol strategies across major market events before relying on them.
• Don’t override bar_type per-node unless absolutely necessary. Mixing Spot and Linear bar types on the same symbol causes confusion — the backtest must reconcile different price feeds, and the results may not reflect real execution.
• Don’t forget that MTF nodes are independent. They don’t see the main data source’s data. If you need the main timeframe’s value AND a higher timeframe’s value of the same indicator, you need two indicator nodes — one at each timeframe — not one node with both connections.
• Don’t use a higher timeframe for entry timing. Higher timeframes have fewer bars, which means fewer entry opportunities and delayed signals. If your strategy runs on 1h bars and you set an entry condition to 1d, you’ll get at most one signal per day — and it will arrive at the daily close, not when the 1h setup actually triggered. Higher timeframes are for context, not timing.

Performance Consideration

Each unique (Symbol, Bar Type, Timeframe) combination requires a separate data fetch from the exchange API. The performance implications during backtesting:

• Single-timeframe strategy: 1 data fetch per backtest.
• MTF strategy with 2 timeframes: 2 data fetches per backtest (2× API calls).
• MTF strategy with 3 timeframes: 3 data fetches per backtest (3× API calls).
• MTF with trigger bar: Adds 1 additional fetch (the trigger bar data stream).

The credits estimator in the backtest configuration accounts for this automatically — it detects the number of unique (symbol, bar_type, timeframe) tuples in your strategy and adjusts the credit cost estimate accordingly. More timeframes = more data = more credits. Be mindful of this when designing strategies with many distinct MTF configurations.