openctp: CTPAPI-Compatible Gateways for Broker Counter Systems and a 7x24 Simulated Trading Environment

The problem openctp addresses: one API, many broker counters

CTP is the counter system developed by a technology company under the Shanghai Futures Exchange, and the README describes CTPAPI as the interface to it. The README also states that CTP is the counter domestic investors prefer, and that its API is the one most quantitative trading code is written against. That creates a practical problem. A trader with a working CTP strategy who wants to route orders through China Merchants Securities XTP, Huaxin Securities TORA, East Money EMT, Orient Securities OST, Interactive Brokers TWS, Esunny TAP or Liangtou QDP has to rewrite the order and market data layer for each counter, because each exposes its own API.

openctp's answer is to implement the CTPAPI surface on top of each of those counters. The repository is organised as one top-level directory per counter: XTP-CTPAPI, TORA-CTPAPI, EMT-CTPAPI, OST-CTPAPI, IB-CTPAPI, QDP-CTPAPI, TAP-CTPAPI, FEMAS-CTPAPI, YD-CTPAPI, TORA_OPT-CTPAPI, CTPOPT-CTPAPI, TTS-CTPAPI and TTS-CTPOPT. The intended audience is a developer who already has CTP code and wants to keep it, not someone starting from scratch who wants a clean modern API. That is the whole value proposition, and it is a narrow one.

The repository also lists language bindings under ctpapi-python, ctpapi-java, ctpapi-go, ctpapi-c, ctpapi-rust and ctpapi-csharp, plus ctpopt-python for the stock option API. Those bindings matter more than the gateway directories for most readers, because they determine whether you can stay in your own language instead of writing C++ against the C interface.

How the compatibility layer and the TTS simulated environment fit together

There are two distinct mechanisms in this repository, and conflating them causes confusion.

The first is API translation. Each *-CTPAPI directory implements the CTPAPI request and callback model on top of a different counter. Your code calls the CTPAPI functions it already calls; the layer translates those into the broker's native protocol and translates the responses back into CTPAPI callbacks. The README does not describe the internal translation design for each counter, so the depth of compatibility per counter is something you have to verify by reading the individual directory and its documentation rather than trusting a single compatibility claim across all of them.

The second mechanism is the simulated environment. openctp runs a TTS-based simulation and exposes it through the same CTPAPI-compatible interface, in TTS-CTPAPI and TTS-CTPOPT. The README states there are three simulated environments: a 7x24 environment, a simulation environment, and a VIP simulation environment. It says these cover domestic futures and options across exchanges, plus A-share stocks, funds, bonds, stock options, and Hong Kong and US markets. The README positions this as a replacement for SimNow and notes 7x24 availability. That availability claim is the concrete differentiator: a developer testing outside Chinese trading hours does not have to wait for a maintenance window.

Two smaller pieces sit alongside these. The data centre exposes domestic futures, commodity options and stock options reference data through what the README calls a minimal RESTful interface returning JSON, with no registration and no access restrictions. The QQ-CTPAPI and SINA-CTPAPI directories provide market data interfaces for Tencent and Sina, and the README notes these two include source code, which is not stated for the broker gateway directories.

Getting the Python binding and reaching a first simulated session

The README points to the ctpapi-python directory in the repository and to a separate repository, openctp-ctp-python, for the Python interface to CTPAPI. It does not give a pip install line, so the path it describes is fetching the Python interface from that repository.

git clone https://github.com/openctp/openctp-ctp-python

That is the only command the README supports for obtaining the binding. It does not document a wheel, a version number or a supported Python version range, so treat the build as source-based until you confirm otherwise in that repository.

For the simulated environment, the README directs you to the simulated trading environment page at openctp.cn/Trading.html for connection details. It does not reproduce the front addresses, broker IDs or credentials in the README itself, and it does not give a code sample for logging in. The repository does contain demo programs, and demo/ctpprint and demo/ctpoptprint are the ones named for printing CTP and CTP stock option data respectively, with demo/prices and demo/settlement_parser.py also present. The README names demo/README.md as the starting point for those programs, so read that file before running anything.

The honest summary is that the first-run path runs through the demo directory and the website, not through the README. If you want a copy-paste login example, this repository does not provide one in the README, and the Trading.html page is where the connection parameters live.

