Traadence's real time trading signals is a working NinjaTrader decision-support dashboard that converts multiple market conditions into seven readable states: BUY, SELL, WAIT, HOLD, WARNING, PROTECT PROFIT, and EXIT. It gives a futures trader one controlled view of market bias, position status, and protective actions without exposing proprietary calculations in the interface.
One screen for market state, trade state, and the next permitted action.
A Decision Layer for NinjaTrader Futures
Fast futures markets create a practical problem: indicators can disagree while orders, fills, and positions change between ticks. The add-on runs inside NinjaTrader 8, subscribes to configured market and account events, evaluates each condition, and publishes one state with reason codes and a timestamp.
The design separates data collection, condition evaluation, state resolution, dashboard rendering, and order handling. That boundary matters when private rules change: a new calculation can be added without rewriting the window, the audit log, or the simulation safety gate. The result is a maintainable foundation rather than a chart panel with trading logic embedded in button handlers.
Core Features
| Feature | Description |
|---|---|
| Multi-Condition Market Monitor | Conflicting indicators are hard to reconcile manually. The monitor receives tick, bar, indicator, session, and position inputs, validates freshness, and sends a normalized snapshot to the decision engine. |
| Seven-State Decision Engine | Ambiguous dashboards leave the trader interpreting colors under pressure. The engine resolves configured rules into BUY, SELL, WAIT, HOLD, WARNING, PROTECT PROFIT, or EXIT, with a reason list showing which conditions passed or blocked. |
| Workspace-Persistent Control Panel | Rebuilding a layout after every restart wastes attention. The dashboard uses NinjaTrader's NTWindow framework so instrument, account, thresholds, and panel state can be restored with the workspace. |
| Order and Position State Monitor | A signal can become invalid after a partial fill or manual intervention. Event handlers track order status, average fill price, quantity, market position, and strategy-versus-account mismatches through the NinjaScript strategy model. |
| Protective Order Manager | Manual stop, target, trailing, and breakeven changes can conflict. The manager keeps one authoritative trade state and uses event-driven order references to submit, change, or cancel simulated protective orders. |
| Simulation Account Gate | Testing logic against a live account too early creates avoidable operational risk. Automated entry and management remain restricted to NinjaTrader Sim101 until the user explicitly changes the deployment policy. |
| Decision and Order Journal | Debugging from screenshots alone hides sequence errors. Every state change records instrument, bar time, market inputs, reason codes, position state, order references, and exception details in a timestamped CSV log. |
| Replay and Backtest Hooks | Rules that work only in live mode are difficult to verify. Shared evaluators can run from Market Replay or Strategy Analyzer, while execution-specific code stays behind an adapter for deterministic testing. |
How the State Engine Reaches a Decision
- Capture: market, indicator, session, account, order, and position events are converted into an immutable snapshot with source timestamps.
- Validate: stale or missing inputs force WAIT or WARNING instead of allowing a directional state from incomplete evidence.
- Resolve: rule groups apply priority and conflict handling, so EXIT and protection states can override new-entry states.
- Publish: the dashboard receives the final state, supporting reasons, and permitted action; the journal stores the same payload for later review.
This is decision support, not a prediction claim. A BUY state means the configured conditions currently permit a long action; it does not assert that price will rise. A WARNING or EXIT state can also override an earlier directional reading when data freshness, risk limits, or position events change.
Risk Controls Before Automatic Execution
The automation boundary is deliberately conservative. Maximum position size, allowed account, session window, duplicate-entry lock, stale-data timeout, and emergency flatten behavior are checked before any simulated order request. This follows the control categories discussed in the CFTC automated-trading concept release, including pre-trade limits, testing, and system safeguards.
Protective orders are treated as stateful objects, not one-time commands. The manager compares expected and observed order states after every update, logs rejects, and blocks a second submission while an equivalent order is working. Futures users can review broader contract and market context in CME Group's stock index futures report.
Technical Stack and Why It Fits
| Layer | Implementation | Reason |
|---|---|---|
| Platform runtime | NinjaTrader 8 AddOn and Strategy APIs | Keeps market data, account events, strategy state, and the dashboard in the same desktop runtime. |
| Trading logic | NinjaScript and C# | Supports typed state models, event-driven order callbacks, unit-testable evaluators, and direct reuse inside Strategy Analyzer. |
| Interface | WPF with MVVM-style view models | Separates visual controls from state transitions, which prevents UI code from becoming the trading engine. |
| Configuration | Versioned XML and NinjaScript properties | Makes thresholds and enabled modules inspectable while preserving compatibility with NinjaTrader templates. |
| Diagnostics | CSV decision journal plus NinjaScript Output logging | Provides a portable event trail for replay comparison, exception tracing, and rule verification. |
Project Directory
TraadenceSignalDashboard/
├── AddOns/
│ ├── SignalDashboardAddOn.cs
│ ├── SignalDashboardWindow.cs
│ ├── SignalDashboardTab.cs
│ └── WorkspacePersistence.cs
├── Engine/
│ ├── MarketSnapshot.cs
│ ├── DecisionState.cs
│ ├── ConditionResult.cs
│ ├── DecisionEngine.cs
│ └── StatePriorityResolver.cs
├── Conditions/
│ ├── IConditionEvaluator.cs
│ ├── IndicatorConditionAdapter.cs
│ ├── SessionCondition.cs
│ ├── DataFreshnessCondition.cs
│ └── PositionCondition.cs
├── Execution/
│ ├── Sim101ExecutionStrategy.cs
│ ├── OrderStateTracker.cs
│ ├── ProtectiveOrderManager.cs
│ ├── BreakevenManager.cs
│ ├── TrailingStopManager.cs
│ └── EmergencyExitController.cs
├── UI/
│ ├── DashboardView.xaml
│ ├── DashboardViewModel.cs
│ ├── StateTileViewModel.cs
│ └── OrderPanelViewModel.cs
├── Configuration/
│ ├── DashboardSettings.cs
│ ├── RiskPolicy.cs
│ └── RuleSetProfile.cs
├── Diagnostics/
│ ├── DecisionJournal.cs
│ ├── OrderAuditRecord.cs
│ └── ExceptionReporter.cs
├── Tests/
│ ├── DecisionEngineTests.cs
│ ├── StatePriorityTests.cs
│ ├── ProtectiveOrderManagerTests.cs
│ └── ReplayFixtures/
│ └── state-transitions.csv
├── README.md
├── INSTALL.md
└── CHANGELOG.md
Acceptance Benchmarks
Benchmarks are measured with fixed rule inputs and recorded market sessions; they verify software behavior, not trading performance. Hardware, data provider, instrument activity, and enabled conditions can change timing results.
| Check | Acceptance Target | Method |
|---|---|---|
| Decision latency | 95th percentile at or below 25 ms with eight condition evaluators | Replay a timestamped market-data fixture and measure snapshot receipt to resolved-state publication. |
| Dashboard refresh | Visible state update within 100 ms, capped at 10 UI refreshes per second | Generate bursty market events while confirming the interface remains responsive and displays the latest state. |
| Sim101 soak test | Two continuous hours with zero unhandled exceptions or duplicate protective orders | Run entries, partial fills, stop changes, breakeven moves, disconnect simulation, and session reset against a simulation account. |
| Deterministic replay | Identical state sequence across three runs using the same configuration | Hash each state, reason-code set, and timestamp bucket, then compare the complete output sequence. |
Use Cases
- A discretionary futures trader replaces several indicator panels with one state tile and can inspect the exact reasons behind WAIT, WARNING, or EXIT.
- A strategy researcher adds confidential calculations as condition evaluators while keeping the dashboard, logging, and state-priority logic unchanged.
- A Sim101 tester validates entries, stop losses, profit targets, trailing behavior, and breakeven transitions before any deployment policy is widened.
- A trading operations reviewer reconstructs a session from the decision journal after an order reject, disconnect, partial fill, or manual position change.
Teams that need additional condition modules, deployment controls, or ongoing NinjaScript maintenance can use Traadence's trading signals service for the same dashboard architecture and existing trading stack.
How to Monitor Futures Decisions Using Traadence's real time trading signals
Download & Set Up the Project
Download, set up, and install Traadence's real time trading signals to get the project running. If you hit any difficulty, contact us here.
Open the Dashboard
Launch NinjaTrader 8, choose Tools → Signal Dashboard, then select the instrument, bars series, and Sim101 account displayed in the header.
Configure the Rules
Enable condition modules, set state thresholds, stale-data timeout, breakeven trigger, trailing distance, maximum position size, and the permitted session window.
Start Monitoring
Press Start Monitoring to receive the current state, reason codes, position status, protective-order plan, and timestamped decision journal.
Questions
Can the dashboard place and manage simulated orders in NinjaTrader Sim101?
Yes. The execution gate can submit simulated entries and manage stop losses, profit targets, trailing stops, breakeven moves, and exits through Sim101. It remains restricted to the configured simulation account unless the deployment policy is deliberately changed and retested.
Do I receive the complete NinjaScript and C# source code?
Yes. The download includes the AddOn, decision engine, condition interfaces, Sim101 strategy, order managers, WPF views, configuration models, tests, and installation notes. Proprietary rule files can be replaced without removing the reusable framework.
How are proprietary trading rules kept separate from the dashboard framework?
Private calculations implement a condition interface and return a structured result rather than drawing directly on the screen or placing orders. The state engine consumes those results, while the UI receives only the resolved state and reason codes, reducing accidental disclosure and coupling.