Hummingbot Connector v6.0.3

Release Date: July 30, 2026 Tags: CRITICAL FIXES, ORDER PLACEMENT, PERPETUALS, RATE LIMITS, API KEYS, SECURITY, CONNECTOR, INSTALLER, BOT CONSOLE, BOT INSTANCES, LOCAL AGENT, CONNECTOR KIT, SETUP, STRATEGY PRESETS, KYC, WINDOWS

Overview

Version 6.0.3 fixes order placement, which was failing 100% of the time, and order cancellation and lookup, which returned "not found" for every request. Between them these made the connector unusable for trading. On current Hummingbot releases the connector could not even be created, and its order book never populated on spot or perpetual, so a strategy had no prices to quote against.

It also adds an operator-hosted bot panel. Admin -> Hummingbot -> Bot Instances runs Hummingbot on the server itself: register an install, start, stop, restart, diagnose and read its logs from the browser, with no terminal session.

And it completes the customer side, which was never usable end to end before this release — a downloadable connector kit, a Connect your bot page that reports whether a bot is actually reaching the exchange, a live bot console with a one-press emergency stop, and an optional local agent that drives a bot on the customer's own machine over an outbound-only link.

Requires Core v6.5.8 or later.

Update Instructions

pnpm updator

Then reinstall the connector into your Hummingbot checkout:

python hummingbot/install_connectors.py /path/to/hummingbot

No database migration is required. If you run the operator-hosted instance panel, restart the backend so the reconciler picks up the new build.

Upgrade Notes

Breaking Changes

None.

Added

Operator-hosted bot instances

A new Admin -> Hummingbot -> Bot Instances screen runs Hummingbot on the server itself. An operator registers an install, points it at a strategy preset, and then starts, stops, restarts, diagnoses and tails the logs of that bot from the browser. No terminal, no SSH session, no shell access to the machine. Nothing like this existed before.

• Supervised, not launched: the screen records what you want the bot to be doing; a background supervisor converges the real process to it. Start and stop are safe to press twice, and a request that times out mid-start still lands on one outcome rather than two bots.
• Survives a deploy: a bot you asked to run comes back after a backend restart instead of staying silently dead, and a process that outlived the restart is re-adopted rather than started a second time alongside itself.
• Restarts a crash, gives up on a loop: a bot that dies is restarted after 5 seconds, doubling to a ceiling of 5 minutes; ten minutes of healthy uptime resets it. A bot that can never stay up stops consuming the host.
• Memory ceiling: each instance carries a memory limit. A bot over it is killed and the reason is recorded on the card.
• One owner: exactly one supervisor is active even when the backend runs across several processes, so a bot is never started twice against the same account — two market makers quoting the same book, each unaware of the other's inventory, is the failure this prevents.
• Live logs: the process output is streamed to the panel, per run.
• Applies to the memory ceiling is enforced on Linux hosts.

Bot console: a live trading terminal for a bot you run yourself

Customers who run Hummingbot on their own machine now get a full-viewport terminal at /hb/console, showing what that bot is doing on this exchange without sitting at the machine it runs on.

• What it shows: resting quotes on both sides with the distance from the touch, fills as they land, inventory skew, open positions, a per-market rail, and a health verdict for the bot as a whole. It updates live.
• Nothing is inferred: every order the bot places is already recorded here, because the bot placed it through this exchange. The console is a read-back of state the platform was storing anyway — it does not host the strategy, run the bot, or hold its logs.
• Cheap at scale: order book reads are shared across everyone watching the same market for a fraction of a tick, so two hundred people watching one pair cost roughly what one person costs.
• Emergency stop is built into it — see below.

Local agent: drive your own bot from the web panel

An optional agent runs alongside a customer's own Hummingbot and lets them start it, stop it, change its configuration, import a strategy, set balance limits, switch paper trading, and read status and history — from the exchange's own page, on a bot running in their house.

• Outbound only: the agent dials the exchange. There is no inbound port to open, no SSH, and the platform never holds a credential for the customer's machine. The link is authenticated with a key the customer minted and can revoke.
• Control is a separate permission: driving a bot requires a Bot Control permission that is deliberately excluded from every trading preset. A key minted to let a bot trade cannot drive it.
• Only known commands cross the link: the set of commands is enumerated on the server. Nothing that names a file, a path or a shell command is accepted.
• Self-contained: the agent ships with its own message broker, so there is nothing else to install, plus a self-test, an end-to-end test and its own documentation. It comes inside the connector kit download.

