trade-frame is a C++ trading library where option combos are the unit of work

A library for market data in and orders out, plus the projects using it

The project describes itself as two things at once. It is a library of functions to sink market data, organize time series, build indicators, author algorithms, and issue orders to a broker for high capacity, low latency trading applications, and it is a collection of projects using those libraries to carry out various manual and automated trading scenarios. That split explains the repository layout, which is mostly directories of sample applications. The data side is DTN IQFeed, a real time feed, and the execution side is the Interactive Brokers TWS API, with the project description also naming Alpaca and Phemex support, a libtorch, LSTM and CUDA demo, and Telegram notifications. The topic tags tell the same story, adding hdf5 for time series storage, luajit for the runtime and option pricing and greeks work. For an engineer, the useful question is which of those directories is a template and which is a working example, and the README answers that one directly by naming AutoTrade as the project to use as a template for building your own automated high frequency trading application.

The option combo is the unit of work, not the leg

The primary goal of the whole solution is stated plainly: to provide a means of tracking an Option Combo Order through the birth to death life cycle. The motivation is given too. It is easy to enter into an option combo with Interactive Brokers through their user interface, but there does not seem to be an effective way to keep the legs grouped for tracking overall profit and loss. That is the gap the library fills, and it is a bookkeeping gap rather than an execution gap, which is why it is worth having a library at all. The object model follows from it. The library provides a means of tracking a Combo, its Leg and its Position, and positions can be grouped together to form Portfolios, with portfolios representing combos grouped together to represent the overall profit and loss of a trading portfolio. The classes live in dedicated directories, TFTrading for orders, positions, portfolios and instruments, and TFOptionCombos for the combo and leg types.

A position is a Watch over an instrument, and options extend it

The lower level of the model is small and deliberate. Positions are composed of a Watch class to record bid, ask and tick of Instruments, which means the position is not just a quantity but a live view of the market for the thing you hold. Options inherit from the Watch class to provide Greeks, and those are computed in real time with an Option Engine, so the position knows its delta, gamma and the rest as the market moves rather than only at fill time. The TFTimeSeries library holds the dated data those computations read, and the option-pricing work has its own TFOptions directory. The design point worth taking away is that the risk numbers are a property of the position object, not a separate report you generate, which is what makes a combo's overall profit and loss something you can watch while the trade is open rather than reconstruct afterwards.

The simulator exists because fills are the hard part

A Simulation Interface is provided for testing strategies off-line, and the README describes its contract precisely. The simulator will accept Orders of type Market and Limit assuming bid and ask data has been captured from the exchange during a live session, and a 50ms to 100ms delay queue has been implemented to better simulate round-trip and slippage effects of order submission. That is a narrow but honest design. It does not invent a market, it replays what really traded, and it makes you wait, because a strategy that assumes instant fills against a live bid and ask is a strategy that will look better in backtest than in production. The captured-data requirement is also a workflow constraint: you need a live session, and a recording, before you can test the next iteration offline. The TestSimulator and dbtest directories in the repository are where that machinery lives.

The build is a Debian, Wine and ten gigabyte proposition

The build environment section sets expectations. A C++17 compiler is used, CMake handles the build, and the project was originally built on Windows a number of years ago but the focus changed towards supporting Linux, with some work needed to make it build on Windows again. Debian is the platform, and the README warns the library installer is specific to that distribution and may or may not work with other distributions or flavours. You will need about 10G of drive space for the libraries and the installs, and the notes record a modification on 2026/09/17 to use boost 1.92 and wxWidgets 3.2.11. The data feed is the awkward part, because DTN and IQFeed require Wine to run, and starting with the 6.2 release of IQFeed wine32 is no longer required, though an x64 only installation may still print wine32 messages that can be ignored. The first steps of the build sequence look like this:

