Hummingbot

What it is

A Python framework for running a market-making bot on your own machine. That is the job it is built around: the homepage sells "the open source framework for crypto market makers", the foundation's income comes from exchanges who want volume, and the strategies the project is known for — Pure Market Making, Avellaneda, Cross-Exchange Market Making — are all quoting strategies.

There are two generations of that framework in the repository at once. V1 strategies are the classic ones listed above, plus perpetual market making, AMM arbitrage, spot-perpetual arbitrage, hedge and liquidity mining. V2 splits a strategy into a controller that decides and an executor that manages order lifecycle — position, DCA, grid, order, TWAP, XEMM, arbitrage and LP. Both still ship; the V2 side is where the backtester, the live config tuning and the composable pieces are, and it is where new work lands.

You run it three ways, all local: hbot, a non-interactive CLI installed from source, which the README now recommends first; the classic full-screen interactive client, which is the Docker default; or a container you attach to. Source install wants Anaconda or Miniconda. A separate Hummingbot API server, a Gateway process for DEX access, and Condor — the LLM harness — are separate repositories you add if you want them.

The licence in the repository is Apache 2.0: the LICENSE file itself, whose only copyright line reads "Copyright 2023 Hummingbot Foundation", with no Commons Clause and no other rider appended. Permissive, so a modified private bot obliges you to publish nothing.

Liveness in dates, as of 19 September 2026. The repository is not archived. master last moved on 30 July 2026 because it tracks releases; development is where the work is, and it last moved on 18 September. Release v2.16.0 shipped 29 July 2026, v2.15.0 on 16 June, v2.14.0 on 21 April — one every five to eight weeks, unbroken back through 2025. Open issues stand at 72, with 92 open pull requests counted separately; the number GitHub's API reports, 164, is the two added together.

Pricing

Free, with nothing for you to buy — no hosted tier, no paid licence, no strategy marketplace, no token gate. What is worth knowing is who does pay, because the catalogue's trading bots page says to read that before reading the feature list, and here the vendor publishes it.

Exchanges pay. The Foundation's Exchanges page prints a rate card: building your own connector and getting it through governance is free; Bounty Management starts at $10,000 and buys a community developer to build and maintain the connector for a year; sponsorship starts at $50,000 and buys priority development, custom features and co-marketing. Both are escrowed under a bounty agreement. Nine exchanges are currently listed as Foundation partners.

The README's sponsor table is the consumer-facing half of the same arrangement: eleven venues, of which Binance carries a −10% fee referral link and Gate.io, KuCoin and OKX carry −20% ones. That is why Binance is the exchange in the quickstart. It is not hidden and it is not disqualifying, but it is a reason the defaults point where they point.

Your own costs are a server, exchange fees and whatever the strategy loses.

Data & coverage

Hummingbot ships no market data. Every price comes from the venue you are connected to, over that venue's websocket where one exists, and history for a backtest is pulled from the exchange's own candle endpoint at run time. Depth of history is therefore whatever the venue keeps.

In the repository itself there are 26 spot connectors plus a paper-trade connector, and 20 perpetual connectors. Spot covers Backpack, Binance, BingX, Bitget, BitMart, Bitrue, Bitstamp, BTC Markets, Bybit, Coinbase Advanced Trade, Derive, Dexalot, Foxbit, Gate.io, Gemini, HTX, Hyperliquid, Injective, Kraken, KuCoin, Lambdaplex, Lighter, MEXC, NDAX, OKX and XRP Ledger. Perpetuals add Aevo, Architect, dYdX v4, EVEDEX, GRVT, Kalshi, Pacifica, Decibel and the perpetual arms of most of the spot list.

The connector count you are reading depends on who is counting, and the vendor publishes three different ones. The homepage says 318 connectors. The Exchanges page on the same site says 50+ exchanges. The README says users traded across 140+ venues. All three are true of different things: the 318 counts every Gateway DEX pool type across every network, the 50+ counts exchanges with a connector in the repo, and the 140+ counts venues that reported volume.

DEX access goes through Gateway, a separate TypeScript service. It supports two chain families — an Ethereum connector covering mainnet, Arbitrum, Avalanche, Base, BNB Chain, Celo, Optimism, Polygon, Unichain and Robinhood Chain, and a Solana connector — with DEX connectors for 0x, DFlow, Jupiter, Meteora, OKX DEX, Orca, PancakeSwap, Raydium, Titan and Uniswap.

