Hummingbot Connector

Hummingbot Connector makes your platform a venue that Hummingbot can trade on. It ships two halves: a connector package that goes inside a Hummingbot checkout, and the server side that authenticates it — HMAC-signed API keys, a Binance-shaped REST surface at /api/hb/…, a multiplexed WebSocket stream, and an admin section for oversight and control.

It is a bridge, not an engine. It owns no order book. Spot flow is forwarded to the Ecosystem matching engine and perpetual flow to the Futures engine, so every order a bot places is an ordinary order on your own book, in your own tables, settling through your own wallets.

What it requires

Requirement	Why
Bicrypto core	API keys, the audit trail, KYC gates, permissions, the settings cache
Ecosystem addon	Spot markets, order book, trades and the spot order path
At least one active ecosystem market	A bot pointed at an unlisted pair connects and then waits forever
Futures addon	Perpetual contracts, positions, funding and leverage. Optional
Redis	Nonce replay protection, rate-limit counters, agent presence and command relay
Hummingbot v2 from source, in a conda environment	On whichever machine runs the bot — yours or a customer's

Two ways to run bots, at the same time

Your users run their own. They install the connector kit into their own Hummingbot on their own hardware, mint an API key here, and point it at your exchange. You host nothing: their orders arrive as signed REST calls. The bot console shows them exactly what their bot is doing on your book, because those are rows you were already storing.

You run your own on the server. Admin → Hummingbot → Bot Instances runs Hummingbot on the platform box itself and supervises it — start, stop, restart, diagnose and read logs from the browser, no terminal. That is for your own market making. It is not a hosting feature for users: one process costs roughly 400–700 MB for a single-pair market maker, and up to about 1.2 GB for XEMM, on the same host as your database.

What a strategy is here

Hummingbot has two strategy systems and this product uses the newer one. A Strategy V2 controller is configured by a YAML file in conf/controllers/ and started through a script config that names it. The V1 create wizard will never list bicrypto_pmm, and reinstalling does not change that.

Two families ship:

Family	Controller	What it does
pmm	bicrypto_pmm	Pure market making — quote a ladder on both sides of your own book and earn the spread. Spot or perpetual
xemm	xemm_multiple_levels	Cross-exchange market making — quote on your book, hedge each fill on a deeper external venue

Presets are authored in the Strategy Studio, stored as parameters rather than files, and rendered to YAML on demand. A preset describes behaviour — spread ladder, refresh cadence, risk barriers — not a market; the market is chosen per deployment. Six presets are seeded and published on install.

Where things live

Which wallet a bot trades

A bot trades the wallet its market type belongs to, and nothing else.

Connector	Wallet type	Shown to the user as
bicrypto (spot)	ECO	Funding
bicrypto_perpetual	FUTURES	Futures

An empty balance with no error message is almost always funds sitting in the wrong wallet. Hummingbot hides balance-fetch errors — a failed read renders as an empty list, not a message — so this is the single most common support ticket the product generates.

How a request is authenticated

Every bot-facing call is signed. The bot sends X-API-Key, X-Timestamp, X-Nonce and X-Signature, where the signature is HMAC-SHA256(secret, "METHOD\npath\ntimestamp\nnonce\nbody"). A timestamp more than 10 seconds from the exchange's own clock is refused, a nonce cannot be reused, and the signature is verified before the key's expiry, disabled and IP checks — so someone who merely knows a public key string cannot probe its state or drive audit writes.

Keys carry explicit scopes. hb:read:* scopes are read-only; everything else changes state, which is exactly what read-only mode blocks. One scope, hb:control:bot, is deliberately outside every trading preset because it acts on the customer's machine, not on your exchange.

Start here