-[Quickstart](#quickstart) · [Write a plugin](#write-a-plugin) · [Architecture](docs/architecture.md) · [Changelog](CHANGELOG.md) · [Contributing](CONTRIBUTING.md)
-
-## What it is
-
-VisualHFT shows live order books and trades from supported venues in one desktop application. It gives traders, quants, and researchers a direct view of depth, liquidity, order flow, and market resilience while the market is moving.
+
-## What you can see
+## What it does
-| Order book | Studies | Extensions |
-| --- | --- | --- |
-| Follow depth, trades, spreads, and venue conditions in one view. | Watch VPIN, LOB Imbalance, Market Resilience, and Order-to-Trade Ratio as conditions change. | Add a market connector or study for the data and measures you need. |
+VisualHFT brings live order books and trades from supported venues into one desktop view. It helps traders, quants, and researchers examine depth, liquidity, order flow, and market resilience while conditions are changing.
-
+| Live order book | Built-in study |
+| --- | --- |
+|  |  |
## Quickstart
@@ -41,60 +59,34 @@ Open `VisualHFT/VisualHFT.sln` in Visual Studio and build the solution. Set `Vis
Need help with setup? See [Troubleshooting](docs/troubleshooting.md) or ask in [Discord](https://visualhft.com/discord).
-## Supported venues and studies
+## Included in this repository
-| Type | Included examples |
+| Area | Included examples |
| --- | --- |
| Market data connectors | Binance, Bitfinex, Bitstamp, Coinbase, Gemini, Kraken, KuCoin, and a generic WebSocket connector |
| Built-in studies | VPIN, LOB Imbalance, Market Resilience, and Order-to-Trade Ratio |
+| Extensibility | Templates for additional market connectors and market-microstructure studies |
-## What it does
-
-- Normalises live Level 2 order book and trade updates from supported connectors.
-- Displays depth, trades, spreads, liquidity changes, and study outputs in one desktop view.
-- Computes market microstructure metrics through included study plugins.
-- Runs trigger conditions and sends alerts to the UI or REST endpoints.
-- Supports additional connectors and studies without changes to the core application.
+Connectors normalise live Level 2 order-book and trade updates for the dashboard and study plugins. Study outputs can also drive trigger conditions that send alerts to the user interface or configured REST endpoints.
-## Screenshots
+## Extend VisualHFT
-
-Open the current dashboard views
-
-| Depth | Limit order book |
-| --- | --- |
-|  |  |
-
-
-
-## How it works
-
-Connectors publish normalised market data to VisualHFT. The dashboard and study plugins read that data and update the live view. See the [architecture overview](docs/architecture.md) for the component map and data flow.
-
-## Write a plugin
-
-VisualHFT has two extension templates:
+VisualHFT has templates and guides for two extension points:
- [Market connector template](SDK-MarketConnectorTemplate/) for a new market-data source.
- [Study template](SDK-StudyTemplate/) for a custom market-microstructure calculation.
-Use the matching template and guide. Plugin authors should also review `RequiredLicenseLevel` before distributing a plugin.
-
-## Roadmap
+Read the [architecture overview](docs/architecture.md) before extending the application. Use the matching template and guide before distributing a plugin.
-See the [project roadmap](https://visualhft.com/#roadmap) for planned work. This README describes only functionality included in the public repository today.
+## Community and updates
-## Changelog
+Ask questions in [Discord](https://visualhft.com/discord) or [GitHub Discussions](https://github.com/visualHFT/VisualHFT/discussions). Report bugs and feature requests through [GitHub Issues](https://github.com/visualHFT/VisualHFT/issues).
-See [CHANGELOG.md](CHANGELOG.md) for changes by date.
+Follow [VisualHFT Connect](https://visualhft.com/connect), [LinkedIn](https://www.linkedin.com/company/visualhft/), [X](https://x.com/visualHFT), and [Substack](https://visualhft.substack.com) for research and project updates. See [CONTRIBUTING.md](CONTRIBUTING.md) to contribute code or documentation.
-## Community and contributing
+## Roadmap and changes
-- **Questions and live discussion:** [VisualHFT Discord](https://visualhft.com/discord)
-- **Ideas and project discussion:** [GitHub Discussions](https://github.com/visualHFT/VisualHFT/discussions)
-- **Bugs and feature requests:** [GitHub Issues](https://github.com/visualHFT/VisualHFT/issues)
-- **Research and updates:** [VisualHFT Connect](https://visualhft.com/connect)
-- **Code and documentation contributions:** [CONTRIBUTING.md](CONTRIBUTING.md)
+See the [project roadmap](https://visualhft.com/#roadmap) for planned work and [CHANGELOG.md](CHANGELOG.md) for dated changes. This README describes functionality included in the public repository today.
## License
diff --git a/assets/brand/visualhft-wordmark-dark.png b/assets/brand/visualhft-wordmark-dark.png
new file mode 100644
index 00000000..31d65774
Binary files /dev/null and b/assets/brand/visualhft-wordmark-dark.png differ
diff --git a/assets/brand/visualhft-wordmark-light.png b/assets/brand/visualhft-wordmark-light.png
new file mode 100644
index 00000000..85290637
Binary files /dev/null and b/assets/brand/visualhft-wordmark-light.png differ
diff --git a/docs/architecture.md b/docs/architecture.md
index e2192d35..c55f626b 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,43 +1,73 @@
# Architecture overview
-VisualHFT is a Windows desktop application built around a shared market-data layer and independently loadable plugins.
-
-```text
-Market connector plugins
- ↓
-Normalised OrderBook and Trade models
- ↓
-Shared helper services
- ↓
-Dashboard and study plugins
- ↓
-Charts, metrics, triggers, and alerts
+VisualHFT is a Windows desktop application that turns live venue data into a shared market-data view, analytical studies, and configurable trigger actions. This page describes the open-source repository as it runs today.
+
+## System at a glance
+
+```mermaid
+flowchart LR
+ A[Venue feed] --> B[Connector plugin]
+ B --> C[Normalised market models]
+ C --> D[Shared helpers]
+ D --> E[Dashboard view models]
+ D --> F[Study plugins]
+ F --> G[BaseStudyModel results]
+ G --> H[Charts and tiles]
+ G --> I[Trigger engine]
+ I --> J[Configured UI or REST actions]
```
-## Main components
+## Components and dependency boundaries
### Desktop host
-The `VisualHFT` project is the WPF desktop host. It owns the dashboard, plugin-management views, trigger configuration, and application startup.
+The `VisualHFT` project is the WPF application. It starts the application, loads and starts plugins, hosts the dashboard, and owns trigger configuration and the trigger engine.
-### Shared core
+### Shared libraries
-`VisualHFT.Commons` contains shared models, helpers, plugin base classes, and contracts. `VisualHFT.Commons.WPF` contains reusable WPF-specific behavior.
+`VisualHFT.Commons` contains the shared market models, helper publishers, plugin contracts, and plugin base classes. It does not depend on WPF.
-### Market connector plugins
+`VisualHFT.Commons.WPF` contains reusable WPF support and depends on `VisualHFT.Commons`. The desktop host can use both libraries.
-Connectors derive from `BasePluginDataRetriever`. They connect to a venue, map its symbols into the configured normalised form, and publish `OrderBook` and `Trade` updates with `RaiseOnDataReceived(...)`.
+### Plugins
-### Study plugins
+Connector and study assemblies use the shared contracts. A connector derives from `BasePluginDataRetriever`. A study derives from `BasePluginStudy`. Built-in plugins are included as project references by the host so their assemblies are copied beside the application for runtime discovery.
-Studies derive from `BasePluginStudy`. They subscribe to shared market data, perform their calculation away from the incoming data callback, and publish `BaseStudyModel` values with `AddCalculation(...)`.
+## Market-data path
-## Plugin discovery
+A connector receives a venue-specific feed, maps it into VisualHFT's normalised models, and publishes updates through `RaiseOnDataReceived(...)`. Order books, trades, providers, and symbols are delivered by the corresponding shared helper.
-At startup, `PluginManager.LoadPlugins()` scans the directory that contains `VisualHFT.exe` for DLLs. It loads non-abstract types that implement `IPlugin` and that meet their declared `RequiredLicenseLevel`. There is no separate plugin folder.
+Dashboard view models and study plugins subscribe to the same helpers. The helper callbacks are synchronous. A subscriber must finish quickly and must not retain the mutable `OrderBook` it receives.
-For a new connector or study, start with the [extension templates](extending/README.md).
+## Study results and triggers
-## Interactive reference
+Studies decide how to process their input. A short calculation can run in a helper callback. A study that needs to keep an order-book state or do longer work can take an `OrderBookSnapshot`, queue that work, and dispose the snapshot when it is finished.
-The existing [interactive architecture map](system-architecture.html) provides a visual companion to this overview.
+`BasePluginStudy.AddCalculation(...)` sends a `BaseStudyModel` through the study's aggregation and result path, then raises `OnCalculated`. The plugin manager registers single-study results with the trigger engine. The dashboard consumes the same study output for live tiles and charts.
+
+This is deliberately not a claim that every study uses a queue or snapshot. For example, the VPIN study processes its configured trade and order-book callbacks directly, while the Market Resilience study snapshots order books before queued processing.
+
+## Plugin discovery and lifecycle
+
+At startup, `PluginManager.LoadPlugins()` scans the directory containing `VisualHFT.exe` for DLLs. It creates non-abstract exported types that implement `IPlugin`, then starts the applicable connector, study, or multi-study lifecycle.
+
+For a source build, add an extension project as a `ProjectReference` to `VisualHFT.csproj`. Its output must be copied next to the application executable for the runtime loader to discover it. Discovery loads assemblies in the application process. It is not a process-isolation boundary.
+
+## Extending VisualHFT
+
+Start from the public templates:
+
+- [Market connector template](../SDK-MarketConnectorTemplate/MarketConnectorSDK_Guidelines.md)
+- [Study template](../SDK-StudyTemplate/StudySDK_Guidelines.md)
+- [Extension guide](extending/README.md)
+
+## Source map
+
+- [Application startup](../App.xaml.cs)
+- [Plugin discovery and lifecycle](../PluginManager/PluginManager.cs)
+- [Connector publish contract](../VisualHFT.Commons/PluginManager/BasePluginDataRetriever.cs)
+- [Study result contract](../VisualHFT.Commons/PluginManager/BasePluginStudy.cs)
+- [Order-book callback helper](../VisualHFT.Commons/Helpers/HelperOrderBook.cs)
+- [Disposable order-book snapshot](../VisualHFT.Commons/Model/OrderBookSnapshot.cs)
+
+For a visual companion, see the [interactive architecture map](system-architecture.html).
diff --git a/docs/extending/README.md b/docs/extending/README.md
index 38ea5559..8b294cf6 100644
--- a/docs/extending/README.md
+++ b/docs/extending/README.md
@@ -13,12 +13,4 @@ Both templates compile against the current shared plugin APIs. Follow the linked
VisualHFT discovers plugin DLLs in the directory that contains `VisualHFT.exe`. For a source build, add the extension project as a `ProjectReference` in `VisualHFT.csproj`, then rebuild the solution. No manual registration is required.
-## License level
-
-`IPlugin.RequiredLicenseLevel` is checked when VisualHFT loads a plugin. The public base classes default to `eLicenseLevel.COMMUNITY`. Keep that default, or explicitly return it, for a plugin intended for this public repository.
-
-```csharp
-public override eLicenseLevel RequiredLicenseLevel => eLicenseLevel.COMMUNITY;
-```
-
See the [architecture overview](../architecture.md) for the data flow and plugin boundary.
diff --git a/docs/system-architecture.html b/docs/system-architecture.html
index 727c1396..896aded8 100644
--- a/docs/system-architecture.html
+++ b/docs/system-architecture.html
@@ -5,7 +5,6 @@
VisualHFT: Interactive Architectural Blueprint
-
@@ -51,28 +50,28 @@
VisualHFT: The Architecture (
-
System Architecture: The Three Tiers
+
System Architecture
-
1. Presentation Layer (WPF)
-
The user-facing GUI, built with a strict MVVM pattern. Views (`.xaml`) are decoupled from logic (`ViewModels`), with data binding automated by Fody for clean, maintainable code.
+
1. Desktop host
+
The WPF application starts VisualHFT, hosts the dashboard, loads plugins, and owns the trigger-engine configuration.
-
2. Core Services Engine
-
The central nervous system. Manages the plugin lifecycle (`PluginManager`) and orchestrates data flow via a high-speed, in-memory Pub/Sub data bus (`Helper` classes).
+
2. Shared libraries
+
VisualHFT.Commons owns shared models, helpers, and plugin contracts. VisualHFT.Commons.WPF adds reusable WPF support on top of Commons.
-
3. Plugin Ecosystem
-
Dynamically loaded DLLs that extend functionality. `Data Retrievers` connect to external sources, while `Studies` perform complex, real-time analytics.
+
3. Plugin assemblies
+
Connector plugins ingest venue data. Study plugins calculate live analytics. Both use the shared contracts and are discovered beside the application executable.
-
Real-Time Data Flow: The Pub/Sub Bus
+
Market Data and Results
-
Data flows unidirectionally from producers to consumers via a decoupled, event-driven bus implemented with singleton `Helper` classes. This ensures modularity and real-time responsiveness.
+
Connectors publish normalised order books, trades, providers, and symbols through their matching shared helpers. Dashboard view models and studies subscribe to those helpers. Studies emit BaseStudyModel results for live views and trigger evaluation.
🔌
@@ -82,14 +81,14 @@
Real-Time Data F
→
🚌
-
Data Bus
-
`Helper` Class
+
Shared Helpers
+
OrderBook, Trade, Provider, Symbol
→
📈
Consumers
-
UI & Study Plugins
+
Dashboard and study plugins
@@ -101,24 +100,24 @@
Core Engine: Hig
-
Concurrency: decoupled processing
-
Connectors publish normalized market data through shared helper services. Studies use their own processing queues and snapshots so calculations do not block incoming market-data callbacks.
+
Callback ownership
+
Order-book and trade helpers invoke subscribers synchronously. A subscriber must return quickly and must not retain the mutable OrderBook from the callback.
-
Memory Management: Custom Object Pools
-
To minimize Garbage Collector (GC) pressure and prevent unpredictable latency spikes, the platform implements custom object pools. Frequently used objects like `Trade` and `OrderBookUpdate` are recycled instead of being newly allocated, dramatically reducing memory churn.
+
Snapshot when work outlives the callback
+
A consumer that needs an independent book state can create an OrderBookSnapshot. It rents storage for copied book items and must be disposed after use.
Optimized LOB Data Structure
-
Order books are updated in place as market data arrives. Plugins that need to process data away from the incoming callback use an independent snapshot.
+
Order books are updated in place as market data arrives. Queues and snapshots are opt-in consumer choices, not a universal study implementation.
-
1. Incoming update: an `OrderBook` is updated by its connector.
+
1. Incoming update: a connector updates a normalised OrderBook.
// connector code owns the venue-specific delta logic
-
2. Shared view: helper services publish the updated book.
-
// dashboard and studies subscribe to the same normalized data
-
3. Study work: a study takes a disposable `OrderBookSnapshot`.
-
// calculations run outside the data-feed callback
+
2. Shared view:HelperOrderBook calls dashboard and study subscribers.
+
// callback work must remain short
+
3. Longer work: a consumer creates and later disposes an OrderBookSnapshot.
+
// snapshot and queue use are per-consumer decisions
@@ -128,15 +127,15 @@
Optimized LOB Data Structure
The Plugin Ecosystem: A Framework for Extensibility
-
The `PluginManager` orchestrates the ecosystem. At startup, it scans the directory containing `VisualHFT.exe`, uses reflection to find non-abstract types implementing `IPlugin`, and manages their lifecycle (`StartAsync`, `StopAsync`).
+
At startup, PluginManager scans the directory containing VisualHFT.exe, finds non-abstract exported types implementing IPlugin, and starts the applicable connector, study, or multi-study lifecycle.
Data Retriever Plugin
-
Connects to a data source (e.g., FIX, WebSocket), parses the native format, and publishes standardized `Model` objects to the data bus.
+
Connects to a venue, maps its native messages into normalised market models, and publishes those models through the matching shared helpers.
Study Plugin
-
Subscribes to data from the bus, performs calculations (e.g., VPIN, Imbalance) in a separate thread, and publishes results back to the bus.
+
Subscribes to shared data, calculates its metric, and sends BaseStudyModel output through AddCalculation(...) and OnCalculated.
@@ -146,26 +145,26 @@
Study Plugin
Anatomy of a Study: VPIN Implementation
-
A `VPINStudy` plugin demonstrates the platform's analytical power. It's a stateful, event-driven component that processes raw trades into a sophisticated microstructure indicator.
+
A VPINStudy plugin demonstrates the platform's analytical power. It is a stateful, event-driven component that processes raw trades into a microstructure indicator.
-
1
Subscribe to `OnTrade` event from `HelperTrade` data bus.
+
1
Subscribe to configured trade and order-book updates from HelperTrade and HelperOrderBook.
-
2
Classify incoming trade as Buy/Sell (e.g., using Tick Rule).
+
2
Classify a trade against the latest order-book midpoint, with the provider's buy or sell flag as fallback.
3
Add classified volume to the current Volume Bucket.
-
4
If bucket is full: calculate imbalance, add to rolling window (queue).
+
4
When a bucket is full, calculate its imbalance and add it to the fixed-size rolling window.
5
Calculate new VPIN value from the rolling window.
-
6
Publish VPIN value to the data bus for UI consumption.
+
6
Emit the new VPIN value with AddCalculation(...), which raises OnCalculated for live views and triggers.
-
Technology Stack & Key Dependencies
+
Technology Stack and Runtime Boundaries
Core Stack
@@ -178,11 +177,12 @@
Core Stack
-
Dependency Licensing
-
Key dependencies have licensing terms with significant implications for enterprise adoption.
-
-
-
+
Runtime boundaries
+
+
Commons: Shared models, helpers, and contracts with no WPF dependency.
+
Commons.WPF: Reusable WPF support that depends on Commons.
+
Plugins: Assemblies loaded into the desktop application's process from beside the executable.
+ 
+ 