Download the connector for your own Hummingbot

Until now the connector existed only on the server. A customer who followed the documented flow typed connect bicrypto and was told it was not a valid connector — and Hummingbot's connector discovery swallows the underlying import failure, so nothing was logged to explain why. The documented flow had a hole in the middle.

The Connect your bot page now offers the connector kit as a zip: both connector packages (spot and perpetual), the installer that places them into a checkout safely, the controller examples, the local agent, and the kit's own docs. Two small account-check scripts ship with it.

• Contains nothing account-specific: no API key, no secret, no exchange address. The zip is identical for every user; those values belong in connect bicrypto, not in a file thousands of people download.

Guided registration: environment check, install detection and one-click provisioning

Registering a server-run bot is a review-and-confirm step with paths already filled in, rather than typing two absolute paths from memory.

• Detect: the panel scans a bounded set of locations for existing Hummingbot checkouts and Python environments and offers what it finds. A candidate that would land on the connector kit shipped with the platform is rejected rather than offered.
• Provision: it can create the target directory and fetch Hummingbot's source into it. It refuses filesystem roots, the platform's own directory and public web roots, and requires roughly 2 GB free. It then prints the exact remaining build command — ./install, activate the environment, then ./compile — instead of pretending to run a ten-minute compile inside a web request.
• Diagnose: a button that names a misconfigured environment before the bot is started, checking the interpreter, the directories, free disk and the options the install's own launcher actually supports. Each check reports pass, warn or fail with the fix.

Server-run bots are configured to trade without an interactive prompt

A bot registered in the panel is made ready to trade without an operator typing connect bicrypto at a prompt.

• Mint a key from the form: a scoped API key can be created while registering the instance, with spot or perpetual trading permissions and owned by the operator creating it. The secret is stored and injected into the bot; it is never returned to the browser.
• Config password: Hummingbot's one-time config-password step only exists on its interactive path, so it is performed before launch. An existing one is never overwritten — replacing it would make every connector key already saved in that install permanently undecryptable.
• Connector credentials: written into the install's own connector configuration, with the field names read from the connector itself rather than assumed.
• Encrypted at rest: the stored config password is encrypted with a key derived from the platform's own application secret, separate from the ecosystem wallet vault.
• Reinstall from the panel: the shipped connector installer can be run into the checkout from the instance screen, including the repair option that wipes the target directories first.

A dead bot says why, and an unlisted market is refused before the bot hangs

• Why it died: when a supervised bot exits, the panel names a probable cause and the next action instead of showing "exited with code 1". Known Hummingbot failures are matched by name — no saved keys for the connector, a missing interpreter, a configuration it would not accept — each with the fix. Pure consequence lines such as "Exiting." are never reported as the cause, which is what made "read the logs" mean "read past four lines of noise".
• The market has to exist: registering or starting an instance whose strategy quotes a pair the exchange does not list is now refused, with the pairs that do exist. Previously this produced the worst kind of failure — a completely successful start. The connector was created, the process stayed alive, the panel showed RUNNING, and the bot logged "bicrypto is not ready. Please wait..." forever without ever quoting, because its book never arrived.
• A market picker replaces the free-text pair field on the instance form.

Windows: provision into WSL, and the launcher starts at all

• Provision into WSL: on a Windows server the panel can install Hummingbot into a WSL distribution, instead of failing on a build that only runs under bash. The source is still fetched on the host either way, so a shell can build it in place.
• The launcher now starts on Windows: Hummingbot's launcher relies on two Unix-only Python components and died on Windows before anything else could happen. Small stand-ins are now supplied to the interpreter, on Windows only.
• VMware guests are detected: running virtual machines are listed on the registration screen so an operator can see that a Linux guest is available.

Customer-facing emergency stop

A customer whose bot is misbehaving can stop it from a browser session, without access to the machine the bot runs on. It lives on the bot console.

