Backtrader Multiple Timeframes: Resampling and Signal Availability

The power and pitfalls of multi-timeframe tradingCopy Anchor Link

In quantitative strategy design, multi-timeframe (MTF) analysis is one of the most enduring approaches to market regime filtering. Popularized by Alexander Elder's Triple Screen trading system, the core intuition is straightforward: evaluate macro market structure, trend direction, and volatility regimes on a Higher Timeframe (HTF) such as Daily or Weekly bars, while timing precise entries, bracket stops, and order execution on a Lower Timeframe (LTF) such as 60-minute, 15-minute, or 5-minute bars.

When implemented correctly, multi-timeframe strategies offer tangible quantitative benefits:

• Noise Reduction: HTF indicators filter out high-frequency market churn and false breakouts common to intraday price action.
• Improved Risk-to-Reward Ratios: Sizing stops and triggers on lower timeframes allows for tighter risk boundaries relative to the broader macro swing.
• Capital Efficiency: Capital remains uncommitted until intraday momentum confirms the higher-timeframe thesis.

flowchart TD
    subgraph MacroRegime ["Higher Timeframe (HTF: Daily / 4H)"]
        D1["HTF Trend Filter\n(e.g., 50-period SMA, 200 EMA)"]
        D2{"Is HTF Bullish?\n(Close > SMA)"}
        D1 --> D2
    end

    subgraph MicroExecution ["Lower Timeframe (LTF: 60m / 15m)"]
        H1["LTF Timing Trigger\n(e.g., RSI Oversold Rebound, Donchian Break)"]
        H2{"LTF Trigger\nCondition Met?"}
        H1 --> H2
    end

    subgraph OrderEngine ["Cerebro Execution Engine"]
        Exec["Submit Buy Order to Broker\n(Executed on next LTF bar)"]
    end

    D2 -- "Yes (Regime Valid)" --> H2
    D2 -- "No (Regime Blocked)" --> Skip["Suppressed / Hold Cash"]
    H2 -- "Yes" --> Exec
    H2 -- "No" --> Wait["Wait for LTF Trigger"]

The lethal pitfall: Lookahead leakage across asynchronous barsCopy Anchor Link

Despite these conceptual advantages, multi-timeframe backtesting is the single most common source of lookahead bias in event-driven systems like Backtrader.

The mathematical root of this failure lies in filtration causality. Let the real-world market information available up to intraday time t be represented by the filtration \mathcal{F}_t^{\text{LTF}}. Let \bar{B}_D denote the daily bar spanning [t_{D,\text{open}}, t_{D,\text{close}}]. A technical indicator I(\bar{B}_D) derived from the daily bar (such as the daily closing price, daily high, or a 50-day SMA) is measurable only with respect to \mathcal{F}_{t_{D,\text{close}}}:

I(\bar{B}_D) \in \mathcal{F}_{t_{D,\text{close}}}

If an intraday execution logic evaluates I(\bar{B}_D) at 10:00 AM (t < t_{D,\text{close}}) to determine an hourly order:

A_t \in \mathcal{F}_{t_{D,\text{close}}} \quad \text{where} \quad t < t_{D,\text{close}}

This constitutes an overt causality violation. In historical simulations, the engine retroactively "peeks" up to 6 hours into the future, using closing prices and daily ranges that have not yet occurred in market time. The resulting backtest displays near-flawless win rates, negligible drawdowns, and inflated Sharpe ratios that instantly collapse during live execution.

[!WARNING] Accessing higher-timeframe bar data before that higher bar has officially completed its time interval is the primary vector for fatal lookahead bias in multi-timeframe backtesting.

Feeding multiple timeframes into CerebroCopy Anchor Link

Backtrader provides two distinct architectural mechanisms for supplying multiple timeframe data feeds to its orchestrator, cerebro:

1. Separate Pre-Calculated Feeds via cerebro.adddata()
2. Dynamic In-Engine Resampling via cerebro.resampledata()

Both methods require strict adherence to Backtrader's internal clock hierarchy.

The cardinal rule: data0 must be the lowest timeframeCopy Anchor Link

In Backtrader's execution model, datas[0] serves as the master clock for the entire simulation loop. The Strategy.next() method is invoked once for each step of the master clock.

If you load daily bars as data0 and hourly bars as data1, Cerebro steps forward only once per day. The strategy will skip all intraday bars, rendering the lower timeframe data completely useless for intraday execution:

