Hummingbot Connector v6.1.1

Release Date: August 19, 2026 Tags: CRITICAL FIXES, ORDERS, MARKET MAKING, CONNECTOR, PERFORMANCE, BOT CONSOLE, STREAMS

Overview

v6.0.8 fixed a cancel that was given up on. This fixes the one that was never sent — and three other ways a bot could stop trading without saying so.

A market maker re-prices every second: it places an order and, if the edge has moved, writes it off about a second later. When placement took longer than that to answer, the cancel arrived before the exchange had returned an order id — and the connector silently dropped it. Then the placement succeeded.

The result is an order resting on the book that nothing is tracking. It holds your funds, so the next quote is refused for insufficient balance; it trips the self-match guard, so the opposite side is refused too. Measured on a live install: 61 orphaned orders in a 50-second run, 127 consecutive submission failures, and an account whose entire free balance had become orders the bot believed it had cancelled. On shutdown the bot reported cancelled 0 open orders — truthfully, because it no longer knew about any of them.

Placement was slow for a reason, and that is fixed too: every order was reading the account's entire history on that pair out of storage and converting it number by number, on the same thread serving its cancels. The longer a bot ran, the slower it got — from milliseconds to three to seven seconds on a 7,200-order history.

Two further faults could each stop a bot outright, and neither said so plainly: a drifting clock on the bot's own machine silently made every signed request invalid, and the order book accumulated phantom price levels that no order was behind.

Alongside those: the bot console no longer reports an empty book for a market that plainly has one, prices are quantised to the market's tick, and a failed cancel now tells you the order is still live instead of quietly moving on.

This release requires a connector reinstall and a bot restart. The platform and the connector kit are two halves of the same fixes and neither works without the other. Requires Core v6.6.9.

Update Instructions

Read this section through before starting. The steps are ordered, and two of them are easy to skip with no visible error and no benefit.

Before you start

Stop your bots, and stop them properly. Use Stop on the instance card, or stop inside Hummingbot — not a kill, which skips the bot's own cancel-on-exit.

Then check the bot console (/hb/console) or your orders page: nothing should be resting. Anything still there was orphaned by an earlier version and will not be retracted by updating. Cancel it now, while you can still see what it is.

1. Update the platform

pnpm updator

2. Clear phantom book levels

Only needed if your market has them. The tell is depth that never trades, or a spread that will not close.

From backend/:

node scripts/rebuild-eco-orderbook.mjs                   # dry run, all symbols
node scripts/rebuild-eco-orderbook.mjs BTC/USDT          # dry run, one market
node scripts/rebuild-eco-orderbook.mjs BTC/USDT --execute

Run the dry form first and read what it says. It touches no orders, no trades and no balances — only the aggregated depth.

3. Restart the backend

Required after step 2, and not optional: the matching engine holds the order book in memory and keeps serving its own copy until it restarts.

4. Fix the clock on the machine running the bot

Do this even if the bot has been working. Every signed request carries a timestamp and is refused if it is more than ten seconds out. A drifting host crosses that line silently, mid-session, and from that moment can neither place nor cancel anything — while the error it reports looks like an authentication problem.

sudo timedatectl set-ntp true
timedatectl status        # expect: System clock synchronized: yes

This release makes the connector survive drift rather than die of it. It does not make a wrong clock right.

5. Reinstall the connector — into every checkout you run a bot from

From your platform root (public_html), in the Hummingbot conda environment:

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

It copies over the existing files, so nothing needs deleting first. Your API credentials in conf/connectors/ and any preset you have edited are left alone.

If the installer reports that setup.py changed, run ./install && ./compile. Skip it otherwise — it takes minutes and changes nothing.

Do not skip this because you already did step 1. The order that never existed, in particular, is fixed on both sides at once: the platform now answers never created where it used to answer not found, and only the new connector recognises that as a final answer. An updated platform with an old connector keeps re-cancelling; an updated connector with an old platform still gets the old answer. Either half alone leaves the loop in place.

6. Restart the bot

Not optional, and the most commonly skipped step. Python loads the connector once, at process start. A bot that is already running keeps the old code in memory no matter what is on disk — so every fix above reaches you only here.

7. Confirm it took

cat /path/to/hummingbot/.bicrypto-kit-version     # expect: 2026.08.19

The bot also logs its kit version on startup, so the instance card shows it if you have no shell on that machine. Then watch for the first quote to appear in the console, usually within a second or two of the strategy starting.

No database migration.

Full guide: Updating the connector kit (hummingbot/docs/UPDATING.md) — which fixes reach you automatically, which need a reinstall, and how to tell which version a bot is running.

Upgrade Notes

Orders left behind by earlier versions are still open

Updating does not retract them — nothing on the platform side knows they were ever meant to be cancelled. Cancel anything resting that your bot is not tracking, on any account that has been refusing quotes for insufficient balance while holding funds.