• Order of operations is the whole feature: the keys are switched off first, which makes the next request the bot signs be refused, and only then are resting orders cancelled. Cancelling first accomplishes nothing visible — a market maker re-quotes within a second and the customer watches their cancel undo itself.
• It never launders an operator block: the disable is stamped as the customer's own, so an operator's block stays a block, and re-enabling is the customer's own decision from the API Keys page.
• It says what it did: the reply states plainly that the cancellation is account-wide and includes orders placed by hand, not just the bot's.
• Reversible: re-enable the key from the API Keys page. Either half — disabling keys, cancelling orders — can be run on its own; both are on by default.

Connect your bot: a setup page that reflects your real account state

A new Connect your bot page walks a customer through pointing their own Hummingbot at this exchange, using their actual account state rather than generic copy.

• The right address for this install: derived from the incoming request, so it is correct behind a proxy and on a custom domain.
• The step you are actually on: computed from your keys — none, one you can use, one whose secret was never kept, or one that has been switched off. Someone whose keys were just switched off by the emergency stop is told to re-enable them, rather than to create a new key, which would have left the old ones dead and the bot still stopped.
• Is my bot talking to you at all: a plain verdict — never connected, connected, currently being refused, or silent — because a customer cannot connect a bot from a web page, and detecting the link is the only truthful thing the page can do.
• No secret is ever returned: a secret is shown once, at creation, and this page is polled.

Connector

• Added last-traded-price lookup, required by the order book tracker when no fresh public trade has arrived. A pair that fails is skipped rather than failing the whole batch.
• Added live subscribe and unsubscribe for individual trading pairs, which Hummingbot v2 needs to add and remove pairs on a running connection instead of reconnecting. Implemented for both spot and perpetual.

Installer

The connector installer has been substantially rewritten.

• Added a --doctor mode — a read-only check that diagnoses why connect bicrypto is not appearing. It checks your Python interpreter, the target directories, compares files against the shipped kit, and verifies the import exactly the way Hummingbot's own discovery does.
• Added --clean, which wipes target directories before copying.
• Added direct detection of the common failure modes: an accidental nested copy, directories readable but not enterable, case-variant folder names, leftover files from older versions, locally modified files, and pointing the installer one level too deep or too shallow.

Changed

Hummingbot pages are behind the platform's per-feature verification gate

• What changed: a new Hummingbot Connector entry was added to the platform's per-feature KYC list, and applied to the strategy presets, the strategy download, the connector kit download, the setup guide and the bot console — on the server and in the pages themselves. On an install with per-feature KYC enforcement switched on, unverified users now see a verification notice on those screens instead of the content. This is a new access restriction; review it before updating if your users are unverified by default.

/hb is now a landing page and the API keys screen moved to /hb/keys

An existing bookmark or link to /hb now reaches an explanatory landing page rather than the list of API keys. The key manager lives at /hb/keys and is still the API Keys entry in the section nav.

• Also: the customer nav gained Home, Connect your bot and Bot console entries.
• Also: the site header and footer are suppressed on the bot console so the terminal can fill the viewport.

Installer

• Changed handling of newer Hummingbot layouts that need no edits at all.
• Changed the setup, troubleshooting and installation docs to match.

Smaller changes

• Changed perpetual orders to check leverage against what the market actually offers. An operator now reads leverage 7x is not offered on BTC-USDT. Available: 1, 5, 10 instead of an opaque rejection on every order. A maximum-quantity check was added alongside the existing minimum.
• Changed order book snapshots to return what exists instead of failing. Asking for more depth than the market has now returns the available levels rather than an error that would leave the bot's initial book empty.
• Changed the connector's admin and customer screens onto the platform's shared colours, stat cards and status badges instead of their own green identity, so they match the rest of the installation in both light and dark themes. Purely visual; no behaviour changed.

Fixed

The connector could not be created at all on current Hummingbot releases

On a recent Hummingbot release, connect, balance, the trading-pair fetch and starting a strategy all failed immediately — the connector was unusable.

• Hummingbot builds a connector by handing it a fixed set of values. The connector still expected one that Hummingbot had removed, and did not accept the two that replaced it, so it could not be built at all.
• Fixed on both spot and perpetual, which now match what current Hummingbot releases pass, including the balance limit and rate-limit share values, and both accept values they do not recognise — so a future Hummingbot release degrades rather than refusing to start.

