Hummingbot Connector v6.1.2

Release Date: August 21, 2026 Tags: CRITICAL FIX, ORDERS, MARKET MAKING, ORDER BOOK

Overview

A market maker that cancelled several quotes at once made its own order book read as empty for the next few seconds — and was then refused for insufficient liquidity against a book that was full.

Cancelling an order does two things that do not happen together. The order leaves the matching engine's working set immediately, so nothing can trade against funds that are on their way back to you. Its depth leaves the published book only at the end, after the refund has been written to your wallet. On a live install that gap was measured at three to four seconds.

For that whole window the price level was sitting in the book with nothing behind it in the working set — which is exactly what a genuine phantom level looks like. Pricing could not tell the two apart, so it did what v6.1.1 taught it to do with a phantom: skip the level and price as though that liquidity were not there.

A strategy that re-quotes on a timer cancels its whole ladder within a few milliseconds. Every one of those levels went dark at once, and for the next few seconds the bot's own book — often the only book on a young market — priced as empty. Orders came back Order book has insufficient liquidity while the book plainly showed depth, and the same misreading warned the operator that their own healthy, mid-cancellation orders were phantom levels needing repair.

An order has not stopped backing its price level until its depth is actually removed, and it is now counted until then.

This is a platform-side fix. There is no connector reinstall and no bot restart. Requires Core v6.7.0.

Update Instructions

Two steps, and neither of them touches your bots.

1. Update the platform

Update to Core v6.7.0 the way you normally do.

2. Restart the backend

The matching engine holds this state in memory, so the fix takes effect when the process restarts — not when the files land.

There is no step 3

Do not reinstall the connector for this release. The connector kit is unchanged at 2026.08.20, the same build v6.1.1 shipped, and reinstalling it achieves nothing. If your bots are running v6.1.1, leave them running.

If you are coming from v6.1.0 or earlier, you have not applied v6.1.1 yet — follow that release's Update Instructions in full first. It needs a reinstall and a bot restart, and its fixes are the larger half of the two.

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

Confirm it took

Cancel a resting order on a market you can watch, and place an order against the same side immediately afterwards. Before this release that second order could be refused for insufficient liquidity; now it prices against the book you can see.

The backend log is the other tell. The warning naming levels with no resting order behind them should now appear only for levels that really are stranded — if it stopped appearing entirely after the restart, every one it had been reporting was a healthy order mid-cancellation.

No database migration.

Upgrade Notes

Phantom levels already in your book are still there

Unchanged from v6.1.1: this release stops healthy orders being mistaken for phantoms. It does not retract the real ones. Those still need node backend/scripts/rebuild-eco-orderbook.mjs <symbol> --execute and a backend restart, as described in that release.

The repair script was never fooled by this

Worth knowing if you ran it on one of the false warnings: the script decides from the stored orders, where an order mid-cancellation is still open, so it saw those levels as correctly backed and left them alone. Only the log line was wrong. A dry run you performed on that advice will have reported nothing to do.

Cancels still take a few seconds to leave the book

This release makes the platform read that window correctly. It does not shorten it — the depth still comes out at the end, after the refund. What changed is that the level is no longer treated as stranded while the cancel is in flight.

Fixed

Orders refused for insufficient liquidity against a book that had plenty

The matching engine removes a cancelling order from its working set before the refund and the cancellation record are written, and only that last write takes the order's size out of the published book. Anything pricing in between saw a level with no order behind it and skipped it as a phantom.

The cost scaled with how many orders were cancelled together, which for a market maker is all of them: a bot re-quoting both sides erased its own visible depth for three to four seconds out of every cycle. On a market where that bot is the only liquidity, the book read as empty, and every order priced against it in that window was rejected.

• Fixed orders that are mid-cancellation no longer being counted toward the depth backing their price level. They are counted until their size is actually removed from the book.
• Fixed the same misreading rejecting market and limit orders with Order book has insufficient liquidity against a book that had depth at every level the order needed.

Healthy orders reported as phantom price levels

The warning that names levels with no resting order behind them — and points you at the repair script — was reading the same gap, so it reported an operator's own working orders as stranded depth seconds after they were cancelled. On a busy market maker that was the normal state of the book, not an exception.

• Fixed the phantom-level warning naming orders that are simply mid-cancellation. It now reports only levels nothing is behind.

Safeguards on the fix itself

Counting a cancelling order toward its level has two ways of going wrong, and both are now closed.

• Fixed a cancellation that fails after the order leaves the working set being able to hold its price level up indefinitely. A record older than the engine's claim window stops counting and is discarded — the original phantom, reached from the opposite direction.
• Changed cancel-all to give each order's record back the moment that order's own decrement lands, rather than leaving it to the claim window. Clearing a ladder and re-quoting the same prices immediately — which is what a market maker does — would otherwise judge the new levels against the depth that had just been withdrawn.
• Changed the cancelling orders to be counted through the same derivation the matching engine already runs against its working set, rather than added separately, so a price cannot be backed for one and stranded for the other.
• Added coverage pinning that these orders are visible to pricing only and never to matching. An order being cancelled has had its funds returned; filling it would spend money that is already back in the customer's wallet.