# Hummingbot vs Freqtrade: only one backtests the job it is built for

One framework quotes both sides of a book, the other runs a signal strategy. Only Freqtrade can backtest its own job; Hummingbot reaches more venues.

*https://cryptomarkets.tools/compare/hummingbot-vs-freqtrade*

- https://cryptomarkets.tools/tools/hummingbot.md
- https://cryptomarkets.tools/tools/freqtrade.md

## Two frameworks, two jobs

These two get typed together because both are free, both are Python, both run on your own
machine, and both trade crypto against an exchange with your key. They are not built for the same
job, and almost every difference below follows from that.

**[Hummingbot](https://cryptomarkets.tools/tools/hummingbot)** is a market-making framework. The homepage sells "the open
source framework for crypto market makers", and the strategies it is known for — Pure Market
Making, Avellaneda, Cross-Exchange Market Making — keep resting quotes on both sides of a book;
the spread is what they are trying to capture. Its catalogue job is `market_making`.

**[Freqtrade](https://cryptomarkets.tools/tools/freqtrade)** is a signal framework. You write a strategy that decides when to
enter and exit, backtest it on downloaded candles, optimise it with Optuna, dry-run it, and then
run the same class live. Its job is `automation`, and it is also listed on the backtesting shelf,
which Hummingbot is not.

So the first question is not which is better. It is whether your strategy rests quotes or takes
positions on a signal. If it rests quotes, Freqtrade has no strategy for you; if it takes positions,
Hummingbot's best machinery is pointed somewhere else.

## What you write, and in what

Both are Python, and in both the strategy is code you own.

In Freqtrade the strategy is one class operating on a pandas dataframe, and that class is what the
backtester runs, what dry-run runs and what trades live. There is no second implementation, which
is the reason to pick it.

Hummingbot carries two generations at once. The V1 quoting strategies ship in the repository. V2
splits a strategy into a controller that decides and executors that manage the order lifecycle —
position, DCA, grid, order, TWAP, XEMM, arbitrage and LP — and V2 is where new work lands. Writing
a Hummingbot strategy today means writing a controller that emits executor configs, and choosing
between V1 and V2 is also choosing whether the backtester can see your strategy at all (below).

## Venues, and who keeps a connector working

Hummingbot connects to more. The repository holds 26 spot connectors and 20 perpetual ones, plus a
paper-trade connector, and DEX access through Gateway — a separate TypeScript service covering an
Ethereum family (mainnet, Arbitrum, Base, BNB Chain, Polygon and others) and Solana, with
connectors for Uniswap, Jupiter, PancakeSwap, Raydium and more. Every exchange on Freqtrade's spot
list appears on Hummingbot's except the regional variants Bybit EU, Gate EU and MyOKX. The vendor
publishes three connector counts — 318, 50+ and 140+ — that count different things; the repository
count is the one to use.

Freqtrade reaches venues through ccxt and names the ones it supports: twelve spot entries and seven
for futures (Binance, Bitget, Bybit, Gate, Hyperliquid, Kraken, OKX), with Bitvavo and KuCoin
community-tested and everything else ccxt reaches marked "we cannot guarantee they will work". Its
DEX reach is Hyperliquid, which it can trade live but cannot backtest, because the venue returns
no history.

How a connector stays alive differs more than the counts do. In Hummingbot, which connectors exist
is a governance question: HBOT holders vote to add and remove them, and maintenance is paid by
bounties that exchanges fund. If your venue's connector stops being maintained, a vote decides
whether it comes back. In Freqtrade the connector is ccxt plus the project's own support list,
and nothing on the card ties a venue's place on that list to a payment.

## The backtest: one runs the strategy, the other runs something else

This is the finding neither card states on its own. Freqtrade's backtester runs the strategy
Freqtrade is built to run. Hummingbot's backtester does not run the strategies Hummingbot is built
to run.

**Freqtrade** downloads candles once and stores them locally. It reads the venue's fee from market
info, though it charges the higher of maker and taker on every fill. In futures mode it pulls mark
and funding-rate candles, settles funding during the run and exits at the liquidation price, where
the venue serves that history; where it does not, the fallback is a constant the docs recommend
setting to zero. Its fills are optimistic and the docs say so: no slippage, and intra-candle
movement is a guess unless you pass a faster timeframe with `--timeframe-detail`. The automatic
pairlists do not run in a backtest.

**Hummingbot** has a backtester only in the V2 engine, and only for four of its eight executors —
position, DCA, grid and order. A passive quote is filled, in full, the moment a one-minute candle
closes through its price, and priced at that close rather than at the quote, so the spread you
meant to earn is not what the result is computed from. Costs are a flat 0.0002 a side, the same
for maker and taker, with no rebate. There is no funding, liquidation or slippage anywhere in the
package. XEMM, arbitrage, TWAP and LP cannot be simulated, the V1 strategies cannot be run at any
setting, and the `hbot` CLI cannot reach the backtester; you go through Python or Dashboard, a
separate repository last pushed on 27 October 2025.

Neither models a market maker's real question — whether a resting order would have been filled.
Freqtrade does not try, because it has no quoting strategy. Hummingbot is built for exactly that
question and assumes the answer. The [backtest guide](https://cryptomarkets.tools/guides/what-a-crypto-backtest-assumes)
covers the assumptions in general; on this pair, the backtester is the reason a directional
strategy belongs on Freqtrade even where Hummingbot has the connector.

## Where the key lives, and what you run

Both run on hardware you control, and in both the exchange key stays with you: Freqtrade holds
your API keys and calls the exchange directly, and Hummingbot runs locally, where its quickstart
needs no key at all for a paper-trading bot. Neither sells a hosted tier.

The burden after that is not the same. **Freqtrade** is one program: Docker, which the project
recommends, or Python 3.11+ with TA-Lib, on a documented floor of 2 GB RAM, 1 GB disk and 2 vCPU.
The REST API, the FreqUI web interface, the Telegram bot and webhooks are all inside it.

**Hummingbot** is one program for one bot on one centralised venue, and a set of services after
that. Docker runs the classic interactive client by default; a source install wants Anaconda or
Miniconda. DEX trading adds Gateway. Running several bots, agent control or the first-party MCP
server adds the Hummingbot API server, and the MCP server is a further install on top of it.
Alerts are not in the client at all — the notifier has no implementations and there is no Telegram
— so being told the bot stopped means Condor or something you build. And by default each instance
reports aggregated volume, the connector, the version, system specs and a random ID every 15
minutes, off with one setting. The Freqtrade card records no such feed.

## Who pays for each

Both are free to you and sell you nothing. The difference is what the card can say about the
other side.

Hummingbot's foundation publishes its rate card: a maintained connector from 10,000 dollars a year
through bounty management, a sponsorship from 50,000, and a README sponsor table where Binance
carries a 10% fee-discount referral link and Gate.io, KuCoin and OKX 20% ones — which is why
Binance is the quickstart exchange. The default-on volume reporting is what the foundation's public volume
dashboard is built from.

The Freqtrade card records no hosted tier, no signal subscription, no commercial licence and no
token, no commission on orders and no routing through anything of its own. It does not record what
funds the project. The [guide to who pays for free bots](https://cryptomarkets.tools/guides/who-pays-for-your-free-trading-bot)
explains why the question is worth asking before the feature list.

The licences differ in a way that matters only if you distribute a modified bot: Apache 2.0 is
permissive, GPL-3.0 is copyleft for what you distribute. Running a private
strategy on your own server obliges you to publish nothing under either.

## Dates under this page

Both cards' pricing, capability and coverage blocks were verified on 19 September 2026, and both
were last updated on 3 October. Freqtrade's fee rule and its funding fallback were re-checked on
3 October; Hummingbot's backtester findings, release dates and connector lists date from 19
September. Release cadence as of that date: Hummingbot one every five to eight weeks (v2.16.0 on
29 July), Freqtrade monthly (2026.8 on 31 August).

## Which one, and when

**Take Hummingbot** if the strategy quotes both sides — a spread, an Avellaneda model, a
cross-exchange hedge — or if the venue you need is a DEX pool or an exchange on its list and not
Freqtrade's. Accept, before you start, that you will be judging the quotes live or on paper,
because its backtester cannot tell you whether they would have filled, and budget for Gateway, the
API server and your own alerting as the setup grows.

**Take Freqtrade** the moment the strategy is a signal — enter on a condition, exit on another —
on a venue from its support list. It is the one whose backtest runs the class it will trade live,
charges a real venue fee, settles funding on perpetuals where the venue serves the history, and
reports through Telegram and webhooks out of one process. Check first that your venue serves
funding history, and pass your own fee if you rest limit orders.

**Do not run a directional strategy on Hummingbot because the connector is there.** The backtest
you would read is the weaker one by the card's own account. And if the simulator matters more than
either connector list, [NautilusTrader](https://cryptomarkets.tools/tools/nautilus-trader) is the engine built around an
order-book fill model; for signal frameworks alone, [Freqtrade vs Jesse](https://cryptomarkets.tools/compare/freqtrade-vs-jesse)
is the closer page.

## FAQ

### Which one should I use for market making?

Hummingbot. Freqtrade ships no market-making strategy and has no DEX middleware; its strategy is a class that reads a dataframe and emits entries and exits. Hummingbot is built around quoting both sides, with Pure Market Making, Avellaneda and Cross-Exchange Market Making in the repository. Just do not expect its backtester to tell you whether the quotes would have filled, because it has no market-making fill model.

### Which one has the better backtester?

Freqtrade, for the strategies each is built to run. Freqtrade stores candles locally, reads the venue's own fee, and in futures mode settles funding and stops at the liquidation price where the venue serves the history. Hummingbot's V2 engine fills a passive quote whenever a one-minute candle closes through its price, charges one flat cost for maker and taker, models no funding or liquidation, and cannot run the V1 strategies the project is named for at all.

### Do I need to know Python for either?

For Freqtrade, yes; the strategy is a Python class and there is no configure-instead path. For Hummingbot, new strategy work is a V2 controller in Python, and the classic quoting strategies ship with the client. Freqtrade's web interface and Telegram bot watch a running bot; neither is where the strategy is written.

### Is either one free, and who pays for it?

Both are free, with nothing to buy from either. Hummingbot's foundation publishes where its money comes from — exchanges pay from 10,000 dollars for a maintained connector and from 50,000 for a sponsorship, and the README carries fee-discount referral links. The Freqtrade card records nothing for sale at all, not even a hosted tier, and states that it adds no commission and routes orders through nothing of its own.