VisualHFT: a WPF terminal that puts live Level 2 order books and microstructure studies on one screen

What the terminal is for, and the scope of the data

VisualHFT Terminal is described as the observability and decision terminal for quantitative and electronic trading desks, and the project description says the same thing more concretely: live Level 2 order books, microstructure analytics, and quantitative execution monitoring.

The What it does section is precise about the scope. It brings live order books and trades from supported venues into one desktop view, and it helps traders, quants and researchers examine depth, liquidity, order flow and market resilience while conditions are changing.

Level 2 is the important word, because it distinguishes this from a chart application. Level 2 data is the per-price order book, the full depth of resting bids and offers at each price level, not the top of book. A study that measures imbalance between the buy and sell sides is only meaningful if it can see the whole book, and that is why the repository's hero image is a full depth order book updating live with bid, ask, trade and study data rather than a price chart.

The built-in studies list is short and each name describes a specific microstructure measure. VPIN, which is the volume-synchronized probability of informed trading. LOB Imbalance, which the documentation describes as visualising changes in order-book pressure. Market Resilience, which is about how the book recovers after a shock rather than its steady state shape. And Order-to-Trade Ratio.

Two properties of the studies are worth calling out because they affect what you can build on top. The documentation says the connectors normalise live Level 2 order-book and trade updates for the dashboard and the study plugins, so every study sees the same normalised feed regardless of venue. And the study outputs can also drive trigger conditions that send alerts to the user interface or to configured REST endpoints, which turns the analytics into a monitoring system rather than only a display.

The trigger idea is the one that extends the reach of the tool. A study is not only something you look at, it is something that can fire an alert when a condition holds, and a REST endpoint target means the alert can go to a monitoring system outside the application.

The primary language is C#, the licence is Apache-2.0 with the LICENSE.txt at the repository root, the homepage is visualHFT.com, and the repository is not archived with the last push on 2026-10-05. There are no GitHub releases, so the CHANGELOG.md is the version history. The topic tags name the stack precisely: wpf, wpf-application, wpf-ui, mvvm, mvvm-architecture, limit-order-book, orderbook-tick-data, market-microstructure, tca and high-frequency analytics, and the platform badge in the README is Windows.

The build, and the forked plotting library you have to check out

The quickstart is short and one instruction in it is unusual enough to be worth reading twice.

The prerequisites are Windows, the .NET 10 SDK, and Visual Studio. Then: the VisualHFT OxyPlot fork, with both repositories placed in the same parent folder.

# Both repositories must sit in the same parent folder.
git clone https://github.com/visualHFT/oxyplot.git
git clone https://github.com/visualHFT/VisualHFT.git

The fork is not an optional suggestion. OxyPlot is the charting library, and the project maintains its own fork of it, and the build requires the fork to be present as a sibling directory of this repository. That is a relative path dependency resolved by convention rather than by a package reference, and it has a practical consequence: you cannot build this from a single clone, and if you update the fork you have to check that the terminal still works against it.

The build itself is Visual Studio. You open VisualHFT/VisualHFT.sln, build the solution, set VisualHFT as the startup project and press F5. The Dashboard opens first, and you select an available provider and a normalised symbol such as BTC/USD in the order-book panel.

That last detail is the design centre of the whole thing. The symbol is normalised, so BTC/USD rather than a venue specific ticker, and the provider is selected at runtime rather than compiled in. Which means the same application can connect to any of the supported venues and present them identically, and a normalised symbol is what makes the cross-venue comparison meaningful rather than a comparison of eight different tickers.

The repository listing shows the rest of the shape. There is App.xaml and App.xaml.cs for the WPF application entry point, MainWindow.xaml and MainWindow.xaml.cs, and then the View/, ViewModel/ and Model/ directories, which is the MVVM layout the topic tags name. VisualHFT.Commons/ and VisualHFT.Commons.WPF/ hold shared code, and VisualHFT.Plugins/ is the plugin surface.

The tooling is worth noting. There is a FodyWeavers.xml and a FodyWeavers.xsd, which is the configuration for the Fody weaving tool, used in .NET projects to inject code at compile time. log4net.config is the logging configuration, global.json pins the SDK version, and there is a VisualHFT.sln.bak, which is the kind of file that tells you the solution file has been edited by a tool at some point and a copy was taken.

The connectors, the simulators and the two extension points

The Included in this repository table is the concrete inventory of what you get, and the market data connectors are the first row: Binance, Bitfinex, Bitstamp, Coinbase, Gemini, Kraken, KuCoin, and a generic WebSocket connector.

Seven named venues plus a generic escape hatch is a sensible balance. The named ones give you a working connection immediately, and the generic WebSocket connector means a venue the project has not written an adapter for is not a blocker, as long as it speaks a WebSocket protocol you can map.

The second row is the built-in studies: VPIN, LOB Imbalance, Market Resilience and Order-to-Trade Ratio. The third row is extensibility, described as templates for additional market connectors and market-microstructure studies, and that row is what the extension section expands on.

There are two templates in the repository, SDK-MarketConnectorTemplate/ for a new market-data source and SDK-StudyTemplate/ for a custom market-microstructure calculation, each with a guide. The documentation gives the order of operations: read the architecture overview before extending the application, and use the matching template and guide before distributing a plugin.

That instruction is a good sign. A template without an architecture document is a starting point, and a template with one is a contract, and for something that plugs into a live trading terminal the difference in risk is large.