CORRECT Hierarchy:
cerebro.adddata(hourly_feed)   <-- datas[0]: Master clock (ticks every 60 min)
cerebro.adddata(daily_feed)    <-- datas[1]: HTF reference (updates once per day)

INCORRECT Hierarchy (BROKEN):
cerebro.adddata(daily_feed)    <-- datas[0]: Master clock (ticks only once per 24 hours!)
cerebro.adddata(hourly_feed)   <-- datas[1]: Intraday granularity is skipped!

Method 1: Loading separate pre-calculated feedsCopy Anchor Link

In this pattern, you construct two independent bt.feeds.PandasData instances from separate historical datasets—one resampled or recorded at the hourly level, and one at the daily level:

import backtrader as bt

cerebro = bt.Cerebro()

# 1. Primary Lower Timeframe Feed (Master Clock)
feed_hourly = bt.feeds.PandasData(
    dataname=df_hourly,
    timeframe=bt.TimeFrame.Minutes,
    compression=60,
    name="hourly"
)
cerebro.adddata(feed_hourly)

# 2. Secondary Higher Timeframe Feed
feed_daily = bt.feeds.PandasData(
    dataname=df_daily,
    timeframe=bt.TimeFrame.Days,
    compression=1,
    name="daily"
)
cerebro.adddata(feed_daily)

While conceptually modular, this approach introduces substantial risk: the datetime indexing of df_daily determines whether Backtrader peeks into future data. If df_daily timestamps are set to midnight (00:00:00) or market open (09:30:00), Backtrader aligns that daily bar with the start of the day's intraday bars, exposing the daily close at the opening bell.

Method 2: Dynamic resampling via cerebro.resampledata()Copy Anchor Link

Backtrader's native resampling engine derives the higher-timeframe feed directly from the primary lower-timeframe stream:

import backtrader as bt

cerebro = bt.Cerebro()

# Base high-granularity feed
feed_hourly = bt.feeds.PandasData(
    dataname=df_hourly,
    timeframe=bt.TimeFrame.Minutes,
    compression=60,
    name="hourly"
)

# Add hourly feed as master clock (data0)
cerebro.adddata(feed_hourly)

# Dynamically resample data0 into daily bars as data1
cerebro.resampledata(
    feed_hourly,
    timeframe=bt.TimeFrame.Days,
    compression=1,
    name="daily"
)

Under the hood, cerebro.resampledata() wraps an internal Resampler buffer around feed_hourly. As each hourly bar arrives, the resampler updates an in-progress daily bar. Only when the daily boundary completes does it push a finalized bar into data1.

Comparative matrix: Separate feeds vs. dynamic resamplingCopy Anchor Link

The fundamental law of multi-timeframe synchronizationCopy Anchor Link

To design multi-timeframe strategies without lookahead bias, you must understand how data feeds progress through time in event-driven systems.

The bar completion lifecycle: Forming vs. confirmedCopy Anchor Link

At any given point during an active market session, two classes of higher-timeframe bars exist:

Real-Time Market Session: 2024-05-15 (09:30 - 16:00 EST)

Timeline:
──────────┬───────────────────────▲───────────────────────┬──────────>
      09:30 EST               12:00 EST               16:00 EST
   Session Starts           CURRENT TIME            Session Closes

HTF State at 12:00 EST:
├── Bar 2024-05-14 (Yesterday): [CONFIRMED & IMMUTABLE] -> Safe to query in next()
└── Bar 2024-05-15 (Today):     [FORMING / UNFINALIZED] -> UNSAFE: Close is unknown!

1. Confirmed Bar (D-1): The session has ended. Open, High, Low, Close, and Volume are finalized and static. Indicators calculated on this bar are immutable.
2. Forming Bar (D): The session is currently active. The "Close" of this bar is merely the latest traded price; High and Low may expand; Volume is incomplete.

The timestamp alignment trap in BacktraderCopy Anchor Link

When loading external daily data into Backtrader via PandasData, third-party providers (such as Yahoo Finance, Stooq, or Alpha Vantage) typically label the daily bar with a date string: 2024-05-15 or 2024-05-15 00:00:00.

When Backtrader synchronizes data0 (hourly) and data1 (daily), it matches timestamps using standard chronological ordering. Observe what occurs on the first intraday bar of the day:

Hourly Bar (data0): 2024-05-15 09:30:00
Daily Bar  (data1): 2024-05-15 00:00:00  <-- Pre-dated to midnight!

