Hummingbot Connector v6.2.1

Release Date: September 21, 2026 Tags: ACCOUNTS, ORDERS, SECURITY, SHUTDOWN, CANCELLATION

Overview

A bot could trade on an account nobody chose for it. Hummingbot signs every order with the key sitting in its checkout's connector config, and the platform books that order against that key's owner — their wallet funds it, their balance is held, and only they can cancel it. Nothing ever read that file back, so an install still carrying someone else's key from a hand-run connect ran every bot as that account, for ever, while the instance row, the panel, the stop-time order sweep and the emergency stop all watched a different one. Observed on a staging box: an admin's market maker quoted on a customer's account for five minutes and locked 202 USDT and 0.0024 BTC of their balance. The orders only cleared when the customer cancelled them from their own panel.

Four more ways a bot's identity or its orders went missing are closed with it, and a Redis gap during a stop no longer cancels the operator's own hand-placed orders.

Read Upgrade Notes before updating: a start can now be refused, and the first reconcile after the update will cancel resting orders.

Requires Core v6.7.8.

Update Instructions

pnpm updator

There is no schema change, no setting to configure, and no connector redeploy. KIT_VERSION is unchanged at 2026.09.12.1 — everything in this release is on the platform side, so a bot already running the current kit needs nothing but the backend restart.

Upgrade Notes

A start is now refused when the install holds another account's key

Every admin-side view of a bot reads the owner of the API key the instance is linked to. The orders are placed, funded and held against the owner of the key actually in the checkout. While those disagree the bot's orders are both invisible and unreachable from the admin side, and no later step recovers that without the other account holder acting themselves.

• Fixed by identifying the credential already in the install at start time and refusing when it provably belongs to a different account. The refusal names both accounts and what to do about it.
• To resolve one, either link the key the install already holds to that instance, or delete conf/connectors/<connector>.yml and start again so it is rewritten from the linked key. The platform still never overwrites a connector config it did not write.
• This is not a bulk audit. It runs at start, one instance at a time, so an install you never restart is never checked. If you have ever run connect by hand in a checkout the panel also drives, restart those instances deliberately rather than waiting to find out.
• The check needs the instance's config password, because the credential store is encrypted with it. An instance without one is neither provisioned nor identified — that is unchanged and still allowed, but the instance log now says so at every start instead of skipping the step silently.
• A key belonging to the same account does not refuse, and neither does anything inconclusive — an unreadable config, a missing field, no linked key. Those log what could not be confirmed and let the start proceed, because an uncertain check must not take a working bot offline.

The first reconcile after updating will cancel resting orders

A bot that died while the backend was down was never swept: the check for a dead process read a pid held only in memory, which a backend restart clears, so the row sat at RUNNING for ever and the one routine that cancels a dead bot's resting orders never ran. Those rows are still sitting there.

• Fixed by falling back to the pid recorded on the row, which survives a backend restart.
• On the first reconcile after you update, any instance in that state is marked exited and its resting orders are cancelled. That is the cleanup that should have happened when it died, but it may be the first time in a while that a market's quotes disappear at once. Expect it, and check the affected markets afterwards.

Two instances cannot share one Hummingbot checkout

Almost everything the panel writes into a checkout is per instance. The three files that decide identity are not — the connector credentials, the fingerprint of what was last written, and the config password seal are all per install. Two instances pointed at one checkout therefore fight over a single credential file: each start calls the other's fingerprint stale and rewrites it, and because Hummingbot reads credentials once at process start, whichever bot is already running keeps an identity the file no longer names.

• Changed — creating or moving an instance onto an install path another instance already uses is refused, naming the other instance.
• Installs that are already shared keep starting. They are misconfigured rather than broken, and taking a live bot offline to enforce a rule it predates is the more expensive mistake. Give each instance its own copy of Hummingbot when you next have a window.

Fixed

Re-selecting an instance's API key and restarting did nothing

• Fixed the start path, which returned before it ever read the instance's linked key whenever the checkout held a connector config the panel had not written. Choosing a different key in the panel and restarting therefore changed nothing at all, with no indication that the choice had been ignored.

A stop that swept the wrong account looked exactly like a clean one

• Fixed the exit sweep, which returned before logging anything when it cancelled nothing. "The book was clean" and "I swept an account with none of this bot's orders on it" produced the identical log — none — so a stop that stranded every order the bot had placed read as a tidy shutdown. It now records the outcome either way.

An instance with no config password ran on whatever key was in the checkout

• Fixed the silence around it. The whole credential step sits behind the config password, so an instance registered without one is spawned with its credentials neither written nor checked, and trades with whatever key is already in the checkout. It is not refused — those instances work today and a password is not always available — but the instance log now names the risk instead of skipping the step without a word.

A Redis blip during a bot stop cancelled orders the bot never placed

• Fixed the way a stop decides which resting orders belong to the bot. It asked a short-lived cache, and when that could not be read it answered "unknown" — which both callers widen into cancel everything on this market for this account. So a momentary Redis gap during a stop did not merely fail to narrow the sweep: it destroyed the operator's own hand-placed orders, in order to avoid leaving a dead market maker's quotes resting.
• Changed the fallback to read the durable client order id carried on the order rows themselves, which only the signed Hummingbot doors ever write. A Redis outage is exactly when those rows stay trustworthy, because a bot quoting straight through one still stamps every order it creates. The cache still wins whenever it can be read.
• The sweep still widens when no open order carries one, which is the case on an install whose open orders all predate that column. The remaining risk runs the other way — a pre-column bot order left resting — and that already happened on every stop where the cache was readable, so the two cases now behave the same.