Hummingbot Connector 6.1.3

Pre-release

This version isn’t published on updates.mashdiv.com yet — the notes are available to preview, but it can’t be downloaded until it’s released.

22 August 2026

This release has upgrade notes. Read them before updating — they describe behaviour changes that need your attention.

CRITICAL FIXESORDERSMARKET MAKINGBOT CONSOLESTRATEGIES

Hummingbot Connector v6.1.3

Release Date: August 22, 2026 Tags: CRITICAL FIXES, ORDERS, MARKET MAKING, BOT CONSOLE, STRATEGIES

Overview

Three things a two-sided market maker could not do: place a market order, hedge on paper, or stop its bot without losing orders it placed by hand.

A market maker rests on both sides by construction, so its own quote is usually the best price on one of them. The exchange priced every market order against that book — including the maker's own resting orders — and then refused the order for trading against itself. The matching engine never had this problem: it steps over an order from the same account and looks further down the book for a real counterparty. Placement simply did not know that. It now prices against the liquidity the engine will actually give it, on both sides.

Pointing an XEMM strategy's external exchange at a Hummingbot *_paper_trade venue — the standard way to prove a maker side quotes correctly before putting capital on the other venue — was refused outright, with a message saying the strategy "would quote and never hedge". That is true and it is the point of a dry run. The hedge leg may be simulated again.

And Stop the bot on the console cancelled every open order on the account, on every market, including orders placed by hand that no bot ever touched. Because it acts on whoever is signed in rather than on the bot's owner, an administrator who opened someone else's console to stop their bot cancelled their own resting orders instead, while the bot they meant to stop kept quoting.

This is a platform-side release. No connector reinstall, no bot restart. Requires Core v6.7.0.


Update Instructions

1. Update the platform

Update to Core v6.7.0.

2. Restart the backend

The matching engine holds order state in memory, so the fixes take effect when the process restarts, not when the files land.

There is no step 3

Do not reinstall the connector. The kit is unchanged at 2026.08.20 — the same build v6.1.1 shipped — and reinstalling achieves nothing. Bots may keep running throughout.

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

If you are coming from v6.1.0 or earlier, follow v6.1.1's Update Instructions in full first — that one does need a reinstall and a bot restart.

No database migration.


Upgrade Notes

The Stop button now leaves your manual orders alone

This is a deliberate change in what the button does. Previously it cleared the whole account; now it clears what a bot placed and says so.

If you were relying on it as a full de-risk — one button to flatten everything — send allOrders: true and you get the old behaviour, described accurately in the response.

Two cases still widen to the whole account automatically, and both announce themselves rather than doing it quietly: when bot-placed orders cannot be told apart at that moment, and when you ask for it. The summary now reports which sweep actually ran.

Some orders are deliberately left behind, and you are told how many

An order the exchange cannot attribute to a bot is left resting. Usually that is exactly right — it is yours, placed by hand. It can also be an old bot order whose tracking record has aged out, and the API keys are disabled before the cancel runs, so the bot cannot clear that one either. The response now names the count. Check your orders page after an emergency stop and cancel anything you did not expect.

Market orders may now be refused for liquidity where they were refused for self-matching

Same book, more accurate answer. If the only depth on the far side is your own, there is genuinely nothing to fill against — the engine would refuse to cross it. You now get a message that says how many of those levels are your own orders, instead of one naming a single price.


Fixed

A market maker could not place a market order at all

The exchange priced a market order by walking the book from the touch, and it counted the caller's own resting orders as available depth. It then checked whether the order would trade against itself at that price — and for a two-sided maker the answer was almost always yes, because its own quote is the best price on one side by construction.

Observed on a live bot: every market BUY refused with "You already have an open SELL order at 78500.00" — its own quote — for an entire session, on a market where another participant's liquidity was resting one level below.

  • Fixed market orders being priced against the caller's own resting depth. Both sides now net it out, so the walk prices against the liquidity the matching engine will actually provide.
  • Fixed the same fault on market SELL, which an earlier partial fix did not reach.
  • Changed the insufficient-liquidity message to say how many price levels were the caller's own, rather than reporting an empty-looking book.
  • Added a guard so depth the engine could not judge is never treated as netted. A market order that reached beyond what the engine holds keeps the original self-match check, because nothing was subtracted out there.

Paper-trade hedging was refused

  • Fixed XEMM presets refusing a *_paper_trade external exchange. The hedge leg may be simulated; that is what a dry run is.
  • Changed the refusal to apply to the maker leg only, where it is still correct — that leg places the orders that rest on this exchange, so a paper maker would quote into a simulator and never touch the real book.
  • Added a startup line naming a simulated hedge leg, so a paper run is never mistaken for a live one.

The console's Stop button cancelled orders no bot had placed

  • Fixed the emergency stop cancelling every open order on the account. It now cancels what a bot placed, on every market that bot quotes.
  • Fixed the stop reading only the first page of an account's order history. Anything older stayed funded and resting while the operation reported success — and because a separate cap already limited each pass, the page limit only bit when there were few open orders, which is exactly when the summary claimed the account was flat.
  • Fixed cancellations that had been accepted but not yet completed being counted as finished. They are reported separately now.
  • Added the number of orders left resting, and which sweep actually ran, to the result.

A cancelled order could leave its price level short

A repair that rebuilds a price level from the orders behind it did not count orders that were mid-cancellation — they leave the engine's working set seconds before their size leaves the book. The level was rewritten without that order, and the cancellation then subtracted it a second time. Because the repair writes an absolute figure, nothing afterwards could tell the level had ever been wrong.

  • Fixed the level repair double-subtracting an order that is being cancelled.
  • Fixed the same repair being able to remove real depth on a market large enough to exceed the engine's resident window. It now leaves those to the reconciler, which can see the whole book.