WonderTrader: A C++ Quantitative Trading Framework with Four Execution Engines

What WonderTrader is and the problem it solves

Most Python-only quantitative trading frameworks hit a wall when the number of tracked instruments grows beyond a few dozen or when strategy latency requirements drop below a millisecond. A Python strategy computing signals for 100+ instruments simultaneously creates resource contention, and even multi-process approaches impose overhead. WonderTrader's design starts from the opposite assumption: performance is non-negotiable, and Python is an application-layer convenience on top of a fast C++ core.

The README positions WonderTrader as targeting professional institutions managing tens of billions in live positions. The C++ core handles market data distribution, risk control, and order routing. The Python wrapper, wtpy, provides the strategy API and the monitoring console. Strategy logic written in Python runs on top of a C++ event loop, and the README notes that a Python implementation of the DualThrust strategy averages approximately 70 microseconds per recalculation while the C++ implementation averages 4.5 microseconds.

The four execution engines and what each one targets

WonderTrader ships four engines with distinct latency and use-case profiles.

The CTA engine is the synchronous strategy engine, driven by both time and market events. It suits strategies with a small number of instruments and fast signal logic, such as single-instrument timing models or medium-frequency arbitrage. The DualThrust example runs in this engine.

The SEL engine is the asynchronous strategy engine, time-driven rather than event-driven. It suits multi-factor selection strategies that score hundreds of instruments on a schedule. The computation runs in a separate thread from the order execution, allowing large calculations without blocking routing.

The HFT engine targets general high-frequency strategies. The README states system latency of one to two microseconds. It exposes more execution primitives to the strategy layer than the CTA engine.

The UFT engine, introduced at version 0.9, targets ultra-high-frequency scenarios. It runs entirely within the WtCore C++ project, with no application-layer interface. The README states system latency within 200 nanoseconds. The UFT engine is for use cases where even the HFT engine's one-to-two-microsecond overhead is unacceptable.

Installing the Python wrapper wtpy

The C++ core, WonderTrader, ships as compiled binaries in the dist/ directory of the repository for Linux and Windows. The Python wrapper, wtpy, installs from PyPI and links against those binaries. To install wtpy:

pip install wtpy --upgrade

This requires Python 3.8 or newer. The wtpy package includes the monitoring service WtMonSvr, which provides a web-based dashboard for real-time strategy monitoring and automated scheduling. The README notes that wtpy is also available on Gitee at gitee.com/wondertrader/wtpy for users who need access from within China's network.

The WonderTrader C++ binaries are in the dist/ directory, structured separately for Linux and Windows via the copy_bins_linux.sh and copy_bins_win.bat scripts in the repository root. Teams that need to compile from source can do so from the src/ directory, though the README does not walk through build instructions.

Portfolio management and the M+1+N execution architecture

WonderTrader organizes live trading into combination portfolios, each with a defined unit capital, risk parameters, and a set of strategies. Multiple accounts can run the same portfolio with different position multipliers. The README describes this as the M+1+N architecture: M combination portfolios feed signals to a single signal aggregator (1), which fans out orders to N trading channels.

This matters in two ways. First, it prevents self-trade: when multiple strategies in the same portfolio target the same instrument, WonderTrader merges their target positions before sending orders, eliminating the risk of one strategy buying what another is selling on the same account. Second, it enables multi-account scaling: a team managing ten accounts with the same strategy loads sets the position multiplier per account based on capital size and risk tolerance, rather than running ten independent strategy instances.

The README gives a worked example: a portfolio with 5 million RMB base capital running at a 10% maximum drawdown threshold. An account with 10 million RMB and the same risk tolerance uses a 2x multiplier. An account with the same capital but a 20% drawdown tolerance uses a 4x multiplier.

Risk control mechanisms

WonderTrader implements four independent risk control layers. Portfolio capital risk control monitors the virtual position value of the combination portfolio and stops trading when the virtual drawdown threshold is reached, even if the account's real drawdown has not yet triggered. This protects against strategies that are losing in theory but whose losses have not yet been realized.

Channel compliance risk control limits the total number of order cancellations and the order rate within a short time window. This targets regulatory compliance requirements common on Chinese futures exchanges, where excessive cancellation activity can result in exchange penalties.

Account capital risk control operates on the actual account balance and position P&L, similar to standard drawdown-based risk management in other frameworks.

The clutch mechanism is a signal-execution decoupler. When a specific instrument or strategy enters a risky state, the clutch disconnects signal generation from order execution for that instrument while allowing the strategy to continue running. A trader can watch how the strategy would have performed during the risk period without live orders being placed.

Data serving architecture and supported broker protocols

The market data subsystem uses a local data server that broadcasts real-time data via UDP to multiple combination portfolios simultaneously. The README describes this as a 1+N architecture: one data feed serves N portfolios without duplication. Historical data caches in memory during the trading session, using memory slice references rather than copies to avoid allocation overhead. Real-time data writes to mmap files, which survive process restarts without data loss. MySQL is supported for historical data storage.

On the broker connectivity side, WonderTrader supports CTP and CTPMini for futures, Femas for futures, CTPOpt and maOpt for options, and XTP and ATP for A-share equities. The supported protocols are exchange-specific to China's financial markets. There is no FIX protocol support documented in the README, and no mention of non-Chinese exchange connectivity.

Comparison to Python-only quant frameworks

Python-only quantitative trading frameworks such as vn.py (vnpy) take the opposite architectural approach: everything runs in Python, with exchange connectivity through Python-wrapped C libraries for performance-sensitive paths. vn.py is widely used in China for similar markets and broker protocols.

The practical difference is ceiling: vn.py and similar frameworks work well for strategies tracking tens of instruments at medium frequency, but the Python event loop becomes a bottleneck at high instrument counts or when strategies require sub-millisecond signal generation. WonderTrader delegates all of those bottlenecks to C++. The trade-off is installation complexity and the need for compiled binaries matched to the platform and exchange SDK version.

For teams doing research and backtesting in a Jupyter environment, WonderTrader's C++ core is not a natural fit. The README mentions a reinforcement learning framework Wt4ElegantRL that uses wtpy as a backtesting engine, but the primary use case is live trading.

Maintenance and licensing

The repository was last pushed on 2026-09-01. It carries the MIT license. The project has no GitHub releases; the main way to track changes is the updatelog.md file in the repository root and a WeChat public account called wondertrader for real-time announcements.

Documentation is split across three sources: the official documentation at docs.wondertrader.com, a semi-official documentation site at dumengru.github.io/docs_wondertrader, and a learning notes site maintained by a community contributor. The existence of community-maintained documentation sites reflects that the official documentation may have gaps for some use cases. The dist/ directory contains pre-built binaries for both Linux and Windows; Docker configuration is in the docker/ directory.

Editorial conclusion

Quantitative trading teams in China who need a framework that spans research backtesting, medium-frequency strategies, and ultra-low-latency execution from a single codebase should evaluate WonderTrader. The C++ core is not pip-installable; only the Python wrapper wtpy is on PyPI. Teams without C++ expertise may find the operational overhead of maintaining the C++ binaries significant. The last push to the repository was on 2026-09-01, and the framework explicitly targets Chinese exchange protocols including CTP for futures and XTP for equities, making it a poor fit for markets that use other protocols.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wondertrader/wondertrader on GitHub