The systems we built to trade our own capital

The module defines the geometry of the grid around a reference price: the range boundaries, the number of levels, the type of spacing, and the size at each level. Spacing can be arithmetic — an equal price difference between adjacent levels — or geometric, where the ratio of adjacent prices is constant. Geometric spacing is more robust across wide ranges; arithmetic spacing is sufficient within a narrow band. The computed prices and sizes are conformed to the instrument's precision rules by the adapter layer. Levels that fall below the minimum notional are discarded while the grid is still being assembled — before the venue would reject them.

Each level is described by a state machine: cancelled, placed, partially filled, fully filled. After a full fill the module places a counter order at the adjacent level; a partial fill does not reset the level's state. Orders are placed as maker-only (post-only): a rejected order is re-placed at the current price rather than crossing the spread. A move beyond the range is handled by one of several explicitly defined policies — freezing the grid, shifting it by one step, or a full rebuild with an incremented generation number. Rebuilds are bounded by hysteresis and a cooldown; otherwise the grid would re-place on every tick and hit the request-rate limit.

The engine turns a strategy's intent into a concrete stream of commands. A post-only limit order — when the goal is to remain a liquidity provider and not cross the spread. An aggressive limit order with a protective price instead of a market order — when capping slippage matters. IOC or FOK — where a partial or delayed fill is unacceptable. Each order lives as a state machine: from local creation to a terminal state, with transitions moving forward only. A position is computed from the actually filled size and the average fill price — the order's requested size says nothing about the outcome.

The channel to the exchange is unreliable, so the engine assumes a response may be lost, delivered twice, or arrive out of order. A self-assigned order identifier is generated before sending and serves as an idempotency key: a repeated request with the same key does not create a second order. After a timeout the engine does not resend blindly — it queries the status by that key. Private-stream events are deduplicated by fill identifier and discarded if they refer to an earlier state than the one already applied. Cancellation and fill always race each other, so a cancel rejection with the reason 'order already filled' is treated as a normal state-machine transition, not a failure.

The module builds the instrument's state from a stream of closed candles and hands the trading layer three quantities: a volatility estimate, the boundaries of the current range, and a continuous measure of how sideways the market is. Volatility is computed several ways — Wilder's ATR, its price-normalized form NATR, and range-based estimators (Parkinson, Rogers–Satchell, Yang–Zhang). Each method is computed over a short and a long window: the short one reacts quickly, the long one gives a stable structural estimate. The grid spacing is derived from NATR and clamped on both sides: from below by the cost of a full round trip (fee plus spread), from above by the acceptable idle time of a level. The number of levels is bounded by the open-order limit and the capital per level.

The market regime is classified from independent measures: ADX, the efficiency ratio of the move, the R² of a linear price regression, a variance ratio, the Hurst exponent over a long window, and the compression of Bollinger Bands inside Keltner Channels. What is exposed is not a binary flag but a continuous weight, subject to a stability requirement over N bars. Parameters are re-evaluated at bar close, with hysteresis and only on a significant departure from the current configuration: rebuilding the grid means cancelling and placing orders, that is, load on the rate limits and slippage risk. All indicators are computed causally, as of the bar, with no centered windows and no hindsight smoothing. On a stream break, gaps in history, or an incomplete warm-up, the module reports an 'undefined' status, and the trading layer stops adding to the position.

The risk-control layer sits in the path of every order: a strategy has no direct access to the execution gateway and technically cannot bypass the checks — this is a property of the architecture, not an internal agreement. Before it is sent, each order is checked against the instrument's rules, its deviation from the reference price, and the message rate. On top of this sit limits per strategy, per instrument, and on the aggregate net position across all venues. There are three operating modes: normal, reduce-only, and a full halt in which only cancellations pass.

A pre-trade check is no more reliable than the data it runs on: if the local position record has diverged from the exchange's, the limit will fire correctly but on the wrong input. The layer therefore embeds a reconciliation loop shared across the whole infrastructure. The source of truth is the state obtained by a dedicated query to the exchange; the update stream is treated as unreliable by default. A discrepancy is acted on only if it recurs several times in a row and exceeds a notional threshold — otherwise gaps in the stream's sequence would trigger constant state rebuilds. The kill switch is duplicated on the exchange side: if our process stops sending its periodic signal, the exchange cancels the open orders itself.

The module maintains a single registry of how much of the firm's own capital is available to each strategy and each instrument. The size of an individual position is set as a fixed fraction of the allocated budget and normalized by the instrument's current volatility: the same notional carries different risk in a calm market and a volatile one. Strategy budgets do not overlap, and any excess is rejected by the pre-trade check before an order is even sent.