From this release the connector tells you itself: it reads the account's open orders on its own stream and warns about any working order it is not tracking, naming the price and the id. Previously it discarded those rows without a word — every one of the 61 orphans appeared in every frame, once a second, for the whole run.

Phantom levels are not retracted by updating either

This release stops new ones forming. The ones already in your book need step 2 above, and step 3 after it.

depth@<symbol> has been removed from the market data stream

It was never a separate feed. It carried the same full snapshot as orderbook@<symbol> while being documented as diff updates, so a client subscribing to both paid twice for one book, and any diff-application logic written against it was working from snapshots. Nothing shipped by us ever subscribed to it — the connector uses orderbook@ and trades@.

• Removed the depth@<symbol> stream channel. Subscribing now returns the standard invalid-topic error. If you have written your own integration against it, move to orderbook@<symbol>; the payload is byte-identical.

Fixed

A cancel issued before placement answered was silently dropped

The connector refused to cancel an order whose exchange id it did not yet have, returning failure without sending anything. That is the normal state for about a second after every placement — and on a busy venue, for much longer. The strategy was told the cancel failed and moved on; the placement then succeeded, and the order rested with nobody watching it.

A cancel now waits for the placement to resolve and then cancels the real order. If the placement fails, nothing was created and there is nothing to cancel. If it is still running, the cancel falls back to the bot's own client order id, which the exchange now accepts.

• Fixed a cancel requested before an order's id arrived being abandoned, leaving the order live on the exchange and untracked.
• Added cancel and status by client order id, so an order can be addressed during the window before its exchange id is known.
• Fixed the connector reading order not found as order already cancelled. It is not the same statement: the first says the exchange could not identify the order, which can mean it is mid-placement or that an index has not caught up. Treating it as a completed cancel dropped live orders from tracking.
• Fixed cancelling an order whose placement had failed never stopping. The exchange forgot the id, answered not found, and the connector — correctly, since that says nothing about the order — kept trying. It now answers that order was never created, which ends it in one exchange.
• Fixed a status poll for an order with no exchange id reporting success, so such an order was pinned in tracking for the life of the process while the strategy kept counting its capital.
• Added adoption of an order whose placement failed ambiguously — a gateway error, a timeout. The connector asks whether the order exists and takes ownership if it does, instead of writing it off and orphaning it.
• Fixed a failed cancel quoting a fixed attempt count that was not the number of attempts actually made, so a refusal that is never retried — a wrong clock — read as a flaky venue. The line no longer names a count at all.
• Changed a client order id whose placement failed to be refused for two minutes rather than freed immediately. That window is what lets a later cancel be answered never created instead of not found; a bot that recycles its ids faster than that will be told the id is already in use. Applies to perpetual placements as well as spot.

A drifting clock on the bot's host silently stopped all trading

The connector read the exchange's clock once, at startup, and never again. A host whose clock drifted afterwards kept signing with a stale correction and, past ten seconds, could neither place nor cancel anything. A live run shows it appearing mid-session and growing from 10.0s to 13.0s, with every cancel failing from that point on.

Worse, /api/hb/time — the one call that would let a bot correct itself — shared its rate-limit allowance with market-data polling, so a busy bot could exhaust the budget and then be refused the very request that would let it sign again.

The refresh is on the spot connector. The perpetual connector was not given one, and that is worth knowing rather than glossing: a perpetual bot still depends on its host's clock being right, so step 4 of the Update Instructions is not optional for anyone running one.

• Fixed the clock correction being calculated once per session instead of refreshed. On the spot connector it now updates on the polling cycle — at least every thirty seconds — and on the refusal that means it has gone stale.
• Changed /api/hb/time and /api/hb/ping to a separate, much wider allowance. Refusing a clock read is a deadlock rather than a limit. That allowance is not one of the three budgets on the HB settings screen, so raising the read allowance no longer widens it — and no longer needs to.
• Added an extra unsigned server-time request from every spot bot, at least once every thirty seconds. It is the cheapest call the platform serves and it carries no data, but it is new traffic and you will see it in request counts. A read that fails now logs Could not read Bicrypto's server time to refresh the clock offset, keeps the previous correction and tries again.

Phantom price levels in the order book

Two causes, both leaving depth behind that no order was funding.

Re-adopting orders after a restart, or a hand-off between processes, added their sizes to the book a second time — the book is durable, so those orders were already counted in it. Cancelling then removed one copy and left the other: a phantom of exactly one order's size, at the price it was quoted. An audit of one live market found seventeen such levels against two genuinely open orders.

Separately, two cancels at the same price could each subtract from the same starting value, so one of the two was lost.

