Heuristic:Nautechsystems Nautilus trader Order Rate Limiting Configuration
| Knowledge Sources | |
|---|---|
| Domains | Optimization, Risk_Management, Live_Trading |
| Last Updated | 2026-02-10 08:30 GMT |
Overview
Pre-trade risk control technique using order submit and modify rate throttlers to prevent exceeding exchange rate limits and avoid ban risk.
Description
The `RiskEngine` provides built-in rate limiting for order submissions and modifications via configurable throttler objects. The throttlers use a sliding window algorithm: orders exceeding the configured rate are silently denied (for new orders) or dropped (for modifications) with appropriate log warnings. The rate is expressed as a string in the format `"{count}/{interval}"` (e.g., `"100/00:00:01"` for 100 orders per second).
Usage
Use this heuristic when:
- Deploying strategies that submit orders at high frequency (HFT, market making)
- Connecting to exchanges with strict rate limits (most centralized exchanges)
- Running multiple strategies on the same trading node that share rate limits
- Protecting against runaway strategy bugs that could submit excessive orders
The Insight (Rule of Thumb)
- Action: Configure `max_order_submit_rate` and `max_order_modify_rate` in `RiskEngineConfig`.
- Value: Set to 80% of the exchange's actual rate limit to provide a safety margin. For example, if Binance allows 10 orders/second, set `"8/00:00:01"`.
- Format: `"{count}/{timedelta}"` where timedelta is a pandas-parseable string (e.g., `"00:00:01"` for 1 second, `"00:01:00"` for 1 minute).
- Trade-off: Too restrictive limits will cause legitimate orders to be denied. Too generous limits risk exchange bans. Orders that exceed the limit are silently denied with a log warning, not queued for later submission.
Reasoning
Exchanges impose rate limits to prevent abuse and ensure fair access. Exceeding these limits typically results in temporary IP bans or API key revocation. The RiskEngine throttlers act as a local safeguard that is faster and more reliable than relying on exchange error responses. By setting the limit below the exchange maximum, you account for network latency variance and potential concurrent requests from other API consumers sharing the same key.
The deny behavior (rather than queue-and-retry) is intentional: in live trading, a delayed order may be worse than no order at all, as market conditions change rapidly.
Code Evidence
Throttler initialization from `risk/engine.pyx:143-153`:
pieces = config.max_order_submit_rate.split("/")
order_submit_rate_limit = int(pieces[0])
order_submit_rate_interval = pd.to_timedelta(pieces[1])
self._order_submit_throttler = Throttler(
name="ORDER_SUBMIT_THROTTLER",
limit=order_submit_rate_limit,
interval=order_submit_rate_interval,
output_send=self._send_to_execution,
output_drop=self._deny_new_order,
clock=clock,
)
Rate limit accessor from `risk/engine.pyx:318-331`:
cpdef tuple max_order_submit_rate(self):
return (
self._order_submit_throttler.limit,
self._order_submit_throttler.interval,
)
cpdef tuple max_order_modify_rate(self):
return (
self._order_modify_throttler.limit,
self._order_modify_throttler.interval,
)