Evaluation in next():
self.data0.close[0] -> Price at 09:30:00
self.data1.close[0] -> Closes from the END of 2024-05-15!

Because 2024-05-15 00:00:00 is chronologically prior to 2024-05-15 09:30:00, Backtrader makes data1 bar 2024-05-15 active at the opening bell. Inside next(), accessing self.data1.close[0] yields the closing print of 2024-05-15 at 09:30 in the morning—a massive lookahead leak!

The two canonical solutions for causality preservationCopy Anchor Link

To guarantee causal validity when using separate feeds:

1. Timestamp Shift to Session Close: During data preprocessing, adjust all daily timestamps to the official market closing time (e.g., 2024-05-15 16:00:00). This ensures Backtrader will not expose the bar until the 16:00:00 hourly bar arrives.
2. The Lag-1 Access Rule: Within strategy logic, query the previous completed bar using index [-1] instead of [0]:

   Copy code

   # Evaluates yesterday's confirmed daily moving average:
   daily_trend_filter = self.daily_sma[-1]

Multi-feed alignment in Strategy.next()Copy Anchor Link

Backtrader's execution engine operates on a synchronized line buffer architecture. Understanding how lines step and advance across feeds is essential for writing robust multi-timeframe logic.

Step-by-step synchronization traceCopy Anchor Link

When cerebro.resampledata() is used, Backtrader automatically manages the availability boundary. The table below illustrates the actual internal state of data0 (hourly) versus data1 (daily resampled) across several intraday bars:

Notice what happens at Step 4: as soon as the first bar of January 5th arrives (00:30), the resampled data1 advances its completed bar to January 4th (23:59). Throughout all 24 hours of January 5th, self.data1.close[0] reliably serves the finalized closing price of January 4th.

Minimum period synchronization (minperiod)Copy Anchor Link

A subtle bug in multi-timeframe strategies occurs during warmup. Every indicator in Backtrader has a minperiod:

• If Hourly RSI(14) requires 14 hourly bars (14 hours).
• If Daily SMA(50) requires 50 daily bars (50 days = 1,200 hours).

Because cerebro postpones calling next() until all indicators have satisfied their minimum warmup periods, next() will not execute until bar 1,200 of data0 has completed.

If your dataset contains only 30 days of hourly data, an indicator like bt.indicators.SMA(self.data1.close, period=50) will prevent next() from ever executing, exiting the simulation with zero trades and no error messages.

[!TIP] Always verify that your lower-timeframe data covers a sufficient historical duration to fulfill the higher-timeframe indicator's warmup period: \text{Bars}_{\text{LTF}} \ge \text{Period}_{\text{HTF}} \times \text{Ratio}_{\text{LTF/HTF}}.

Complete runnable Backtrader example: Daily Trend Filter + Hourly ExecutionCopy Anchor Link

Below is a self-contained, reproducible Python script demonstrating causal multi-timeframe synchronization in Backtrader.

The strategy implements a dual-timeframe momentum model:

1. Higher Timeframe Filter (Daily): 20-period Simple Moving Average on resampled daily bars. Only permit long entries when the confirmed daily close exceeds the daily SMA.
2. Lower Timeframe Trigger (Hourly): 14-period Relative Strength Index (RSI) on 60-minute bars. Enter when RSI dips into oversold territory (< 35) while the macro trend is bullish.
3. Exit Rules: Liquidate position when RSI crosses into overbought territory (> 65) or when the macro daily trend turns bearish.

import datetime
import numpy as np
import pandas as pd
import backtrader as bt


def generate_synthetic_intraday_data(days: int = 90) -> pd.DataFrame:
    """
    Generate synthetic 1-hour OHLCV market data with realistic
    upward drift and cyclical volatility.
    """
    np.random.seed(42)
    n_hours = days * 24
    timestamps = pd.date_range("2024-01-01 00:00", periods=n_hours, freq="1h")

    # Upward drift with geometric Brownian motion component
    drift = np.linspace(0, 20.0, n_hours)
    innovations = np.random.randn(n_hours) * 0.45
    price_series = 100.0 + drift + np.cumsum(innovations)

    # Construct clean OHLCV bars
    df = pd.DataFrame(
        {
            "open": price_series + np.random.randn(n_hours) * 0.1,
            "high": price_series + np.abs(np.random.randn(n_hours) * 0.4),
            "low": price_series - np.abs(np.random.randn(n_hours) * 0.4),
            "close": price_series,
            "volume": np.random.randint(500, 3500, size=n_hours),
        },
        index=timestamps,
    )

    # Ensure internal OHLC consistency
    df["high"] = df[["open", "high", "close"]].max(axis=1)
    df["low"] = df[["open", "low", "close"]].min(axis=1)
    return df


