Algo trading on GitHub: project types and checks before you trust one

Contents

1. Can you use algo trading projects from GitHub?
2. What kinds of algo trading projects are on GitHub?
3. Which open-source backtesting frameworks are most used?
4. How do you check an open-source strategy for costs and look-ahead bias?
5. Can an open-source strategy place orders directly?
6. How do you validate a borrowed strategy on unseen data?
7. Frequently asked questions
8. References

Can you use algo trading projects from GitHub?

Algo trading GitHub projects are useful as building blocks and study material, not as finished strategies. A star count and a published equity curve say nothing about whether the rule survives commission, slippage and next-bar fills on data it has never seen. Treat every repository as untested until you have run it yourself with costs.

The reason is simple. A repository is code plus a claim. The code you can read and run. The claim, usually a chart or a table of returns, was produced on data the author chose, with settings the author tuned, often without costs. Nothing in a GitHub page tells you how many variants were tried before the published one. Bailey, Borwein, López de Prado and Zhu (2014) show that the best result from a large number of tries is inflated by selection alone, even when every rule tested is worthless. A shared script is the end of someone else's search, so it carries that inflation whether or not the author knows it.

This does not make the projects useless. A good backtesting library saves months of work. A bot shows how order handling is done. A strategy collection is a list of ideas to test. If you are new to the field, read what algo trading is, what it costs and why most rules lose first, because the checks in this article only make sense once you expect most borrowed rules to fail after costs.

What kinds of algo trading projects are on GitHub?

Open-source algo trading projects fall into three types with different jobs, and none of them alone gives you a tested, tradable futures strategy. A backtesting library is an engine that replays rules on old prices and reports the trades, with no strategy of its own. A trading bot is a program that connects to an exchange or broker and places orders from rules, usually for one exchange at a time. A strategy collection is a repository of rule scripts, shared as code, rarely with costs or out-of-sample results.

	Backtesting library	Trading bot	Strategy collection
What it contains	An engine: data loading, order simulation, report	An order connector, a scheduler, often a small backtester	Rule scripts, sometimes with a results chart
What it is missing	A strategy; often a futures contract model	Validation; usually any futures connector	Costs, out-of-sample results, parameter history
Typical market	Stocks in the data model; futures by hand	Exchanges with free public APIs	Mixed: stocks, forex, some futures
First thing to check	Where the fill price comes from	Risk controls and what happens on a disconnect	How many parameters were tuned

Most repositories under the search phrase "github trading bot" belong to the second type, and most of them talk to an exchange that publishes a free public API. Futures on CME or TAIFEX reach the exchange through a broker, so a bot for them needs a broker connection, which far fewer open-source projects ship. Sort a repository into its type before you read a line of code; it tells you what you will have to add yourself.

Which open-source backtesting frameworks are most used?

The commonly used open-source backtesting frameworks differ in how they process bars, which markets their data model fits, and whether they are still maintained, and those three facts decide which one fits a futures test. An event-driven engine processes one bar at a time, in order, the way a live system does. A vectorized engine computes the signals for the whole price series at once as arrays, which is fast but makes it easy to use a price the rule could not have known yet.

Framework	Processing model	Language	Futures data model	Default fill	Live-order connector	Activity
Backtrader	Event-driven	Python	Multiplier and margin in the commission settings; a rollover feed exists; sessions by hand	Next bar's open	Yes (Interactive Brokers, Oanda, Visual Chart)	Check the last release date
Zipline	Event-driven	Python	Continuous futures and trading calendars built in; calendars are US-centric	Next bar	Not in the core library	Original repository archived after Quantopian closed in 2020; continuation forks exist
vectorbt	Vectorized	Python	Works on price arrays; contract multiplier and sessions by hand	Same bar's close unless you shift the signals	No (open-source version)	Check the last release date
Backtesting.py	Bar-by-bar loop	Python	Single instrument; no contract multiplier; sessions by hand	Next bar's open	No	Check the last release date
Lean (QuantConnect)	Event-driven	C# with Python support	Futures with continuous contract mapping and rollover settings built in	Next market data after the order	Yes (several brokerages)	Maintained by a company

Two of these columns deserve your attention before any other. The default fill column tells you whether a plain copy of the examples will leak the close into the decision, which the next section explains. The futures data model column tells you how much you must build by hand: a contract multiplier, a session filter and a continuous series with the roll gaps handled. The list of things a futures tester needs from any software, open-source or not, is in algo trading software for futures: the five features that actually matter; use it as a checklist against whichever framework you pick.

How do you check an open-source strategy for costs and look-ahead bias?

