C++ trading-systems case study
A complete algorithmic trading platform, from market data to live execution.
ENZO-TS is a multi-process C++20 platform for algorithmic trading research and live operation. It spans exchange adapters, historical-data ingestion, exchange-aware simulation, model evaluation, signal distribution, portfolio allocation, execution, and risk controls.
01 Architecture
Signal to execution
Signal generation, distribution, orchestration and execution each run as their own process. Separating them keeps account credentials inside the execution clients, lets one market's model crash without taking the portfolio down with it, and allows a single set of signals to drive more than one account.
Market data
Streams and cached candles
TSP
Signal generators
One process per market
TSM
Network hub
Distributes signals
TSL
Launcher
Ranks candidates, allocates
TSC
Execution clients
Orders, state, reconciliation
Exchange APIs
One client per account
Shared libraries exchange access · simulation · backtesting · models · indicators · reporting · configuration · networking · interfaces
02 Exchange and execution
Order lifecycle against live venue APIs
The exchange layer is the part that has to be right every time. It covers Binance and Bybit over both REST and WebSocket, on public market streams and private account streams.
Execution client
Venue API
Places an order, tagged with a client order ID
Accepts it and returns an exchange order ID
Tracks the order as working
Streams status changes and fills
Cancels on a stop or a drift check
Confirms the cancellation
Reconciles its own state after a restart
Reports open orders and positions
Both identifiers persist so an order stays traceable across a restart or a dropped connection
- Connectivity
- REST and WebSocket adapters per venue, carrying public market data on one side and private account events on the other.
- Order lifecycle
- Placement, cancellation and status tracking, with persistent exchange and client order identifiers so an order can be traced back to the signal that produced it.
- Reconciliation
- Local order state is checked against what the venue reports, so a restart or a dropped connection does not leave the system guessing about a position.
- Venue constraints
- Server-clock synchronization against venue time, and explicit rate-limit and HTTP 429 handling rather than retry-and-hope.
- Historical data
- Candle ingestion with local caching, so research and live processes read the same market history without refetching it from the venue on every run.
- Portability
- A Phemex adapter and continuing work to decouple the system from the shape of any one venue's API.
03 Simulation and research
Historical evaluation that models the venue
A backtest is only as good as its fills. The simulator models exchange order behaviour and applies commissions and trading costs, rather than assuming an ideal fill at the closing price.
- Data and fills
- Sub-minute historical data through an exchange-aware order simulator, with positions and trades persisted for later inspection.
- Portfolio simulation
- Runs span multiple markets at once, so allocation behaviour can be studied rather than inferred from single-market results.
- Reporting
- P&L, alpha, win rate and monthly statistics, alongside Sharpe, Sortino and maximum drawdown, so a run is judged on more than one number.
- Models
- Custom indicators and a strategy framework, with several model families explored side by side rather than one line of research pursued alone.
- Validation
- Out-of-sample practice and leakage controls, treated as first-class concerns. Most of the research effort goes into not fooling yourself.
04 Portfolio, risk, and operations
Controls around the live path
The orchestrator evaluates persisted signal statistics, ranks allocation candidates, and applies allocation rules before instructing the execution clients.
-
Arriving from the hub
-
Market gating, active-market limits
-
Persisted signal statistics
-
Sizing mode, leverage, per-market switches
-
Sent over IPC
- Allocation
- Position sizing with equal, linear, fixed and manual modes, plus configurable leverage and per-market trading switches.
- Market gating
- Active-market limits decide which markets are permitted to trade at all, before weight is assigned to any of them.
- Trade controls
- Stop-loss with a fallback stop path, entry-drift tolerance to skip fills that have moved too far, and cooldown and retry logic.
- Supervision
- Process groups are supervised and restarted, communicating over TCP/IP between hosts and IPC between local processes.
- State and diagnostics
- State persists across restarts, with logs and runtime diagnostics surfaced in the operator interfaces.
05 Stack
What it is built on
A single C++ codebase carries the runtime, the research tooling and the interfaces, so a model can be evaluated and then run without being reimplemented.
- Runtime
- C++20 across the process types and the shared libraries they are built on, with multi-threaded work for research and evaluation loads.
- Machine learning
- LibTorch for training and evaluating models inside the C++ runtime, with PyTorch alongside it for research work.
- Model search
- Genetic algorithms and neuroevolution beside conventional backpropagation training, run over populations of candidate networks.
- Networking
- TCP/IP between hosts and IPC between local processes, with the hub distributing signals to whichever clients subscribe.
- Storage
- A local historical candle store with caching, alongside persisted positions, trades and runtime state.
- Build targets
- Windows, Linux, macOS and Raspberry Pi.
06 Interfaces
Operator and research tooling
Built alongside the platform, and used to configure runs and study what came out of them.