Which connectors exist is a governance question rather than a roadmap one: HBOT holders vote to add and remove them, and the Foundation allocates maintenance bounties the same way. If your venue's connector stops being maintained, the thing that decides whether it comes back is a vote.

Running instances report home by default. Every 15 minutes each bot sends aggregated USD volume, the connector id, the version, general system specs and a random instance UUID; that feed is what the public dashboard's "$47B+ total trade volume, 111K+ instances" is computed from. It is documented, it excludes keys, addresses and individual trades, and it is off with one config setting — but it is on until you change it.

Integrations

The hbot CLI is the scriptable surface: every command prints compact Markdown, the run and observe commands take --json, and the contract for outcomes is the exit code. Trade fills are written to a local SQLite file, and the interactive client's export trades writes them out as CSV. There is an MQTT remote interface for controlling a bot from outside the process.

There is a first-party MCP server, in the Hummingbot organisation and under the same Apache 2.0 licence, which lets an agent drive a bot. It is a separate install and it talks to the Hummingbot API server rather than to the client, so it is two more services to run; its last commit was 23 March 2026.

Condor is the AI harness — LLM-driven strategies connected to deterministic execution through the Hummingbot API, controlled from Telegram or its own dashboard. It is a separate product with its own repository, and it is the reason the client itself does not need AI features of its own. The only AI-named thing in the client is an example controller that subscribes to an MQTT topic for predictions something else publishes.

Limitations

The backtester has no market-making fill model, which is the one thing a market maker needs it for. The V2 engine ships exactly four executor simulators — position, DCA, grid and order. Market-making controllers are reachable by it, because they emit position and order executor configs, but what those simulators do with a passive quote is compare it to a one-minute candle's close: if the close crosses your price you are filled, in full, instantly; if it never does you are never filled. No queue position, no partial fills, no constraint from traded volume. Fill probability at a resting price is the entire uncertainty of the business, and it is assumed away.

The fill is priced at the candle close rather than at the price you quoted. The simulator takes entry_price from the bar that triggered the condition, not from the executor's configured entry price. The spread you were trying to earn is not what the simulated P&L is computed from.

Costs are one flat number for both sides. The default is trade_cost=0.0002, charged as 2 * trade_cost on the round trip, identical for maker and taker, with no fee schedule and no maker rebate. For a strategy whose margin is the difference between the maker and taker fee, that is the wrong sign of error.

No funding, no liquidation, no maintenance margin, no slippage. Searching the whole backtesting package for any of them turns up a Plotly layout margin, a min-notional buffer in the grid simulator and nothing else. Run a perpetual strategy through it and the result is missing one of the two largest cash flows on the position, which is exactly the failure the trading bots page warns about.

Four of the eight executors cannot be simulated at all. simulate_executor dispatches on config type and returns None for anything that is not DCA, position, grid or order — so XEMM (cross-exchange market making), arbitrage, TWAP and liquidity provision have no simulator. DCA in taker mode raises NotImplementedError outright.

The V1 strategies are not backtestable by this engine at any setting. It takes a V2 controller. Pure Market Making, Avellaneda and Cross-Exchange Market Making — the three the project is named for — are a separate framework, and there is nothing that runs them against history.

And the CLI cannot reach the backtester. The hbot reference lists backtest <config> under proposed future commands with the note that the engine ships a backtester and the CLI cannot reach it. In practice you go through Python, or through Dashboard — a separate repository whose last push was 27 October 2025, against a client that has had seven releases since.

No Telegram, no webhooks, no alerting in the client. hummingbot/notifier/ contains an abstract base class and no implementations, and a search of both branches for "telegram" returns nothing. Notifications moved to Condor. If you want to be told the bot stopped at 3am, that is yours to build or another service to run.

Two more processes for anything beyond a single local bot. DEX trading needs Gateway. Agent control, the MCP server, or orchestrating more than one bot needs the Hummingbot API. Neither is in this repository, and each is its own deployment.

Alternatives

Freqtrade is the closer comparison for anyone whose strategy is directional rather than passive: it downloads and stores candles itself, charges the venue's real maker and taker fee in a backtest, and pulls mark and funding-rate candles in futures mode, all of which Hummingbot's engine does not do. It has no market-making strategy and no DEX middleware.

NautilusTrader is where to look if the simulator matters more than the connector list — an event-driven engine built to run the same code in backtest and live, with an order-book-level fill model. It costs more to learn and gives you fewer venues out of the box.

If what you want is a bot to configure rather than a framework to write in, OctoBot is the same category with a graphical interface, a constant-rate funding model and far less of the market-making machinery.