TL;DR: Coding a backtest in Python with backtrader, vectorbt or backtesting.py gives you complete freedom over logic, data and execution assumptions, and for research outside Trigr's scope it is the right choice. The cost is that every source of error, including look-ahead bias, funding, cross-asset alignment and cost modeling, becomes your responsibility. Trigr trades that freedom for fixed, conservative conventions, point-in-time alternative data and a direct path to paper and live Hyperliquid agents.
What do Python backtesting libraries actually give you?
Python is the default language of quantitative research. If you have only used a charting tool so far, the TradingView Strategy Tester comparison covers that side; here the question is code. Three open-source libraries come up most often for strategy backtests. Each has a different design philosophy. Details below reflect their official documentation as of September 2026.
backtrader is an event-driven framework. You write a strategy class whose next() method runs bar by bar, and a broker object simulates orders. According to its order execution documentation, a market order executes at the opening price of the next bar, on the reasoning that the next price available after your logic runs is the upcoming open. It also documents slippage, commission schemes and a cheat-on-open mode.
backtesting.py is a compact library with a small API and interactive plots. Its API reference explains that market orders fill at the next bar's open unless trade_on_close=True, in which case they fill at the current bar's close. Commission can be a fixed amount, a percentage or a function; spread is a constant rate; leverage is expressed as margin.
vectorbt takes a vectorized approach. As its documentation puts it, it operates on pandas and NumPy objects, accelerated by Numba, so thousands of strategy variants can be packed into arrays and tested in seconds. A paid PRO version adds features such as leverage and limit orders.
| Library | Style | Default fill | Strength |
|---|---|---|---|
| backtrader | Event-driven, object-oriented | Next bar's open for market orders | Flexible order types and broker simulation |
| backtesting.py | Event-driven, minimal API | Next bar's open (or close with trade_on_close) |
Easy to learn, quick plots |
| vectorbt | Vectorized arrays | The price array you pass | Speed across huge parameter grids |
| Trigr | Hosted node graph | Next bar's open, always | Point-in-time data, explicit costs, deploy to agents |
What do you have to build yourself?
A library supplies an engine. It does not supply the rest of a research pipeline. For crypto perps, the gaps are substantial.
Data, and its timestamps
You need clean OHLCV for each market, and for anything interesting, more: funding rates, open interest, liquidations, macro series. Each source has its own timestamp convention. A daily FRED series stamped at midnight may not have been published until days later; a candle labeled with its open time contains information up to its close.
Getting this wrong is the most common way a coded backtest lies. A join on the wrong timestamp, or a resample() that labels a bucket by its start, quietly lets the strategy see the future. The article on look-ahead bias in crypto backtests shows several real patterns.
In Trigr, every feature uses only information available at the bar's close, and coarser inputs from other assets or data sources are carried forward, never read ahead. Missing data is never filled with invented values. You cannot turn that off, which is the point.
Signal timing in vectorized code
vectorbt is fast because it computes everything at once. The flip side is that it will happily compute an entry from a bar's close and fill at the same close if that is the price array you pass. Shifting signals by one bar, or passing next-bar open prices, is your job. That is a documented design choice, not a flaw, but it is an easy step to forget.
Trigr always fills at the next bar's open after a signal. The post on next-bar-open fills shows how much that single assumption can move a result.
Funding and perp mechanics
None of the three libraries ships perp funding data. You can model it with custom cash flows, but you need the historical series, the settlement schedule and the sign convention for longs and shorts. Hyperliquid's funding documentation explains that it settles funding hourly, which is different from the 8-hour schedule of most centralized exchanges.
Trigr includes funding as an opt-in cost: roughly 8-hour settlements, signed by side, from Binance's historical USDT-M series or a flat rate you set. Slippage is also opt-in, as a flat bps per fill against you; it is not an order-book model. Trading fees and the builder fee are always applied, and a first result is labeled gross so you know which view you are reading.
Intrabar ambiguity
When a take-profit and stop-loss are both inside one candle's range, a bar-based engine has to guess which came first. Libraries differ in how they resolve it, and custom code often resolves it by accident, in whatever order the checks happen to be written.
Trigr replays 5-minute bars inside a coarser bar to find the order, and if both are still touched in the same 5-minute bar, the stop wins. That can understate some strategies; it never flatters them.
Overfitting statistics
vectorbt makes it trivial to test ten thousand parameter combinations. That is useful and dangerous: the best of ten thousand backtests is mostly selection. You can compute the Deflated Sharpe Ratio (Bailey and López de Prado) yourself, but you need to count trials honestly.
Trigr's ML optimization runs report DSR using the run's trial count, plus PBO and an out-of-sample Sharpe from anchored, purged walk-forward validation. A plain backtest does not compute DSR or PBO and labels them as not yet computed. The point-in-time backtesting pillar connects these ideas.
Where does going live fit?
A Python backtest ends at a result. To trade it, you write or adopt an execution layer, handle exchange authentication, retries, partial fills, position reconciliation and protective orders, and host it somewhere reliable. The logic in your backtest and the logic in your live bot are often two separate codebases, and they drift. Open-source bots such as those covered in Trigr vs Freqtrade and Hummingbot close part of that gap, with the same self-hosting trade-off.
On Trigr, the strategy you backtested is the strategy an agent runs:
- Paper agents forward-test at the current Hyperliquid price with the taker fee and builder fee, without slippage or funding.
- Hyperliquid agents trade through a trade-only agent key that can place and cancel orders but cannot withdraw; you keep the master wallet key and custody.
- Propr agents run prop-firm challenge accounts.
- Every live entry ships with reduce-only take-profit and stop-loss orders, and agents reconcile against Hyperliquid every minute.
Backtests are not guarantees; perps are leveraged and can lose more than expected.
Can you combine code and Trigr?
Yes, and many technical users do. Trigr exposes an agents API and an MCP server, so a Python script or an AI coding assistant such as Claude Code or Codex can:
- search the capability catalog of assets, timeframes, indicators and data sources;
- create and edit strategy graphs;
- run credit-metered backtests with optional slippage and funding, including bounded date windows for detached research;
- read stored backtest runs and their full trade logs for free, and pull them into pandas for your own analysis.
Over MCP an assistant cannot start execution, place a live trade or withdraw. You can connect one from the connect an AI assistant page.
When is writing your own backtester the better choice?
Code wins clearly in these situations:
- Logic the graph cannot express. Custom exit graphs, path-dependent position management, pairs and spread trades, options, or portfolio optimization across dozens of assets. Trigr's graph has exactly one trigger and a single RISK block.
- Markets Trigr does not cover. Equities on a broker, spot altcoins, other venues. Trigr focuses on 43 certified crypto perps on Hyperliquid, plus TradFi perps via HIP-3 for backtests and paper agents only in the current beta.
- Tick or order-book research. Market-making and microstructure studies need data and fill models far below bar level.
- Custom ML. If you want to tune hyperparameters, engineer bespoke features or use your own model classes, Python is the tool. Trigr does no hyperparameter tuning and chooses among LightGBM, random forest and XGBoost.
- Full auditability of the engine. Open-source code can be read line by line.
When is Trigr the better choice?
- You want trustworthy perp backtests without building a data pipeline for funding, open interest, liquidations and macro series.
- You want conventions you cannot accidentally break: point-in-time features, next-bar-open fills, a conservative intrabar rule, an audit trail of real versus simulated inputs.
- You want to go from backtest to a paper and then a live non-custodial agent without writing an execution layer.
- You want to work with an AI assistant under exact-argument approvals.
Next steps
If you already have a Python backtest, rebuild the same rules on Trigr, run it gross and then net, and diff the two trade logs; disagreements usually point to a timestamp or fill assumption worth checking. Pricing includes a Free plan with 3,000 one-time trial credits to try it.