Every order was rejected

Placing an order failed with " must be a object." on every attempt.

• Fixed so orders now place correctly. Request signing is unaffected.

Every cancel and order lookup returned "not found"

Cancellation, order status and order updates all failed on both spot and perpetual. Hummingbot cancels exclusively by order id, so this broke the strategy loop outright.

• Fixed so every lookup by order id now works.

Bulk cancellation left orders live while reporting them cancelled

The operator kill switch and the cancel-everything action both recorded orders as cancelled while leaving them in the matching queue, still fillable. An operator pressing stop was shown a successful cancellation on orders that were still working the book.

• The same identifier-comparison defect behind "Every cancel and order lookup returned 'not found'" above, on the bulk paths. On ecosystem markets an order's identifier is not held as plain text, and the raw value was passed straight through, so nothing ever matched — but the cancellation was written down anyway. That made the kill switch itself a source of ghost orders.
• Fixed on both paths, which now match the order and cancel it for real.

The order book never populated, on spot and perpetual

Every snapshot and trade arriving on the live market-data connection died with "Unexpected error when processing public order book snapshots", so the book stayed empty. A strategy had no prices to quote against and simply never traded — on spot and on perpetuals.

• The two steps Hummingbot's book tracker uses to hand a live message to the book were never implemented, and Hummingbot refuses them outright when they are missing.
• Fixed on spot and perpetual, and messages reach the book.

The exchange address you entered was discarded

The address typed at connect bicrypto never reached the connector. Every request the framework itself made — connect, balance, the trading-pair fetch — went to the compiled-in default instead of the operator's own exchange, with no error to explain it. Together with the removal of that default host below, this is why a correctly configured connector could still be talking to a different server.

• Hummingbot hands the connector only the fields marked as connection settings. The exchange address field on both the spot and perpetual configurations was not marked, so it was filtered out before the connector was ever built.
• Fixed so the address is carried through on both, and neither falls back to a default any more.

Every leveraged perpetual order opened at a fraction of its intended size

A bot asking for 1 contract at 20× leverage opened a position of 0.05. At 5× it opened 0.2. Spot was unaffected.

• Why nobody noticed: the response echoed the shrunken size back, so Hummingbot's own reconciliation agreed and never raised a discrepancy. A market maker simply quoted sizes it was not actually showing, and its inventory tracking diverged from reality from the first fill onward.
• The futures engine used to inflate forwarded amounts by the leverage, so this connector divided by the same factor to compensate. When futures was corrected to implement isolated margin properly, the inflation went away and the compensating division here did not.
• Fixed so the quantity a bot asks for is the quantity that is opened.

Orders with a quantity of exactly 1 or 0 were silently rejected

• Fixed in Core v6.5.8 — a quantity of exactly 1 or 0 was being misread as a yes/no value before the order was placed.

Per-key rate-limit overrides never took effect

On MariaDB installs, an operator who throttled a misbehaving bot watched it keep hammering at the default budget, and an operator who raised a budget for a market-data-heavy bot watched it keep being rate-limited. The admin panel reported success and stored the value correctly; nothing ever applied it.

• Fixed so overrides now apply everywhere. A malformed value falls back to "no override" — the addon default applies, never an unlimited budget.
• Same underlying cause as the IP allowlist defect below.

The customer-facing pages could not show their own error messages

Worst at the emergency stop. A failure there — an expired session, the operator's kill switch, a missing engine addon — arrived in a form the page could not read, so the customer saw a generic "request failed" while their bot's actual state was unclear. The same applied to the setup page, the bot console and the connector download.

• This addon deliberately speaks two different dialects — one that Hummingbot's parsers expect, and one that browsers expect. The four newest customer-facing pages had inherited the bot dialect.
• Fixed so the setup page, the bot console, the emergency stop and the connector download now all report errors in a form the browser can display.

The connector shipped with a third-party host as its default address

The connector had a live demo hostname (starflux.net) compiled in as its default exchange address. Hummingbot rebuilds a connector from its template configuration on every startup, and that instance never sees saved credentials — so every install was quietly dialling that host on each launch, regardless of what the operator had configured. It also made a genuine misconfiguration unreadable: the error named a domain the operator had never typed.

