Engines — Python vs C++

Both engines read the identical strategy_parameters block, generate the same client order id format, persist the same grid graph shape, and drain the same per-strategy Redis command channel. That means the dashboard, the settings panel, the controls and the logs all work unchanged regardless of which one you pick — and a strategy can be moved between them.

• Broadest broker coverage — the reference implementation, where new venues land first.
• Arbitrary-precision Decimal — no fixed-point rounding considerations at all.
• Easiest to introspect — rich structured logging, and the code path for any behaviour is straightforward to read.
• asyncio-based — one event loop per bot, websocket fills processed on the loop.

For a normal grid — tens of levels, sub-second latency tolerance, a handful of strategies per account — this is the right default.

• Fixed-point decimal — int64 scaled by 1e8, branch-free and allocation-free on the fill path.
• Slot-per-strategy threading — each strategy is owned by exactly one worker thread, so fill processing, trailing and config updates never race. Inbound commands are queued and applied by the owning thread.
• Header-only engine core — aggressive inlining; the whole hot path compiles into the binary.
• Far lower per-strategy cost — thousands of strategies per worker are practical.

Prefer it for tight spacing, deep ladders, high fill rates, or when running many strategies on one host.

Lifecycle commands (pause, resume, stop, kill, rebalance, update_config) are published to a per-strategy Redis channel plus a short-lived durable queue. Whichever engine owns the strategy drains it, so control is location-transparent: the dashboard does not need to know which worker or which runtime is hosting the bot.

• 1.Step 1 — Particulars — Where the engine is selected
• 2.Strategy Lifecycle — Commands and live edits
• 3.Step 3 — Preview & Deploy — What happens on deploy