StarQuant pairs a C++ trading server with Python strategies you can run in backtest or live

A platform scoped to individual users

StarQuant is described as a light-weighted, integrated trading and backtesting system or platform for individual, ordinary users, rather than for an institution. Its Chinese name is given in the README as a system for numeric trading, and the project is written in C++ and Python.

The current focus is futures and options programmatic trading through the CTP interface, which the README says is in live testing. Stock trading support exists in the form of the Zhongtai XTP and Kuanrui OES interfaces, and the README is explicit that those are awaiting testing and improvement.

That scope statement tells you what kind of project this is. It is a personal platform: one person building the trading system they want to trade with, and publishing it so others can do the same. The stock connectors exist, but the project itself says they are not finished, which is the kind of honesty that tells you how to read the rest of the feature list.

The two progress notes in the README describe where the work stands. In October 2022 a backtest version was updated, on the backtest branch, adding the backtesting features that were common in the Pro version. In December 2020 the 1.0 beta was completed and put into CTP live testing, with the claim that for liquid instruments with wide order books, and for trades that are not large orders, tick level backtest fills matched live fill times and prices. It also ran unattended around the clock on Aliyun and Tencent Cloud, with automatic reconnection of the API counter after a disconnect, automatic recording of market data, and automatic strategy initialisation, start and stop.

That last set of claims, about running unattended for weeks, is the most valuable thing in the README and the hardest thing for a reader to verify from the outside.

A C++ server, separate processes, and two IPC choices

The system architecture section describes a client-server design in C++, with the backtest side offering both an event-driven mode and a vectorised mode, and a modular and loosely coupled design throughout.

The process model is the interesting part. The market data and trading interfaces, the strategy execution and the GUI are all separate processes, and the server side runs market data, trading and data recording as separate threads. Communication between the server and the GUI and the strategies uses a message queue, nanomsg, or shared memory, the latter based on the Kungfu project the README says the system referenced during development.

The performance figures attached to each mode are worth reading with the source in mind, since they are the project's own numbers rather than a third party benchmark. For ordinary applications using the message queue, the README puts the latency in the hundreds of microseconds and states it was measured at 30 to 100 microseconds with throughput around 10k/s, which it says is enough for futures. For stock L2 tick data, where throughput and latency both matter more, the shared memory mode is offered as a way to reach 10 microsecond latency while still landing all trading data.

The data path is worth following too. Market data is forwarded to the strategy process as messages over the relevant ports, and a strategy's order operations travel back the other way to the server, which then calls the counter API. The market data APIs support CTP and TAP, and data can be recorded locally to CSV files or to a MongoDB database.

So the server is a broker for the strategies, not just a place where the counter API is called. That design is what lets a strategy be written once and run in both backtest and live.

One strategy codebase for backtest and live trading

The strategy model is the project's most transferable idea.

Strategies can be written in C++ or in Python, for both backtesting and live trading. The event-driven mode of the backtest framework is rewritten from vnpy, which the project also referenced during development, and it supports dynamically reloading strategies. Most importantly, a strategy has the same form in the backtest program and in the trading program, so it does not need to be rewritten, and the data format and function signatures of Python strategies are compatible with vnpy, which the README says makes conversion, migration and testing easier.

That compatibility is a double-edged fact. It lowers the cost of adopting the framework, and it lowers the cost of leaving it.

Around that core sit several operational features. Strategies can be managed in real time, with the ability to add, delete, edit parameters, start, stop and reload, which the README compares to vnpy's ctastrategy module, and multiple strategy processes can be managed at once. Live trading supports multiple API interfaces, including the penetrating CTP for futures, the ESunny TAP, and the Zhongtai XTP and Kuanrui OES for stocks, with multiple futures and securities accounts logged in at the same time and multiple strategy groups running independently. Trigger conditions can automate logging in, logging out and resetting, and there is a risk control module with parameters for flow control and total volume control, plus local conditional orders such as stop loss, one-click cancel all, close positions and custom command types.

For a retail platform, the risk module and the unattended operation story are what make the project worth reading, since those are the parts a small team rarely builds.

Three backtest modes and a pro tier with factor analysis

The backtest side supports both bar and tick time scales, and three modes: lite, pro and batch.

Lite is the single instrument mode. Batch mode uses multiple processes to backtest different strategies on different contracts at the same time, which is what lets you combine strategies and look at combined returns. Pro mode supports backtesting any number of instruments at once, with a regular expression to determine the range of instrument names, and batch mode in that tier supports multi-process backtesting so you can split instruments apart for parallel, faster runs.

The results view is where the work shows. You get overall metrics such as return, Sharpe ratio and maximum drawdown, an equity curve, all trade details, daily details, buy and sell markers on the K-line, and a tick data view. Trades can be filtered by specified conditions, results can be exported to CSV and to images, and custom indicators can be displayed.

On top of that sit the parameter optimisation and analysis features: backtest parameter optimisation with screening, multi-process parameter optimisation, and genetic algorithm optimisation.

The Pro tier adds a specific set of things, and it is worth separating them from what is actually in the open repository. According to the README, the Pro features include multi-process parallel batch backtesting of different strategy combinations, filtering of backtest results by specified conditions, MongoDB reading and writing through pymongo in batch mode which it says is 2 to 10 times faster than the ordinary version, cursor mode for data reading to save memory, saving, reading and script mode for backtest results, distributed computing and optimisation, factor statistics and correlation analysis with batch factor generation and regression analysis for quick factor screening, vectorised fast backtest based on prediction models for intraday and overnight with separate test and training set evaluation, custom indicators including order flow, and tick level spread analysis between instrument combinations.

