Backtesting & Research Libraries

What this category is

Code you run yourself to test a strategy against historical data, and in several cases the same code running it live afterwards. Almost everything here is open source and free, so the questions that decide the choice are not commercial.

The catalogue lists these as products because a reader chooses between them, but a licence file and a commit log are the specification. That makes them the cheapest cards here to verify and the easiest to get wrong from memory: relicensing and abandonment are exactly the events that published summaries lag behind.

It is also the one corner of this catalogue where nobody will ask you to get on a call. Not one card here carries a tier with the price left off — the priced on request list puts this category at zero against three quarters of the market data APIs, and that gradient is the difference between selling software and reselling somebody else's licensed data. Three products here charge anything at all: Jesse sells a one-time licence for the live half, VectorBT PRO a subscription and a lifetime seat, and QuantConnect Cloud hosted compute and data by the month. Everything else is a repository. Your budget is not the constraint here; your own time is.

The licence file is the specification

Read it before the feature list, because it is the only field on these cards that can stop a project outright. Four kinds of licence are in use here, and the difference matters the moment the engine is going anywhere other than your own machine.

Permissive. MIT covers Barter, HftBacktest and Jesse; Apache-2.0 covers LEAN and adds an explicit patent grant, which is why it tends to be the licence a company picks when it open-sources something it also sells. LEAN is exactly that case — the engine is free, the hosted platform and the crypto data that make it useful are the paid half.

Copyleft, in three strengths. LGPL-3.0 on NautilusTrader lets you link the engine into a closed product; modifications to Nautilus itself carry the licence with them. GPL-3.0 on Freqtrade and Lumibot says that if you distribute a derived work the source goes with it — running one privately, however much money it makes, distributes nothing and triggers nothing. AGPL-3.0 on Backtesting.py is the one that reaches a business that thought it was safe: offering a modified copy over a network counts as distribution, so an internal research notebook is fine and a customer-facing "backtest this strategy" button is a source obligation.

Source-available, which is not open source. VectorBT is Apache-2.0 with a Commons Clause bolted on — read it, fork it, run it, and you may not sell it. VectorBT PRO is proprietary with the source shown to paying members. Both are perfectly legitimate and neither meets the open-source definition, which is why neither appears on the open source list where the rest of this category's licences are grouped.

Every licence string on these cards was read out of the repository's own LICENSE file rather than a README badge, a package classifier or a documentation site, because those three disagree with the file often enough that checking is a standing job. The worst case in this catalogue sits one category over: dYdX v4 Clients carries an AGPL badge and an AGPL declaration in its package metadata against six identical custom LICENSE files whose grant terminates automatically if you fall out of step with the venue's terms of use.

What actually decides the choice

Does it model the instrument you trade. Spot backtesting is well served by general-purpose libraries that were never written for crypto. Perpetual futures are not. Four engines here settle a funding payment at all: Freqtrade downloads mark and funding-rate candles alongside the usual OHLCV in futures mode, LEAN applies position notional times the rate at 00:00, 08:00 and 16:00 UTC, NautilusTrader emits a settlement at each venue boundary that debits longs and credits shorts, and QuantConnect Cloud is LEAN plus the funding data LEAN does not ship. The rest price a perpetual as spot. In Backtesting.py, VectorBT and VectorBT PRO the word does not appear in the source at all — which is a cleaner answer than a half-implementation, and the cards say so rather than implying a gap.

Whether the engine says so when it is not modelling something. This is the trap underneath the previous point, and it is worse than a missing feature. LEAN's funding model is real and its funding data is opt-in: with no funding-rate feed loaded it charges nothing and reports nothing. Liquidation is a separate switch again — off by default in NautilusTrader, off until you enable it in Freqtrade, off by default in Jesse. An engine that could have closed your position and was never asked to check hands you the equity curve of a trade that did not survive.

What it charges you per fill by default. Two engines here open with a real exchange fee: Freqtrade reads the venue's own maker and taker rates out of market info, and Jesse ships per-exchange rates — 0.1% Binance spot, 0.04% Binance perpetual. One refuses to guess at all: HftBacktest makes you pick one of three fee models before the asset is built, which is the correct behaviour for a backtester whose users are frequently testing a maker rebate, where the sign of the taker fee is the strategy. Everywhere else the default we could read is zero — Backtesting.py ships spread and commission at zero, Lumibot's backtesting broker returns immediately when no fee object is attached, VectorBT's settings carry fees and slippage at 0.0, LEAN's fee and slippage models are zero until set, and NautilusTrader's default fill model treats a touched limit order as filled with no slippage. What a crypto backtest assumes works through the fill rule and the cost model in the detail this page cannot.

Event-driven or vectorised. A vectorised engine computes fast over a whole series and cannot easily express a rule that depends on what happened at the last fill. An event-driven engine is slower and can. This is an architectural choice you do not get to revise later, and it is usually documented one level below the README.

Whether the backtest and the live loop are the same code. A framework that runs the same strategy object in simulation and in production removes an entire class of translation bug. One that requires a rewrite to go live is a research tool, and worth choosing deliberately as one.

Where the exchange connectivity comes from. A framework advertising a hundred exchanges is usually counting a dependency's exchange list — most often CCXT, which is filed under trading bots because that is the job it is hired for. That is fine and often the right design, but it means the connector's maintenance status, not the framework's, decides whether your venue keeps working.

Nothing here is a data source

Not one card in this category ships history. The engines compute; the numbers come from an exchange endpoint, a vendor, or a directory of CSV files you assembled yourself, which is why the coverage fields on these cards are mostly empty rather than unchecked. It is why QuantConnect Cloud exists as a separate product from LEAN at all, and why the expensive decision on this page is usually not which engine but which history — tick data, order-book snapshots and funding-rate series at the resolution your strategy needs. Price that against the market data APIs before you price the engine.

Reading the repository instead of the README

Liveness is a set of dates, not an adjective. Last commit on the default branch, last release and its date, and whether the repository is archived. "Actively maintained" with no date attached is not a fact, and a frozen exchange connector is the single most expensive thing to discover after you have built on it. Some of the engines in this catalogue have run for years without ever cutting a tagged release, which is a maintenance model rather than a fault — but it means "latest version" is whatever was on the branch the day you cloned it, and it removes the one date most readers use as a proxy for liveness.

Stars measure attention, not maintenance. The most-starred project in a niche and the best-maintained one are frequently not the same project, and a repository can gather thousands of stars in a year and then stop.

Read the tests for the thing you care about. The cheapest way to find out whether an engine models funding, queue position or partial fills is to search its test suite for the word. A feature with no test is a feature that works in the example and nowhere else, and in an open-source engine that search takes about a minute and settles a question the documentation usually leaves open.