class MultiTimeframeMomentumStrategy(bt.Strategy):
    """
    Dual-timeframe strategy:
    - data0: Hourly execution feed
    - data1: Daily resampled macro regime filter
    """
    params = (
        ("daily_sma_period", 20),
        ("rsi_period", 14),
        ("rsi_oversold", 35),
        ("rsi_overbought", 65),
    )

    def __init__(self):
        # 1. Lower Timeframe Indicator (Hourly)
        self.hourly_rsi = bt.indicators.RSI(
            self.data0.close, 
            period=self.p.rsi_period
        )

        # 2. Higher Timeframe Indicator (Daily Resampled)
        self.daily_sma = bt.indicators.SMA(
            self.data1.close, 
            period=self.p.daily_sma_period
        )

        # Internal tracking reference for active orders
        self.order = None

    def notify_order(self, order):
        if order.status in [order.Completed]:
            dt = self.data0.datetime.datetime(0)
            if order.isbuy():
                print(
                    f"[{dt}] EXECUTION: Bought {order.executed.size} @ "
                    f"${order.executed.price:.2f} (Comm: ${order.executed.comm:.2f})"
                )
            elif order.issell():
                print(
                    f"[{dt}] EXECUTION: Sold {abs(order.executed.size)} @ "
                    f"${order.executed.price:.2f} (Comm: ${order.executed.comm:.2f})"
                )
            self.order = None
        elif order.status in [order.Canceled, order.Margin, order.Rejected]:
            print(f"[{self.data0.datetime.datetime(0)}] ORDER STATUS: {order.getstatusname()}")
            self.order = None

    def next(self):
        # Prevent stacking multiple orders while an order is pending
        if self.order:
            return

        hourly_time = self.data0.datetime.datetime(0)
        daily_time = self.data1.datetime.datetime(0)

        # In resampled data1, data1[0] represents the last finalized daily bar
        htf_bullish = self.data1.close[0] > self.daily_sma[0]

        # Entry logic: HTF confirms bullish regime AND LTF RSI enters oversold pull-back
        if not self.position:
            if htf_bullish and self.hourly_rsi[0] < self.p.rsi_oversold:
                self.order = self.buy(size=50)
                print(
                    f"[{hourly_time}] SIGNAL BUY -> "
                    f"Daily Close (${self.data1.close[0]:.2f}) > SMA (${self.daily_sma[0]:.2f}) | "
                    f"Hourly RSI: {self.hourly_rsi[0]:.2f} | Confirmed HTF Bar: {daily_time}"
                )
        else:
            # Exit logic: RSI overbought threshold reached OR HTF trend breaks downward
            if self.hourly_rsi[0] > self.p.rsi_overbought or not htf_bullish:
                self.order = self.close()
                exit_reason = "RSI Overbought" if self.hourly_rsi[0] > self.p.rsi_overbought else "HTF Breakdown"
                print(
                    f"[{hourly_time}] SIGNAL EXIT ({exit_reason}) -> "
                    f"Hourly RSI: {self.hourly_rsi[0]:.2f} | HTF Bullish: {htf_bullish}"
                )


def run_multi_timeframe_backtest():
    # 1. Instantiate Cerebro engine
    cerebro = bt.Cerebro()

    # 2. Generate and load base hourly data
    raw_data = generate_synthetic_intraday_data(days=90)
    feed_hourly = bt.feeds.PandasData(
        dataname=raw_data,
        timeframe=bt.TimeFrame.Minutes,
        compression=60,
        name="hourly"
    )
    cerebro.adddata(feed_hourly)

    # 3. Resample hourly feed to daily feed within Cerebro
    cerebro.resampledata(
        feed_hourly,
        timeframe=bt.TimeFrame.Days,
        compression=1,
        name="daily"
    )

    # 4. Attach strategy, broker parameters, and commissions
    cerebro.addstrategy(MultiTimeframeMomentumStrategy)
    cerebro.broker.setcash(100000.0)
    cerebro.broker.setcommission(commission=0.001)  # 10 bps per trade

    print("--- Starting Backtest Simulation ---")
    initial_val = cerebro.broker.getvalue()
    print(f"Initial Portfolio Capital: ${initial_val:,.2f}")

    # 5. Run simulation
    cerebro.run()

    final_val = cerebro.broker.getvalue()
    net_pnl = final_val - initial_val
    print("--- Simulation Complete ---")
    print(f"Final Portfolio Capital:   ${final_val:,.2f}")
    print(f"Net Profit / Loss:         ${net_pnl:+,.2f} ({(net_pnl / initial_val) * 100:+.2f}%)")