Read the code for five things in a fixed order, and stop at the first one that fails. Look-ahead bias is any use of information in a backtest that was not available at the moment the rule decided. The most common form is a rule that reads a bar's close, decides, and fills at that same close. In live trading the close is only known when the bar is finished, and the first price you can get is the open of the next bar. Everything else on this list is cheaper to fix than that one, which is why it comes first.

1. Where does the fill price come from, relative to the signal bar? Find the line that sets the execution price. If it is the close of the bar that produced the signal, the test is leaking. A fill at the next bar's open, or a stop or limit price that the next bar actually traded through, is tradable. The ways this leak hides, including shifted indicator columns, are in look-ahead bias in backtests and the one-bar check.
2. Do commission and slippage exist, and are they applied per side? Search the code for a fee, commission or slippage setting. Many scripts have none. Some charge a percentage of notional, which fits stocks but not a futures contract with a fixed tick value. A futures test needs a fixed amount per contract per side for commission and at least one tick per side for slippage.
3. How was the data built? Check whether the price series is one contract, a continuous series with adjusted roll gaps, or raw concatenation of contracts. Check the session: a daily bar built from 23 hours of trading is a different instrument from one built from the day session. Check the time zone of the timestamps against the time zone of any time-of-day rule.
4. How many parameters were tuned, and on what? Count every number in the rule that could have been changed: lookbacks, thresholds, stop distances, time windows. Five tuned numbers on 60 trades is a description of that history, not a rule. Look in the commit history for how often those numbers moved.
5. Is the published result in-sample only? Read the README for the date range of the chart and the date range the parameters were chosen on. If they are the same range, or if no split is mentioned, treat the chart as an in-sample result, which is the best of whatever the author tried.

Checks one and two together explain why most shared scripts look best in the repository and worst on a real account. A same-bar fill adds a fraction of a bar's move to every trade, and the missing costs remove nothing. The combined effect is largest for rules that trade often, because they have the smallest move per trade and the most fills. When AlphaPrime (Valynox) evaluates a candidate it charges fees and slippage inside the evaluation and fills on the next bar, which is the setting described on the backtesting page; the five questions above are the same ones that setting answers before a search begins, and you can apply them to any script by hand.

Can an open-source strategy place orders directly?

Only a project that ships a broker or exchange connector can place orders, and most futures-ready paths run through a trading platform's own language, so a borrowed rule usually has to be rewritten for the platform where the orders go. A connector is the part of a program that logs in to an exchange or broker, sends orders and reads fills. Most GitHub bots have one for a single exchange with a free public API. A rule that lives in a Python script and a futures account at a broker are two separate things until something joins them.

There are three ways the join happens in practice:

1. A bot with a built-in connector. The code sends orders itself. This is common for exchanges with free public APIs and rare for exchange-traded futures, where the connection goes through a broker's API and the open-source projects that support it are few.
2. A framework with a brokerage connector. Backtrader and Lean can route live orders through supported brokers. You still run the program yourself, on a machine that stays on, and you own the risk controls.
3. A rewrite in the platform language. The rule is translated into the language of a trading platform, and the platform handles the broker connection, order types and session times. For futures this is the most common path. The platforms with their own strategy languages include MultiCharts (PowerLanguage), TradingView (Pine Script v6), TradeStation (EasyLanguage), NinjaTrader (NinjaScript), MetaTrader 4 (MQL4) and MetaTrader 5 (MQL5). AlphaPrime exports strategy source code to these six; the current list is kept on the supported platform export page.

The rewrite is also where the second test happens. A rule translated into a new language should produce a trade list on the same data that agrees closely with the original, trade by trade. Where it does not, the difference is usually fill timing, session boundaries or how the two engines treat a stop and a target inside the same bar. Fix the difference before the rule goes anywhere near an order.

How do you validate a borrowed strategy on unseen data?

Freeze the rules, run them with realistic costs on a later block of data the author never saw, count the out-of-sample trades, and remember that one kept candidate out of many tried carries a selection bonus. Out-of-sample data is the part of the price history that was not used to choose the rule or its settings. For a borrowed rule, the only data you can be sure of is data that did not exist when the repository was last changed, so the commit date of the parameters is your split date.

1. Record the rule and every parameter exactly as published, with the commit date. No changes, not even a rounded lookback.
2. Set costs for the market you trade: a fixed commission per contract per side and at least one tick of slippage per side, with next-bar fills.
3. Run on bars after the commit date only. This is the data the author could not have tuned on.
4. Measure the sample in completed trades rather than calendar years. Fewer than about 30 trades is a hint, not a result; a few hundred is a sample you can read.
5. Judge against a rule you wrote before looking: for example, the average trade after costs must stay positive and no single quarter may hold most of the profit.