• Fixed re-adopted orders being added to the aggregated book again. Only a newly placed order now contributes to a price level.
• Fixed concurrent writes to a price level losing one another's updates.
• Fixed order prices not being rounded to the market's tick size. A strategy computing to 28 decimal places created a new price level per quote, so the book stopped aggregating and each cancel left dust behind.
• Fixed depth being credited with an order's original size rather than what is still resting, so re-adopting a partly-filled order overstated the book.

Placement got slower the longer a bot ran

Every order placement read the account's whole order history for that pair and converted seven values on each row before it would accept the order — tens of thousands of conversions to answer a question about a handful of resting quotes. Cancels paid the same cost, as did the two account data streams, twice a second each.

• Fixed order placement reading the account's entire order history per order. It now reads only what the check needs.
• Fixed cancel and order-status doing the same, including a status lookup that ran the identical query twice.
• Fixed the account streams reading unbounded history on every tick.
• Changed GET /api/hb/order to bound its read of finished orders at the query rather than after it. It always returned at most 500, but it fetched and converted the account's whole history on the pair to get them, on the same thread the matching engine runs on. Resting orders are still never capped. The bundled connector does not use this route — it is for integrations written against the API — and the one visible edge is that with finished orders requested, fewer than 500 can now come back when the newest rows on the pair are still resting.
• Fixed wallet lookup during placement running a full deposit-address reconciliation, twice per order — work unrelated to trading that could reach blockchain address generation on the order path.
• Changed the connector to throttle itself slightly below the exchange's budget rather than exactly at it, so it paces itself instead of being refused.
• Changed how long a refused cancel is retried, to match why it was refused. Waiting a minute is right for a rate-limit lockout and wrong for a condition that clears in seconds; applying one budget to both multiplied a bot's own request volume against the limit it was trying to survive.

Cancel-all missed orders, and a cancel could refund without cancelling

• Fixed cancel-all reading only the most recent page of history, silently leaving older open orders untouched — and the accounts most likely to cross that boundary are the ones with the largest holds. It now reports when a result is incomplete instead of implying success.
• Fixed a cancel releasing your funds and then failing to mark the order cancelled, leaving it resting and matchable after it had been refunded.
• Fixed the exchange reporting a cancel as complete when it had only been handed to the matching process. Hummingbot treats a successful cancel as final, so it stopped tracking an order that was still open.

The bot console reported an empty book for a market that had one

A single corrupt order row with no symbol became a market with no name, which sorted first and was selected automatically — so the console described a market that did not exist while the real one traded beside it.

• Fixed unusable order rows appearing as markets in the console.
• Changed the console to open on a market that has a book rather than whichever sorts first.
• Added a distinct verdict for a book that could not be read. An empty ladder previously always read as no liquidity — seed this market, sending you to fix a market when the fault was on our side.

Market data and error reporting

• Fixed the last traded price never consulting the trade tape. It reported a daily candle, then the book mid-point — an average of two orders that have not traded — and zero when there was no book.
• Fixed the connector accepting a price of zero as a valid price.
• Fixed an empty book producing no stream frame at all, so a book that emptied looked identical to one that had not changed and bots kept quoting against liquidity that was gone.
• Fixed insufficient balance being reported with the error code for a malformed request. A bot reads that as stop, your request is wrong rather than your account is short.
• Changed the insufficient-balance message to name what you hold and what is missing, rather than the order's full cost.
• Fixed the shutdown sweep counting attempted cancels as successful ones, and spending its budget on price-lookup connectors before the one holding your orders. Cancels during shutdown now use a short, wide retry so every order gets an attempt.
• Fixed connector credentials and exchange address being frozen at first start. Editing an instance, or rotating its key, had no effect on an install that had already been provisioned.
• Fixed a paper-trade connector being accepted as an arbitrage strategy's hedge venue. It cannot execute, so the bot would quote and never hedge.

Installer and documentation

• Added a kit version, stamped into the checkout on install and logged by the bot at startup, so you can tell at a glance which build a bot is running.
• Added an updating guide (hummingbot/docs/UPDATING.md) covering which fixes reach you automatically and which need a reinstall.
• Fixed the installer verifying only a helper module, so a connector that could not load at all passed as healthy. It now imports every module the kit ships, and it works that list out by reading the kit rather than carrying a written-down copy — a written-down list is a second place for the truth to live, and it named two files the perpetual connector has never had, because that connector deliberately reuses the spot connector's authentication and web helpers. A correct install could therefore report itself broken and skip stamping its kit version, which is worse than the silence the check replaced.
• Fixed the installer printing a start command that contradicts every preset and both guides, and showing it for only one preset.
• Fixed the installer being able to place a strategy controller where Hummingbot never looks, and reporting it as installed.
• Fixed the strategy guide describing a maker rebate that does not exist and understating the profitability floor roughly fourfold.
• Fixed a downloaded preset instructing you to save it under an internal identifier rather than its own filename.