if __name__ == "__main__":
    run_multi_timeframe_backtest()

Execution log auditCopy Anchor Link

When executed, the script logs the exact bar-by-bar timestamps and execution details:

--- Starting Backtest Simulation ---
Initial Portfolio Capital: $100,000.00
[2024-01-22 10:00:00] SIGNAL BUY -> Daily Close ($105.66) > SMA ($101.53) | Hourly RSI: 34.85 | Confirmed HTF Bar: 2024-01-21 23:59:59.999989
[2024-01-22 11:00:00] EXECUTION: Bought 50 @ $103.90 (Comm: $5.20)
[2024-01-24 00:00:00] SIGNAL EXIT (HTF Breakdown) -> Hourly RSI: 42.69 | HTF Bullish: False
[2024-01-24 01:00:00] EXECUTION: Sold 50 @ $100.44 (Comm: $5.02)
[2024-01-27 22:00:00] SIGNAL BUY -> Daily Close ($104.61) > SMA ($102.73) | Hourly RSI: 32.90 | Confirmed HTF Bar: 2024-01-26 23:59:59.999989
[2024-01-27 23:00:00] EXECUTION: Bought 50 @ $101.62 (Comm: $5.08)
...
--- Simulation Complete ---
Final Portfolio Capital:   $101,421.35
Net Profit / Loss:         +$1,421.35 (+1.42%)

Notice the crucial diagnostic print:

Confirmed HTF Bar: 2024-01-21 23:59:59.999989

When the buy signal triggers on January 22 at 10:00:00, the daily close being evaluated is stamped 2024-01-21 23:59:59. The strategy strictly evaluates yesterday's finalized daily close, maintaining complete mathematical causality.

Multi-timeframe strategies in modern research enginesCopy Anchor Link

While Backtrader pioneered event-driven multi-feed simulation in Python, maintaining synchronization across complex object graphs introduces operational friction. Resampling inside the event loop adds computational overhead, and subtle timestamp discrepancies between feeds frequently lead to undetected lookahead bugs.

The modern paradigm: Separation of ETL and executionCopy Anchor Link

In modern quantitative workflows, experienced research teams decouple feature engineering from backtest execution.

Rather than forcing the backtesting engine to act as a runtime data aggregator, multi-timeframe indicators are computed during the upstream data pipeline using pandas and pandas-ta-classic. The resulting higher-timeframe features are lagged by one bar (.shift(1)) and merged directly onto the lower-timeframe execution DataFrame using pandas.merge_asof().

flowchart LR
    subgraph DataETL ["Upstream Data Pipeline (Pandas / Vectorized)"]
        D_Raw["Raw Daily OHLCV"] --> D_Ind["Compute Daily 50 SMA"]
        D_Ind --> D_Shift["Explicit .shift(1)\n(Strict Causality Guard)"]
        
        H_Raw["Raw Hourly OHLCV"] --> Merge["pd.merge_asof(direction='backward')"]
        D_Shift --> Merge
    end

    subgraph ExecutionEngine ["Execution Engine (OpenBacktesting v0.2.1)"]
        Merge --> OB_Feed["Single Consolidated DataFrame\n[Open, High, Low, Close, Daily_SMA_Lag1]"]
        OB_Feed --> OB_Loop["Bar-by-Bar Fast Simulation"]
        OB_Loop --> OB_Rep["Immutable SQLite Report & Studio"]
    end

Pre-computing multi-timeframe features in PandasCopy Anchor Link

Here is how multi-timeframe feature fusion is constructed cleanly before backtesting:

import pandas as pd
import pandas_ta_classic as ta