The open-source note is important: the currently open code has all the basic functionality from backtest to live trading and shows the system prototype and framework for secondary development, while the customised Pro code has only been partially opened and some features are not yet open.

Compiling the C++ core and starting the three processes

The build is a CMake build of the libraries under cppsrc, and it needs a set of system and third party libraries prepared in advance.

The system packages required are boost and libmongoc-1.0, and you either install or compile yourself the libraries in cppsrc: nanomsg 1.0, log4cplus 2.04, yaml-cpp, fmt 5.3 and ta-lib. The counter API dynamic libraries for CTP, TAP and the others have to be present as well, since the server links against them.

The build itself is the standard CMake sequence:

$ cd cppsrc
$ mkdir build
$ cd build
$ cmake ..
$ make

The development environments the project was built in are listed too, which is a reasonable guide to a working toolchain: Manjaro with the Arch kernel 4.14, Python 3.8 and gcc 9, Ubuntu 20.04, and Windows 10 with Visual Studio 2019. The Python side needs psutil, pyyaml, pyqt and qdarkstyle, with the exact list in the requirement.txt on the backtest branch.

Once the libraries are built, the executable apiserver.exe from cppsrc/build/StarQuant is copied to the main directory and run to start the server. The GUI is started by running gui.py, strategy.py starts a standalone strategy process, and recorder.py starts the market data recording process.

So the running system is at least three processes, and the separation is deliberate: the strategy process can be restarted or reloaded without touching the server, which is what makes the 24 hour unattended operation described in the README plausible.

Two conventions are documented for contributors, and they tell you what kind of codebase this is. C++ follows Google's C++ guide with cpplint for checking, Python is checked with flake8 and formatted with autopep8, and the naming rules are explicit: class names are CamelCase with no underscore characters, member variables are lower case with a trailing underscore as in data_, globals carry a g_ prefix, and functions are mixed case.

Data sources, paper trading and a Qt front end

The data side of the platform is complete enough to be useful on its own. Live market data subscription and storage for tick and bar data is supported, working like vnpy's data recorder in message queue mode as a separate process, and it also has vnpy's csv loader functionality, with bar and tick data import. In shared memory mode, the in-memory data is written to disk asynchronously, with a dedicated export and viewing script for processing and analysis. The project can also download data from several sources, naming RQData, Tushare and JoinQuant.

On top of live data there is paper brokerage, which is described as simulation trading based on live market data with simple matching, and the stated purpose is testing before going live.

The front end is a Qt visual interface, PyQt5 based, used for management, monitoring and operation. The README lists what it gives you: monitoring information that is recorded and can be exported to CSV, real-time K-line data, contract basic information, the ability to show or hide specific view widgets and adjust the view layout, and support for manual trading, strategy trading, and viewing order, position and account information. There is also a command line form, cli and tui, for monitoring.

One more feature stands out as a decision rather than a detail: the system supports WeChat real-time push and receive of information, through itchat or the ServerChan style service. For a trading system run on a cloud host with a phone in your pocket, that is a plausible way to get an alert, and it is also a dependency on a third party messaging channel that a regulated deployment would think hard about.

The overall shape is a desktop-style platform for one person, cross-platform on Linux and Windows, rather than a service for many users.

The licence question and the state of the repository

Two facts about the repository should be settled before you build anything on it.

The first is the licence. The licence badge in the README says MIT, while the repository listing records the licence as Apache-2.0, and the repository contains a LICENSE file. The README badge is also inconsistent with the fact that the project references vendor libraries, nanomsg, ta-lib, log4cplus, yaml-cpp and fmt, which carry their own terms, and the MongoDB and PyQt dependencies bring licensing questions of their own. The LICENSE file is the document to read, and the badge is decoration.

The second is the state of the code. There is one release tag, v1.0-alpha from 2019-07-13, and the last push was on 2026-07-04, so the repository is not archived and something is still moving, but the published artefact is seven years old. The work is spread across branches, with the backtest branch holding the 2022.10 backtest update and its requirement.txt, and the TODO section says the system has completed the 1.0 beta version, is in live testing, and is meanwhile improving the C++ backtest, the vectorised backtest and the command line interface.

The top level listing explains where the pieces live: cppsrc for the C++ server and libraries, gui.py, strategy.py and recorder.py as the three entry points, mystrategy/ and source/ for the strategy examples, demos/ for the recorded demonstrations, and etc/ for configuration. There is a README_eng.md alongside the main README, and the README itself points to a quantvs.code-workspace file, which suggests the project is developed in Visual Studio Code.

What you get is a complete, opinionated platform that one person built, with the documentation to match, and with the rough edges of a personal project that you inherit along with the code.

Editorial conclusion

StarQuant suits a developer who wants to own the whole path from backtest to live futures trading on a single machine or cloud host, and who is prepared to compile the C++ core, the vendor libraries and the counter APIs themselves. It is the wrong choice for a team that needs a supported release, a clear licence, or a strategy API it can migrate away from later, because the project is a personal platform with one 2019 tag and a licence that the README and the repository listing contradict. Verify first the licence by reading the LICENSE file, then confirm that the counter API you need, CTP for futures or XTP and OES for stocks, is one of the interfaces this build actually supports and that you have the vendor dynamic libraries it links against.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. physercoe/starquant on GitHub
4. README
5. Releases