Where the compatibility approach breaks down

The compatibility layer is only as complete as the counter's own API allows. A broker counter that does not expose a particular order type, a particular query, or a particular callback cannot be made to behave like CTP at that point. The README makes no per-counter compatibility matrix, so a claim of CTPAPI compatibility for XTP and a claim for TAP are presented with equal confidence even though the underlying counters differ substantially. That is the single biggest gap in the documentation, and it is a gap you discover in testing rather than in reading.

There is a versioning problem too. CTPAPI itself has evolved, and the README mentions a file named CTP接口扩展说明.md at the top level, which suggests extensions beyond the base interface. The README does not state which CTPAPI version each gateway targets. If your strategy depends on a field or a function added in a later CTPAPI revision, you need to confirm the gateway implements it.

Latency is the other trade-off. Going through a translation layer adds a hop between your code and the counter. For strategies where queue position or microsecond timing matters, a native broker API is the correct choice and openctp is the wrong tool. The README makes no latency claims, and none should be inferred.

Finally, the repository has no retrieved releases. There is no changelog in the README, and the README does not document a rollback path if a gateway update breaks your build. The last push to the repository was on 2026-07-29, so the code is recent, but recency of the repository as a whole says nothing about whether a specific gateway directory is current.

Alternatives and how their approach differs

The README itself recommends LocalCTP, described there as an embedded simulated trading environment compatible with the CTPAPI interface, with no server component, supporting futures, options and combination contracts across the market, FAK and FOK orders, conditional orders, backtesting and settlement statements. The difference from openctp's simulated environment is architectural: LocalCTP runs inside your process with no server to connect to, while openctp's TTS-based environments are remote services you log into. If you want deterministic, offline, repeatable test runs in CI, the embedded model is easier to reason about. If you want a shared environment that behaves like a live counter, the remote model is closer to production.

For the framework layer above the API, the README lists VeighNa, QUANTAXIS and WonderTrader. These solve a different problem: they are trading frameworks that consume a CTP-style API rather than provide one. Choosing between them is orthogonal to choosing openctp, and you can run any of them on top of an openctp gateway if the interface matches.

ctpbee is listed as a futures live-trading framework supporting both ctp and ctp_mini, and MT5CTP connects the MT5 client directly to futures company CTP counters. Both are narrower in counter coverage than the openctp gateway set, which spans equities, equity options, futures, options and overseas markets through TWS. The trade-off is the usual one: broad counter coverage comes with per-counter depth that you have to check individually.

Maintenance, upgrade cost and the BSD-3-Clause licence

The repository is not archived and the last push was on 2026-07-29. That is a recent push, but it is a single signal about the repository as a whole. Because the tree is a set of independent subprojects, a push to one directory does not tell you anything about the others. If you depend on TORA-CTPAPI, check that directory's history, not the repository's.

Upgrade cost is driven by two external factors the project does not control. The first is CTPAPI itself: if the upstream interface changes, each gateway has to follow. The second is the broker counters: XTP, TORA, EMT, OST, TAP and QDP each release their own API versions, and a gateway has to track them. Neither tracking obligation is documented in the README, so budgeting for it is guesswork until you read the individual directories.

The licence is BSD-3-Clause, per the LICENSE file at the repository root. BSD-3-Clause is permissive and typically allows commercial use and modification provided the copyright notice and disclaimer are retained, but the README does not state whether every subdirectory carries the same terms, and the README does not discuss licensing at all. If you are shipping a product that embeds a gateway, read the LICENSE file and check the headers in the specific directory you are building. That is a factual check, not legal advice, and for a commercial deployment the terms should go to whoever handles licensing at your organisation.

Editorial conclusion

Adopt openctp if you already have CTP-based trading code and need to point it at a broker counter that does not speak CTP, or if you need a simulated environment that is available outside SimNow's session windows. Do not adopt it if you need a documented, versioned release process: the README does not describe one, and the repository is a collection of per-counter subprojects with separate maturity levels. Before writing any code, verify which counters and which language bindings are actually populated in the tree, and confirm the licence file at LICENSE covers the subdirectory you intend to build.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. openctp/openctp on GitHub
4. Project website
5. README