def build_multitimeframe_dataset(df_hourly: pd.DataFrame, df_daily: pd.DataFrame) -> pd.DataFrame:
    """
    Fuse daily regime indicators onto hourly execution bars
    with guaranteed mathematical causality.
    """
    # 1. Compute higher-timeframe indicators on daily bars
    df_daily["daily_sma50"] = ta.sma(df_daily["close"], length=50)
    
    # 2. CRITICAL: Lag daily features by 1 bar to prevent session peeking
    df_daily["htf_sma50_confirmed"] = df_daily["daily_sma50"].shift(1)
    df_daily["htf_close_confirmed"] = df_daily["close"].shift(1)
    
    # Select only the confirmed features and datetime index
    htf_features = df_daily[["htf_sma50_confirmed", "htf_close_confirmed"]].dropna()

    # 3. Asynchronously merge onto hourly execution timestamps
    df_hourly = df_hourly.sort_index()
    htf_features = htf_features.sort_index()

    df_merged = pd.merge_asof(
        df_hourly,
        htf_features,
        left_index=True,
        right_index=True,
        direction="backward"  # Match latest confirmed prior timestamp
    )

    # 4. Compute lower-timeframe indicators
    df_merged["hourly_rsi14"] = ta.rsi(df_merged["close"], length=14)

    return df_merged

Why feature pre-computation is superior for researchCopy Anchor Link

OpenBacktesting (version 0.2.1) is purpose-built around this single-asset historical OHLCV bar-by-bar execution model:

1. Guaranteed Causality: Because the higher-timeframe indicator is explicitly lagged (shift(1)) prior to merging, lookahead bias is mathematically impossible. You can visually inspect the DataFrame before any simulation runs.
2. Deterministic Execution Speed: Event-driven runtime resampling requires branching conditionals and memory allocations on every tick. Pre-calculating indicators in vectorized C/NumPy accelerates simulation speeds, enabling rapid parameter search (such as SAMBO Bayesian optimization).
3. Transparent Auditability: Backtrader's line buffers hide intermediate indicator states inside memory pointers. In OpenBacktesting, all signals, trailing stops, and execution fills map directly to immutable columnar DataFrames (trades_df and portfolio_df), which can be inspected directly in local browser-based OpenBacktesting Studio.
4. Zero Synchronization Bugs: By collapsing multi-timeframe features into a single consolidated bar stream, you eliminate engine-level clock desynchronization, incomplete session boundaries, and missing bar errors.

Architectural comparison: Backtrader multi-feed vs. OpenBacktesting feature fusionCopy Anchor Link

Summary checklist for multi-timeframe researchCopy Anchor Link

Before accepting backtest performance metrics from any multi-timeframe trading system, audit your pipeline against this engineering checklist:

• Verify Master Clock Assignment: Ensure data0 is assigned to the smallest timeframe feed. Never add daily data before intraday data in cerebro.adddata().
• Audit Daily Timestamp Conventions: If using separate CSV or DataFrame feeds, confirm whether daily timestamps represent bar start (00:00:00), bar open (09:30:00), or bar close (16:00:00).
• Enforce the Lag-1 Rule on Unadjusted HTF Feeds: If daily data is stamped at 00:00:00, query data1.close[-1] inside next(), never data1.close[0].
• Prefer Native Resampling: Use cerebro.resampledata() instead of ad-hoc separate feeds when raw high-resolution intraday data is available.
• Verify Minimum Warmup Periods: Ensure lower-timeframe history spans enough bars to satisfy \text{HTF Period} \times \text{Compression Ratio}.
• Log Bar Synchronization Explicitly: Add diagnostic print statements in next() comparing self.data0.datetime.datetime(0) with self.data1.datetime.datetime(0) during strategy development.
• Transition to Upstream ETL Feature Fusion: For production research, pre-calculate HTF indicators in pandas using .shift(1) and pd.merge_asof(), eliminating runtime engine synchronization bugs entirely.

Further reading and technical resourcesCopy Anchor Link

• Backtrader Tutorial: Build and Inspect Your First Strategy — Foundational Cerebro architecture, LineSeries data feeds, and order execution hooks.
• What Is Lookahead Bias? Detect Future Data in Python Backtests — Deep dive into filtration causality, vectorized shift errors, and leak detection protocols.
• Backtrader Custom Data Feeds: Extending PandasData — Mapping custom columns, timestamps, and extended features into Backtrader.
• Backtrader Stop Loss Orders: Gaps and Execution Mechanics — Modeling native resting stop orders, slippage, and orphan order elimination.
• OpenBacktesting Documentation — Fast, causal, single-asset historical backtesting with declarative order execution and SQLite trial persistence.