Hummingbot: The Market-Making Framework for DEX and CEX

Hummingbot is an open-source Python framework that turns any exchange's API into market-making, arbitrage, and liquidity strategies. It connects both centralised exchanges and DeFi venues, letting a trader run the same strategy across CEX and DEX order books from a single codebase. Version-controlled, config-driven, and free to fork, Hummingbot is the serious autotrader's scaffold rather than a click-and-pray bot.

What Market-Making in Hummingbot Actually Does

A market-maker quotes bids below mid-price and asks above it, earning the spread every time a limit order fills, while inventory risk accumulates. Hummingbot's pure market-making strategy places orders at a configurable spread around the mid; its cross-exchange market-making strategy routes the flow across venues to capture the price difference. The framework also ships starter strategies for liquidity provision on automated market makers (AMMs), where the bot acts as a forced counterparty.

Configuring Your First Strategy

controller_config = {
    "markets": [{"markets": {"kucoin_spot": ["BTC-USDT"]}}],
    "trade_type": "SPREAD",
    "spread": 0.01
}

Every strategy starts with a config file: spread, order amounts, cancellation and refresh intervals, and the price source. Hummingbot's dashboard (V2) lets you watch filled orders, inventory, and P&L in real time. The discipline, however, is in the config: a spread too narrow against a volatile pair turns market-making into inventory accumulation with a smile.

The Risks Woven Into Market-Making Strategy

  • Adverse selection: your quotes get filled exactly when the market is about to move against you - the core mortal danger of market-making
  • Inventory drift: holding a skewed inventory during a big move erases weeks of spreads
  • Exchange/API failure: a dead connection with open quotes leaves you exposed; Hummingbot's kill-switch and exchange health checks exist for this reason
  • Fees and gas: DEX strategies pay gas per order and per cancel - the cost model must be part of the tick, not an afterthought

Paper Trading and Backtest First

Hummingbot ships a paper-trading mode where the engine simulates fills against live market data. Run every market-making idea there for a week across a downtrend, an uptrend, and sideways chop. Only the configuration that survives paper in all three regimes deserves a real API key.

Bottom Line

Hummingbot is the professional's framework for CEX/DEX market-making: config-driven, open source, and equally at home with order-book or AMM venues. But market-making is a skill, not an install - spread selection, inventory discipline, and adverse-selection awareness decide either the alphabets turn into income or the bot turns your balance into someone else's fill.

What is Market Making?

Market making means placing buy and sell orders to earn the spread. Hummingbot automates this process.

Why Hummingbot?

  • DEX Support: Uniswap, PancakeSwap, dYdX
  • CEX Support: Binance, KuCoin, Gate.io
  • Strategies: Pure market making, arbitrage, liquidity mining
  • Community: Active development and support

Installation

pip install hummingbot
hummingbot

Configuration

# Pure market making
strategy: pure_market_making
exchange: binance
trading_pair: BTC-USDT
spread: 0.001  # 0.1%
order_amount: 10

Risk Management

  • Stop loss: Exit if position exceeds threshold
  • Inventory limits: Max position size per asset
  • Volatility filter: Pause in extreme conditions

SEBI Disclaimer

Market making involves risk of loss. This article is for educational purposes only.

Spread and Order Size as a Function of Inventory

Hummingbot lets you tie your quote spread to your current inventory, which is the difference between a market-maker and a fancy limit-order placer. When inventory drifts toward the base asset, widen the ask relative to the bid to discourage more buying and encourage selling back to neutral; when inventory is stacked toward the quote side, do the inverse. The classic setting anchors both legs to a reference price and scales each side's spread by a fixed function of deviation. A maker that quotes both sides with a fixed spread coasts fine in a drifting market and loses its edge exactly when the book moves to one side.

The Three Inventory Regimes

  1. Neutral: evenly balanced, symmetric spreads, the happy mean-reversion machine.
  2. Skewed: heavy on one asset, asymmetric spreads push the book back home while collecting the spread twice.
  3. Dry: inventory hit the floor or ceiling; stop quoting unless the signal to rebalance clearly stands out.

Program the transition rules rather than tending the book by hand, because the fast-moving crypto market respects makers who decide their inventory policy before the move, not during it.

Liquidity Provider Incentives and Their Flags

Some venues pay makers a rebate for resting limit orders, which reshapes the entire profitability of a spread that used to cost the fee. Treat the rebate as real income in the maker's models but measure it in the aggregate first: many rebate programmes pay at tiered rates based on a 30-day volume and change terms quarterly. Keep the fee tier and the effective spread in the same spreadsheet cell, because a maker whose edge collapses when the venue reprices its rebate table is a maker who was trading the venue's marketing, not the market.

Connecting Hummingbot to Indian-INR Pairs

Indian crypto traders often connect Hummingbot to a global venue with deep liquidity and settle through a corridor, or run against INR pairs on local venues whose depth is too thin for a worthwhile spread. Read the liquidity profile before choosing: if the entire book at one level is 50,000 rupees, a maker quoting 20,000-rupee orders is the whole liquidity pool, which is a different risk than quoting inside a deep book. The practical answer for most Indian users is to run the bot on a liquid major pair and hold the INR exposure off-chain, rather than wedging naive spreads into a thin local pair.

Backtesting a Maker Strategy Honestly

Maker strategies are the hardest to backtest because fills depend on the order book the simulator cannot fully replay. Use Hummingbot's paper-trading mode to capture live order-book behaviour without committing capital, then walk the parameters across a month of sessions. The honest test compares the bot's captured fill rate and adverse selection to a simple benchmark of "always crossed the spread" fills. If the maker strategy does not beat that naive benchmark after fees, the spread was just a more expensive way to take liquidity.

  1. Bind spread policy to inventory state, not to a fixed quote.
  2. Program the three-regime transition rules before funding.
  3. Count venue rebates in the model and re-check tiers quarterly.
  4. Choose liquid major pairs for the bot; keep INR off-chain.
  5. Validate the maker vs the crossed benchmark after every refactor.

Connector Persistence and Health Checks

Hummingbot's strength is the connector catalogue, and its weakness is the config that silently moves: persist each venue's connector settings - API keys, order-type defaults, spread bounds - in versioned files, and treat any drift between the config and the bot's live orders as an incident, not a footnote. Add the health checks that matter: the websocket heartbeat, the bid-ask distance from the reference price, and the count of resting orders against the strategy's expectation. A market-making session that quietly pushes its own spread outward while the config says "tight" is a session giving liquidity away without the ledger noticing. The runtime dashboard - resting orders, inventory, spread deviation, and fills - is the maker's post-mortem prevention kit, and its absence is why "the bot made money last month" is always a past-tense sentence.