A portion of capital is never allocated to opening positions and is held as a reserve against variation margin, funding costs, and price gaps. Without such a reserve, a jump in the mark price of a single position would touch the shared collateral and the other strategies. Free and locked balance, initial and maintenance margin are accounted for separately. Rebalancing is triggered by a deviation band around the target weights rather than on a schedule: a narrow band means excess turnover and cost, a wide one means accumulated drift.

Each venue has its own transport, its own instrument naming, and its own precision rules, and the adapter isolates these differences. REST is used for state snapshots, reference data, and service requests; WebSocket for quote streams and order events; FIX where it is available and justified. Upstream it presents a single domain model: an instrument with its price step, size step, minimum notional, and precision, plus order-book, trade, and order-status events reduced to a common form. The instrument reference data is re-read on a schedule — a venue changes its precision rules without notice.

Rounding is done in the adapter, before sending, so the other modules need not think about it. Price is conformed to the price step, size to the size step and truncated downward so as not to exceed the available balance. Then the minimum notional — price times quantity — and the permitted precision are checked; an order that fails the notional is rejected on our side. A dropped connection is handled by a dedicated path: reconnection with increasing backoff and random jitter, re-subscription to the streams, and a request to the venue for the current state.

The engine is built as a single event-processing loop: market data, timers, orders, and exchange acknowledgements pass through one queue in strict chronological order. A strategy sees only the market state that existed at the current timestamp. The order book is reconstructed from a stream of level and order updates (L2/L3); where that resolution is excessive, an aggregated-bar mode is available. The strategy code is the same in simulation, on a live feed in paper-trading mode, and in production — only the data and execution adapters differ.

The value of a simulator is set by how honestly it models friction. A limit order is not counted as filled merely because price touched it: queue position at the level, the volume that passed through it, partial fills, and the rejection of post-only orders that would cross the spread are all accounted for. On top come maker and taker fees on a tiered schedule, funding accrual at interval boundaries, and depth-dependent slippage. Latencies are specified separately — on receiving data, on sending an order, and on the acknowledgement coming back. It is precisely these that determine which market state the strategy actually saw at the moment of decision.

Telemetry is captured at three levels. Infrastructure — processes, memory, runtime pauses, queue depth. Transport — health signals on each channel, the drift of local clocks against exchange time, the reconnection rate. Trading — open positions and exposure, the share of filled and rejected orders, the deviation of the fill price from the expected one. Metrics are written to a time-series store at a fixed cadence rather than gathered on demand at the moment of investigation: an incident is reconstructed from a continuous series of measurements, for which fragments of logs will not do.

The alerting rules are built around symptoms: a divergence between local and exchange state, stale market data, rising latency in the upper percentiles, a spike in API errors. A single numeric threshold produces too many false positives to base an alert on it alone. Signals are separated by severity level, with deduplication, grouping, and suppression of derived alerts; each carries a response runbook. Critical routes trigger order cancellation and a halt of the loop without waiting for an operator. A separate layer is the audit trail: an order's path from decision to final status is written as structured JSON events with an end-to-end identifier into an append-only log.

The bots' configuration is described as code: a typed schema with explicit value ranges and layers over a base set — an environment layer (historical run, sandbox, production), then environment variables and launch arguments. The schema is strict: an unknown key, a wrong type, or a value out of range stops the launch. A silently substituted default would mean going into trading with an unverified parameter set. Access keys and infrastructure credentials are taken from a separate store, so the parameters themselves are versioned in full — with a change history and the ability to roll back.

Parameters are divided by how they are applied. Risk thresholds, limits, and instrument enablement are picked up on the fly: a new configuration snapshot is assembled, validated, and swapped in with a single switch between trading cycles, so that no cycle ever sees a half-applied state. The connection schema, the set of venues, and the structure of the state store change only on restart. Below the strategy level sit non-disableable ceilings: the maximum position and order size, leverage, send rate, and the kill-switch threshold. Configuration can only tighten them — loosening goes through review and the release of a new version.

Exchange API keys are issued with the minimum set of permissions: trading is allowed, withdrawals are disabled on the exchange side, and the key itself is valid only from the fixed outbound IP addresses of the executing nodes. Where an exchange supports asymmetric keys (Ed25519, RSA), we use them instead of HMAC: only the public part remains on the exchange side, and the private part never leaves our perimeter. Each request is signed over a canonical string with a timestamp and a narrow validity window. Node clocks are synchronized over NTP: the exchange discards an expired signature before it reaches the trading logic.

The store is separated from the trading nodes: secrets lie encrypted on disk under an envelope scheme, the master key never leaves the hardware module (HSM), and the ciphertext is kept apart from the encryption key. The trading process never receives the secret into memory — it calls a signing service over mutual TLS with its own service certificate and receives a ready-made signature. Every call is written to an append-only log. The threat model allows for the compromise of an individual node, so keys are separated across exchanges, sub-accounts, and loops: the trading key is kept apart from the read-only key used for reconciliation.