Two more directories in the listing complete the picture of what a trading terminal needs. Simulators/ suggests synthetic market data for development, which is the difference between a plugin you can test and one you can only test against a live feed. And TriggerEngine/ is the mechanism behind the trigger conditions and alerts that the study outputs can drive. demoTradingCore/ and WS_input_json/ suggest a demo execution core and sample WebSocket input files, which fits a project whose extension story includes feeding replayed data into the same pipeline the live feed uses.

PartnerQuantProgram.md at the root is a document for a partner program, which is a commercial signal about where the project intends to go. AnalyticReports/ and SQL scripts/ suggest reporting over the collected data, and UserSettings/ and UserControls/ are the ordinary WPF application furniture. PluginManager/ is how plugins are discovered and loaded.

The tests/ directory exists, and the project has a documented troubleshooting source in docs/troubleshooting.md, which is a small thing that saves a lot of time on a WPF application with a sibling-repository build dependency.

What the studies actually measure, and what a connector has to normalise

Two technical threads run through this project and they explain most of the design decisions: the studies that ship with it, and the normalisation problem every connector has to solve.

VPIN is the most demanding of the four to implement, because it is not a simple aggregation. It is the volume-synchronized probability of informed trading, and the defining feature of the measure is that it synchronises on volume rather than on time. The implication for a connector is that the trade and order book feeds have to arrive in an order the calculation can consume, and that a venue delivering updates in a different sequence can change the result. That is a property of the algorithm, not a defect in the implementation, but it means the normalisation layer is doing more than renaming fields.

LOB Imbalance is the simplest to reason about and the one whose name tells you the input. It measures the pressure between the two sides of the book at a given moment, and the documentation describes it as visualising changes in order-book pressure. The interesting part is the word changes, because an imbalance level is only useful as a time series, which is why the visualisation is a chart of the imbalance rather than a number.

Market Resilience is a different question again, and the one a trader would most want answered in a stressed market. It is about how the book recovers rather than how it looks, which means it needs the history of the book and not just the current state, and it is the study most likely to behave differently across venues because the recovery depends on the venue's own matching and cancellation behaviour.

Order-to-Trade Ratio is the execution-facing one. It relates order flow to trades, and in a context with quantitative execution monitoring and transaction cost analysis in the topic tags, it is the study that connects market structure to your own fills.

Now the connector side, which is where the real engineering sits. Each venue publishes its own Level 2 feed with its own message format, its own sequencing model, its own way of expressing that an order was modified rather than cancelled, and its own view of when a trade happened relative to the order updates. Normalising all of that into one stream that the studies can consume is the work, and it is why the connector list is a list of substantial pieces of code rather than configuration.

The generic WebSocket connector is the escape hatch for a venue nobody has written an adapter for, and the template directory is there so that a desk writing one follows the same shape as the built-in ones. The output of that work is a study that behaves the same way whether the data came from Binance or from a desk's own internal feed, and that consistency is what makes the cross-venue comparison in the dashboard worth having.

The licence, and what a desk has to think about

VisualHFT is licensed under the Apache License 2.0, with the text in LICENSE.txt, and for a project that is explicitly aimed at commercial trading desks that is the important practical detail.

Apache-2.0 grants broad use including commercial use, modification and redistribution, and its significant obligations are the notice and licence file and the patent grant. For a proprietary desk tool built by embedding or extending VisualHFT, the licence permits it, and the obligation is attribution in the distribution.

What the licence does not do is make the data free. A Level 2 feed from any of the seven named venues comes from an exchange under its own agreement, and the connector is the piece that has to respect that agreement. Nothing in the repository tells you what each venue permits, so a desk running this in production is the one that has to check the exchange terms for the data it consumes.

The second thing to think about is the operational shape. This is a WPF application on Windows, which means it is a desktop application on a trader's machine, not a service. The good property of that is that a Level 2 feed is high bandwidth and the display is local. The consequence is that the tool is per-user rather than shared, which changes how you run it across a desk and how you distribute a custom connector to other people.

The third is the build coupling again, but from an operational angle. Because the OxyPlot fork has to sit next to the repository, a desk that wants to build this reproducibly has to manage two checkouts in lockstep, and a desk that wants to package the built binaries for its traders needs to do that packaging itself, since the project publishes no releases. The repository publishes no GitHub releases at all, and the README says the README describes the functionality included in the public repository today, with the roadmap hosted on the project site and the dated changes in CHANGELOG.md.

There is also a documentation split to be aware of. The website carries the documentation, the docs/ directory holds the OSS doc sources, and the architecture document lives at docs/architecture.md. The community is on Discord and GitHub Discussions, and the project also runs a Connect programme, a Substack and social accounts for research and updates.

Editorial conclusion

VisualHFT fits a quantitative or trading team that wants a single desktop view of live depth and liquidity across several venues, with studies they can read and extend, and that accepts a Windows only, WPF only deployment. It is the wrong tool if you need a headless or Linux system, since the platform is Windows and the interface is WPF, and it is the wrong choice if your requirement is a research environment rather than a monitoring terminal. Before adopting, read docs/architecture.md, because the extension templates assume you understand the layering, and plan for the fact that the plotting library is a fork that has to sit in the same parent folder as this repository, which is a build coupling you will have to keep in step.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. visualHFT/VisualHFT on GitHub