# run with bash
# git for latest code, wine for IQFeed daemon
sudo apt-get update && sudo apt-get install git wine64 wget ttf-mscorefonts-installer
wget http://www.iqfeed.net/iqfeed_client_6_2_0_25.exe
wine64 iqfeed_client_6_2_0_25.exe

# interactive brokers TWS for linux
wget https://download2.interactivebrokers.com/installers/tws/stable/tws-stable-linux-x64.sh
sh tws-stable-linux-x64.sh

The main code is then cloned and built with CMake, and the README notes that if you load the folder into VS Code the manual build is not required:

# main trade-frame code
git clone https://github.com/rburkholder/trade-frame.git
# if you have access to the up-to-date private library, use this instead:
# git clone https://github.com/rburkholder/tf2.git

# if you build manually (this is not required if you load the folder into vscode):
cd trade-frame
mkdir build
cd build
cmake ..
# use parallel to use more cpu cores
cmake --build . --parallel 4 --config Debug

The portability flag is a deliberate trade

One line in the build notes deserves to be read twice. The use of -march=native in the root CMakeLists.txt will cause code to be not necessarily transportable across CPU types, and the instruction is to comment out the option if you intend to compile across CPU types, for example various releases of the Intel instruction set. For a project whose whole point is low latency on the machine you trade from, that is a rational choice, since letting the compiler emit the newest instructions your processor supports is where the last few percent come from. It also means a binary built on one machine may not run on an older one, and a build intended for a cluster has to be compiled per node type. The build notes are also dated, recorded as of 2021/11/22, and there are wxWidgets requirements for using a GTK variation of video drivers, which the author says has worked with Nvidia and Radeon cards.

Bringing up the data feed and the broker session

The startup section is a checklist for two external systems. The IQFeed daemon is started from the wine application menu or from the command line with the autoconnect switch, and you log in with your credentials, ticking the Save Username and Password and Autoconnect boxes the first time. Interactive Brokers TWS is started and connected to a paper trading account, and the README is emphatic about the first point: do not use an active account for testing. When connecting via an application you also have to enable the API in the settings and activate the port. Then the data preparation projects run. IQFeedMarketSymbols spends a few minutes downloading, parsing and saving the latest symbol list, and the README says lots of messages will be generated and there is no need to evaluate them other than the summary stats at the end. IQFeedGetHistory obtains daily OHLC values used to refresh data, repeating the symbol download, and it expects the IQFeed daemon to be running first.

Maintenance signals are mixed, and the licence is unusual

The repository is not archived and the last push was on 2026-10-13, so the code is being touched, and the 2026/09/17 note about moving to boost 1.92 and wxWidgets 3.2.11 shows dependency maintenance happening. But there are no GitHub releases, and the build notes inside the README are dated 2021/11/22, so the difference between what the project does now and what its documentation describes is wide. The directory listing also shows a long period of accumulated work, with dozens of sample applications such as ComboTrading, CurrencyTrader, OptionTrader, OverUnderConsole, HedgedBollinger, WebTrader, Scanner, OptimizeStrategy, Alpaca and Phemex, and a TradeFrame.sln that points back to the original Windows era. The licence deserves attention: GitHub could not classify it and points to the LICENSE file, and the repository root carries both LICENSE.txt and gpl3.txt, so read both before you reuse any of the code in something commercial.

Editorial conclusion

Adopt trade-frame if you are writing a low latency strategy in C++ that trades multi-leg option combos and need the legs grouped with a single profit and loss figure, since that is the specific problem the library was built around, and if you already have IQFeed or a broker session on Linux. Do not adopt it to prototype quickly, because the build is a native dependency chain with about ten gigabytes of disk, a Wine hosted data feed and a Debian specific installer, and the samples around it are years old in places. Before you start, read the build notes and the -march=native caveat, confirm the IQFeed and TWS credentials you need, and check the licence file, since the repository carries both a LICENSE.txt and a gpl3.txt.

Frequently asked questions

Official sources

1. Issues
2. rburkholder/trade-frame on GitHub
3. README