The selection bonus is the part people skip. Whoever published the rule tried others first and kept the one that looked best. Harvey and Liu (2015) show how much a result should be discounted for the number of tests behind it, and Sullivan, Timmermann and White (1999) found that technical rules which looked strong over decades of stock data lost most of their apparent edge once the whole set of rules that had been searched was accounted for. The same applies to a rule found by a search inside AlphaPrime. The box below is such a run. It tests a stand-in rule built from a standard indicator, not a GitHub strategy itself: an Efficiency Ratio rule as the only entry and exit, with no stop, target or filter. The Efficiency Ratio measures how straight a price move was over a lookback, from near zero for choppy movement to near one for a straight line; how it is read as a trend measure is explained in the Kaufman efficiency ratio and its 0-to-1 reading. The run used NQ daily bars from 2019-01-02 to 2025-06-30, long and short, one contract, with $20 commission and $10 slippage per trade. The candidate shown is the one the search kept out of the 1,024 it tried, for its return against its drawdown. Picking the kept one after the fact flatters its result, exactly as a published GitHub script is flattered by the tries that came before it.

Read the box the way you would read a repository chart. The $104,570 net profit and the 2.309 profit factor are the kept candidate's in-sample record on this run, not something the rule earned or that a reader can expect. The number to look at first is 44 trades over about six and a half years. That is the swing-strategy problem from step four: a 63.64% win rate from 44 trades can move a long way if a handful of trades change, so the average trade of $2,376.59 is a hint about this candidate, not a measured edge. The $26,345 max drawdown is the drawdown this one history produced; a different ordering of the same trades would produce a different one. The run also spent 16.37% of the time in the market, so most of the period it held nothing, which matters when you compare it with a rule that is always in.

A borrowed rule that passes this test once is a candidate, not a strategy. It still needs the checks in the five checks before you trust an algo strategy that works consistently: neighbouring settings that behave alike, profit spread across time rather than one lucky quarter, and a result that survives doubled slippage. Run those on the same frozen rule, and write down the pass count you require before you look.

A concrete next step: pick one strategy collection you have starred, find the commit that last changed its parameters, and run the rule unchanged on your own futures bars from that date forward with a fixed commission and one tick of slippage per side. Count the trades before you read anything else. If you have never set up a test like that, the 30-day route to a first algo trading strategy for beginners walks through the setup in order.

Frequently asked questions

Is a GitHub trading bot safe to run with real money?

Only after you have read how it handles a lost connection, a rejected order and a position that exists at the exchange but not in the bot's memory. Most open-source bots were written and tested by one person on one account. Run any bot on a paper or simulated account first, with the same order sizes you plan to use, and watch how it behaves over a weekend and a reconnect.

Can I backtest futures with open-source software?

Yes, but most open-source backtesting frameworks were built around a stock data model, so the contract multiplier, the session filter and the continuous contract with its roll gaps are often things you add yourself. Zipline and Lean have continuous futures built in; Backtrader handles multiplier and margin in its commission settings; vectorbt and Backtesting.py leave these to you. Check how the framework fills an order before you check anything else.

Why do strategies from GitHub fail after costs are added?

Many shared scripts fill at the close of the bar that produced the signal and charge no commission or slippage. Both choices add to every trade, and the effect is largest for rules that trade often, because their move per trade is smallest. Once the fill moves to the next bar's open and a fixed cost per side is charged, the average trade of a frequent-trading script often drops below zero.

Do I need to know Python to use open-source algo trading projects?

For most of the widely used backtesting frameworks, yes, because they are Python libraries and the strategy is written as Python code. For a futures account the rule also has to reach a trading platform, which usually means a second language such as PowerLanguage, Pine Script, EasyLanguage, NinjaScript or MQL. Reading code well enough to find the fill price and the cost settings is the skill that matters most, even if you never write a strategy from scratch.

How much out-of-sample data does a borrowed strategy need?

Enough to hold a few hundred completed trades, measured from the date the rule's parameters were last changed in the repository. For a daily-bar rule that trades a few times a year, a single year after the commit date holds too few trades to judge, so you may need to wait, or widen the test across several related markets with the same frozen rule. Fewer than about 30 trades is a hint, not a result.

References

• Bailey, D. H., Borwein, J., López de Prado, M., & Zhu, Q. J. (2014). Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance. Notices of the American Mathematical Society, 61(5), 458–471.
• Harvey, C. R., & Liu, Y. (2015). Backtesting. The Journal of Portfolio Management, 42(1), 13–28.
• Sullivan, R., Timmermann, A., & White, H. (1999). Data-Snooping, Technical Trading Rule Performance, and the Bootstrap. The Journal of Finance, 54(5), 1647–1691.