Overview
Build anything the platform supports — as a plugin.
SabrTrader is an extensible trading platform. Indicators, strategies, bar types, drawing tools, market-data connections, trading providers and more are all plugins: you compile a single .NET DLL against the public SDK, drop it in a folder, and the host discovers it on the next launch.
This documentation teaches you to build every plugin kind, from a short "hello world" to production-grade tooling. Each subject lives on its own page so you can read exactly the topic you need — use the menu on the left to jump straight to it. You never modify, or even see, the host's source code: you reference one NuGet package and implement small, well-documented contracts.
Start here
Two pages get you from zero to a plugin on a chart, and one page gives you the mental model that makes every later chapter click. Read them in order if you are new.
Install the SDK
Add the one NuGet package every plugin compiles against, target net10.0, and turn on
auto-deploy.
Your first plugin
Write a complete minimal indicator, build it in Release, deploy it, restart, and see it draw on a chart — the full round-trip.
Core concepts
The plugin model, the contract assemblies, capability interfaces, series indexing, lifecycle phases and threading — the foundation under every chapter.
What can I build?
The SDK surfaces the whole platform as contracts. Each plugin kind has its own chapter, and each chapter is split into focused pages — an overview, a "your first one" walkthrough, then one page per feature. Start anywhere; the chapters are independent.
📈 Indicators
Plot lines, bands, histograms and candles. Custom chart rendering, orderflow access, per-tick or per-bar calculation, panel placement, threshold lines, child indicators, multi-timeframe and toolbar menus.
🤖 Strategies
Automated entries and exits with managed orders, full ATM brackets (stop/target, breakeven, trailing, scale-in/out), optimizable parameters, backtest and live execution.
🕯️ Bar types
Custom candle aggregation driven by ticks or derived from another series — Renko, range, volume, Heikin-Ashi, or something proprietary of your own.
✏️ Drawing tools
Interactive chart annotations with anchors, hit-testing, editable properties and automatic persistence. Lines, shapes, Fibonacci level sets and patterns.
🔌 Venue plugins
Teach the platform a new venue — data feed, broker or crypto exchange: backfill, live ticks, depth and instruments, behind one plugin, one manifest and one session.
💱 Trading providers
Route orders to a venue: place / cancel / modify / flatten, stream order and account updates, report fills and commissions, and declare your capabilities.
📊 Market Analyzer columns
Add custom columns to the Market Analyzer grid — a computed value per instrument, with its own parameters and data type.
🔔 Alerts
Deliver alerts through a custom channel — e-mail, webhook, messaging or anything you can reach from .NET — behind one async contract.
🕒 Trading hours & sessions
Session-aware logic: detect session open bars, the first bar of a session, and whether a bar time falls inside a configured window.
🏦 Broker venues
A broker is a venue that also routes orders: one plugin, its own trading port over your vendor client, and the components and contract kit that keep the order lifecycle honest.
📒 Trade history
Persist and query fills, and backfill historical executions from a broker into the platform's trade-history store.
🎯 Options data & trading
Venue-agnostic option chains with IV, open interest and greeks, bounded snapshots for exposure analytics (GEX/DEX/VEX), streaming contract quotes, and atomic multi-leg orders from strategies.
📚 SDK reference
Every public type in the contract assemblies — interfaces, records, enums and attributes — grouped by namespace, with signatures.
How the SDK is structured
One meta-package, SabrTrader.Sdk, brings in the three contract assemblies you compile
against, plus an MSBuild target that can auto-deploy your built DLL. The contract assemblies hold
only interfaces, abstract base classes, attributes, enums and data records — no engine
code. The host supplies the engine at load time, which is exactly why your deployed plugin ships only
its own DLL and never copies of these assemblies.
-
SabrTrader.Pipeline.Contracts— indicators, plots, series, bars, ticks, market depth, drawing tools, market-analyzer columns, alerts, and the venue-agnostic options data model. -
SabrTrader.Pipeline.Venues.Contracts— the venue seam (plugin, descriptor, manifest, session) plus orders, positions, accounts, risk, ATM brackets, multi-leg option orders, the option chain SPI and trade history. -
SabrTrader.Pipeline.Strategies.Contracts— theStrategybase class and its runtime context.
Core concepts walks through how these fit together: the plugin model, the "base class plus optional capability interfaces" pattern, series and bars-ago indexing, ambient providers, and the shared lifecycle every plugin kind follows.
How a plugin works
The mechanism is the same for every plugin kind, and it is deliberately simple. There is no plugin manifest, no registration call, and no host configuration to edit. You implement a contract, build a DLL, and the host finds it by inspecting the types inside. The four steps below are the whole story; the Building & deploying chapter explains each in depth.
-
Reference the SDK. One NuGet package,
SabrTrader.Sdk, brings in every contract assembly you need. You compile against pure contracts — interfaces, base classes and data records — never the engine itself. -
Implement a contract. Subclass
IndicatorBase,Strategy,DrawingToolBase, or implement a discovery interface such asIVenuePlugin— the one export behind a market-data feed or a broker. The host constructs your type with a public parameterless constructor before applying any settings. -
Build & deploy. Output a
net10.0DLL and copy it — just the DLL — into the host'sPluginsfolder. An MSBuild target shipped in the SDK can do this for you on every build. - Restart SabrTrader. The plugin loader scans the folder, discovers your types by the interfaces they implement, and registers them into the relevant catalog. Your tool now appears in the UI alongside the built-ins.
.deps.json file. The host already owns the contract types;
shipping your own copies breaks type identity and your plugin silently won't load. The full reasoning
is in Dependencies & isolation.
The pipeline at a glance
Everything is built on a small, allocation-conscious core. Two value types underpin the whole platform — a bar and a tick — and every plugin kind is a contract that produces or consumes them.
C#// One OHLCV bar — passed by value through the whole pipeline.
// StartUtc / EndUtc are true venue UTC. Start / End is the chart timeline
// (display-zone wall-clock when the host has stamped StartDisplay / EndDisplay).
public readonly record struct Bar(
DateTime StartUtc, DateTime EndUtc,
double Open, double High, double Low, double Close,
long Volume, long TickCount,
DateTime StartDisplay = default, DateTime EndDisplay = default);
The flow reads left to right: connections produce ticks; bar builders aggregate ticks into bars; indicators and strategies read the bar series and emit plots, signals and orders; the chart renders plots and drawing tools. Each layer is a contract you can plug into, and the SDK reference maps the full surface.
Conventions used in this guide
| Marker | Meaning |
|---|---|
| SIMPLE | A minimal, get-it-working example. |
| ADVANCED | Production features: rendering, parameters, multi-timeframe, ATM, persistence. |
| INTERFACE | A contract type you implement or consume. |