What breaks in a trading loop without Hummingbot integration
A custom market maker usually keeps quote state in process memory. The connection to the exchange drops — the bot continues to assume its orders are live, although some have already been canceled or filled.
After reconnection, it places them anew: duplicates appear in the order book, the position exceeds a limit that no one reconciles.
On a thin order book, even a couple of extra orders move the price themselves, the spread widens, and the next trade closes noticeably worse than calculated.
The second point of failure is manual order management. Changes to the spread, grid step, or range boundaries are made by editing the settings file and restarting; state is lost, and during the restart the instrument is not quoted at all.
While one engineer handles this, any unavailability becomes a liquidity hole: the order book stays empty exactly as long as it takes to find the cause.
The third is silent failure of the trading strategy. The bot runs, places orders, the log is clean, but the configuration has long ceased to match volatility: the spread is too narrow for current depth, inventory accumulates to one side.
From the outside it looks like a healthy bot, in fact like a strategy that slowly accumulates risk and loses spread on every round.
We break down how this is closed by integrating Hummingbot into the trading loop.
What managed market making delivers: measurable results
Manual quote management relies on on-call duty: until an engineer moves the orders, the spread lives by yesterday's volatility. Any restart is a window when the order book is empty, and volume goes exactly into it.
A managed loop on Hummingbot turns such decisions into rules: position limits, automatic node restart, a log of every action.
Trading loop downtime
Nodes come up as services with liveness checks and auto-restart, and orders are restored from saved state rather than placed again manually.
Downtime shrinks from hours to minutes: the share of time when the loop actually quotes stops depending on the human factor and the on-call time zone.
Position risk control
Limits on position size, maximum drawdown, and instrument exposure are set before start, not after the fact.
Exceeding them stops order placement and closes the position by rule — risk is visible in monitoring as it approaches the boundary, not in a report after a series of trades.
Reduction of manual operations share
Order replacement, spread changes, rebalancing, and strategy stop move into a schedule and trigger conditions.
What remains are setup-level tasks: the share of manual operations drops by an order of magnitude, and engineering time goes to analyzing metrics, not on-call at the terminal.
All three metrics are taken from one loop, so the effect is visible in dynamics: we compare periods before and after strategy migration, rather than relying on the feel of a trading session.
Hummingbot integration options: cloud, own server, hybrid
Where the trading bot lives matters more than it seems: latency to the exchange, access to private keys, and how fast the strategy reaches the real market depend on it. Hummingbot is an open-source market-making engine, and it can be deployed in three schemes. Each trades control against speed of launch in its own way.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud deployment | Need to start in a short time, no own hardware, strategy already debugged | Keys are held by the provider, latency to the exchange is higher, fine network tuning is unavailable |
| Deployment on own server | Full control over keys and logs is required, strategy is latency-sensitive | Environment setup, monitoring, and updates remain on your side, launch takes longer |
| Hybrid hosting scheme | Trading loop on own hardware, strategy backtesting in the cloud | Two loops need to be connected, configurations and strategy versions synchronized |
Exchange interface limits are the same for all three schemes and often decide the choice.
Rate limits and order weight limits prevent quoting too frequently, some order types are available only in certain markets, and a test loop does not replicate real order book depth — on a live market the strategy behaves differently.
Own-server deployment is chosen where private keys and predictable latency matter: a container with the bot, a separate exchange access node, own logs and failure alerts.
Cloud deployment wins at the hypothesis testing stage — set strategy parameters and observe behavior on a live order book. Hybrid covers both scenarios but requires discipline in configurations: diverging strategy versions across loops produce discrepancies in reports.
Work sequence: from trading logic audit to launch
Hummingbot integration work goes from trading logic audit to handover to production, and each stage closes with an artifact that can be checked, not a verbal "done".
The order should not be violated: a strategy built before inventorying connections and exchange limits usually hits them already on a live account.
- Audit of trading logic and current loop. We look at entry and exit rules, the position accounting method, quote sources, and how orders are placed and canceled. The output is a map of bottlenecks: where logic relies on manual actions and where order duplicates are possible.
- Scheme and target parameters. We fix pairs, spread size, order replacement step, limits on position and number of active orders, and behavior on exchange connection loss. This is the specification for building the configuration.
- Strategy and connection assembly. We prepare configuration files, create access keys with the minimum necessary permissions, without withdrawal, and separately set rate limits for exchange requests.
- Historical data testing. We run the logic on recorded quote and order book series: we look at drawdown, canceled order share, behavior on missing candles and on a thin market.
- Test loop with small volume. We duplicate the run on an exchange test environment or with minimal real volume, reconciling actual fills with calculated ones.
- Handover to production. We hand over configurations, strategy descriptions, run logs, and procedures: how to change parameters, how to stop the bot, and how to roll back to the previous strategy version.
What the team keeps: configurations, schemes, regulations
After Hummingbot integration, the team is left not with a "black box" but with a set of artifacts by which the loop can be developed, handed to another engineer, or restored after a failure. Below is the minimum set we close on every market-making project.
- Strategy configurations — working parameter files: spreads, sizes and quote depth, position limits, recalculation intervals, alongside a change log explaining which change led to which behavior.
- Trading loop scheme — quote and order flows by node, failure points, behavior on exchange connection loss, and restart procedure without manual parameter editing.
- Access matrix — who and from which addresses changes parameters, who sees only metrics, how keys are issued, rotated, and revoked when an engineer leaves.
- Failure response procedure — what we consider an incident, who and how stops the strategy, how to roll back to the previous parameter set and within what time.
- Documentation package — strategy logic, from-scratch launch instructions, decommissioning procedure, change and decision history.
- Set of metrics and thresholds — by which values it is visible that the strategy deviates from expected behavior and when manual review is needed.
We deliver each artifact with validation by an external engineer: if the loop cannot be raised from it without us, it is not written well enough.
Case study: how a class of failures was eliminated in a volatile market
A market maker on several exchanges went into manual mode on every volatility spike: quotes diverged from the benchmark spread, some orders hung between submission and confirmation, and exchange connection loss left open positions unattended.
On sharp moves, divergence reached several percent of the target spread, up to a tenth of orders hung, and loop recovery took 20–30 minutes of manual review.
What we changed
The strategy on Hummingbot remained the foundation, but position state stopped living only inside the trading logic.
Independent accounting with exchange reconciliation on every reconnect appeared, and each order got a client identifier: resubmission after connection loss no longer creates duplicates or doubles the position.
We separately closed quoting on a stale order book: when the market exits the target corridor, the strategy cancels orders and pauses instead of quoting at the wrong price.
Reconnection uses increasing backoff, and on connection loss the loop first cancels orders and only then recovers.
What became
The share of hung orders fell from a tenth to fractions of a percent, quote divergence returned within the target spread, and loop recovery after connection loss takes less than a minute and happens automatically.
Manual interventions during the observation period — zero: the failure class "quoting at a stale price after disconnect" disappeared along with manual reviews.
Metrics appeared in the loop that make degradation visible before money loss: spread divergence, share of hung orders, recovery time after connection loss.
How does market making on an exchange differ from arbitrage?
Market making is quoting: the strategy keeps orders on both sides of the order book and earns on spread and liquidity reward. Arbitrage captures divergence: the same asset is bought on one venue and immediately sold on another.
The modes share only the exchange access layer — beyond that, they are loops different in load, risk, and requirements.
| Axis | Market making | Arbitrage |
|---|---|---|
| Source of result | Spread and liquidity reward | Price difference between venues |
| Directional position risk | High: inventory accumulates against movement | Low: position closed by the opposite leg |
| Speed requirements | Continuity of quoting | Peak reaction in a short window |
| Loop load | Steady flow of orders and cancellations | Rare spikes when divergence appears |
| When chosen | Need constant liquidity and turnover | Venues provide a stable price difference |
Directional position risk is the main divide. A market maker holds inventory constantly, so on a trend it accumulates the asset against the movement; it is protected by position limits, hedging orders, and moving quotes out of the danger zone.
Arbitrage almost does not hold a position, but requires simultaneous execution of two legs: a delay on one venue turns the trade into a directional one.
Reaction speed is also different in nature. For a market maker, continuity matters more — a gap in quoting is visible in turnover and missed trades. Arbitrage needs peak reaction in a narrow window, so its loop idles and waits for a spike.
Arbitrage is chosen where liquidity is spread across venues and divergences repeat predictably.
In Hummingbot, both modes are built on top of a shared exchange connection layer, so the choice of trading strategy is a matter of configuration and risk limits, not rewriting the integration.
Technical questions asked before launch
Before launch, engineering teams ask not "does it work" but about resilience: what happens on exchange connection loss, how not to duplicate orders on reconnect, how to stay within rate limits, and where access keys are stored. Below are the answers as these points are solved in our implementation.
What happens to orders when exchange connection is lost?
After every disconnect, the connector reconciles the actual state: open orders and balances are pulled from the exchange, and the strategy continues from them, not from the last memory record.
Each order is assigned an identifier on our side, mapped to the exchange one, so before placing it checks whether an active order already exists for this pair and side. On timeout instead of confirmation, the request is not repeated blindly — account state is requested first.
How do you stay within exchange rate limits?
Limits are accounted for at the connector level: a request queue and rate limit per method with headroom for peak load.
As the threshold approaches, the strategy reduces recalculation frequency — an exchange-side ban cuts off all requests at once, including those needed to cancel orders.
Where are account access keys stored?
Keys are stored in a secure vault and enter the process only at startup, via environment variables; they are not in the configuration or logs.
API permissions are limited to trading without withdrawals, and vault access is granted by an infrastructure-side role, not a shared file on the server.
Can the strategy be tested before a live account?
Testing runs in three steps: historical data, exchange test loop with real latencies and responses, then an account with minimal volume.
At each step, spread, filled order share, number of cancellations, and maximum position drawdown are reconciled — they show whether the strategy behaves as intended.
Let's discuss the task: we'll send a scheme, estimate, and work plan
To come back with an estimate and plan, not general wording, we need to review the current loop: where bots run, which exchanges and pairs are connected, how keys, limits, and trade logging are arranged, what metrics are already collected.
For this, a short call and access to configurations are enough — after that we describe the scheme. Below is the order the work follows; it also becomes the table of contents of the plan.
- Loop review: current strategies, order placement methods, revaluation frequency, connection loss handling, and already accumulated execution statistics.
- Integration scheme: how Hummingbot sits alongside your exchanges and accounting systems, where keys pass, which limits and safeguards constrain position size.
- Timeline estimate: stages with points where you can stop or change priorities, and explicit dependencies on external approvals.
- Pilot launch: limited pair and small volume, reconciliation of actual trades with expected ones, behavior check on failures and partial fills.
- Custom strategies: entry and exit rules, risk parameters, cancellation and order replacement logic, historical data tests.
- Trading loop support: monitoring, incident review, parameter adjustment when liquidity changes and exchange-side updates occur.
- Handover: configurations, launch and recovery documentation, instructions for your team.
Describe the task in two or three sentences — we'll come back with a timeline estimate and work plan on these points.