• Fixed so there is no default. The connector now refuses with "Bicrypto base URL is not configured. Run 'connect bicrypto'..." instead of falling back, and the trading-pair fetch that runs at startup returns an empty symbol list rather than reaching out to anything.
• Applies to spot and perpetual. The perpetual package inherited the same default and is covered by the same change.

IP allowlist degraded into a partial match

On MariaDB installs, the IP allowlist check ran against text rather than a list — so a partial IP address could satisfy it.

• Fixed so allowlists and permission lists are now read correctly everywhere, on the server and on both the admin and user key screens. Malformed data falls back to an empty list, which for a permission list is the safe reading.
• Fixed the same defect blanking the API key screens on affected installs, and making permission checks match nothing at all.

Downloaded strategy presets could never start

Every strategy preset this platform generated was missing an identifier that Hummingbot's controller configuration requires and declares with no default, so a preset failed validation before the bot ever reached an exchange. The instructions printed at the top of the file were wrong too — they described a single start command that does not work for a v2 controller.

• Fixed so generated presets now carry an identifier, taken from the preset's own name or the filename, and restricted to safe characters. The header now gives the correct two-file flow — the controller configuration, a script configuration that points at Hummingbot's stock v2 runner, then start --v2 — instead of a command that could not work.
• Fixed the five bundled example controllers and the strategy guide the same way.

Listing your orders returned only the closed ones

Asking for your orders on a symbol returned everything except the live ones — so a bot would reasonably conclude its book was empty and re-quote on top of its own resting orders. It now returns everything, newest first. Anything already asking explicitly for open or closed orders is unaffected.

A key could be created but never rotated

On an install with platform KYC enabled and this addon's own KYC requirement left at its default of OFF, users could create a Hummingbot key and then be refused when trying to rotate its secret or edit its permissions. Rotation is the recovery path for a leaked secret.

• Two different implementations of one policy. Key creation used the operator's configured setting; rotation and permission changes used an older rule that hard-coded "KYC level 2 whenever platform KYC is on" and ignored what the operator had configured.
• Fixed so all three now follow the same rule.

"Your bot is connected" during an emergency stop

The connection status compared the last successful request against the most recent rejection — and both are recorded to the nearest second. A bot polls several times a second, so the exact situation this status exists to describe (last success moments before the block, everything since refused) normally landed both in the same second, and the tie went to the success. The customer was told "your bot is talking to us and just isn't placing orders; check your strategy" — while their keys were switched off. A tie now resolves to the rejection.

A wrong clock on the bot's machine now says so, and the rejection is recorded

Clock drift on the machine running the bot is one of the few things that stops an otherwise-correct connector, and it was the only one that left no trace on the exchange side. The check ran before the key had been identified, so the bot logged a refusal locally, the exchange had no record of it against that key, and the customer was sent off to reinstall a connector that was fine.

• Fixed so the rejection is now recorded against the key, and the message names the direction and size of the drift and the fix — "this machine's clock is 12400ms ahead of the exchange, limit 10000ms. Sync the clock on the machine running the bot." Being ahead is the case people do not expect, so the direction is stated rather than an absolute difference.

Local-agent commands could be dropped

Two defects, both of which appeared as a bot ignoring a command for twenty seconds and then timing out. Commands issued from the browser could be discarded before reaching the bot, or the bot's reply could be published where nothing was listening. Both are fixed.

The market-data connection answered only one keepalive style

A client using the other keepalive convention would tear down a healthy connection on every ping and reconnect forever. Both styles are now answered.

A missing spot or futures addon flooded the server log every second

On a server without the ecosystem or futures addon, two background feeds wrote a full stack trace per subscribed user per second into the process log, and retried the same unavailable feed on every tick. On an install with any number of connected users this was the loudest thing in the log.

• Both feeds already had graceful handling for a missing addon, and it could never run — the failure happened earlier, in a form that handling never saw.
• Fixed so the unavailable addon is now reported in a form the existing handling can act on, and both feeds check once whether the addon is present and skip the work quietly, including the positions read that only exists with futures installed.

Connector

• Fixed a request-signing detail that could produce a request the backend refuses.

Admin

• Fixed inconsistent handling of malformed permission data across four screens in the Hummingbot key filter.