Skip to main content

Platform Architecture

HyperionX is organized as a desktop trading workstation with a script runtime, provider layer, charting engine, account/order model, research tools, and AI context layer.

At a high level, the platform has five major layers:

LayerResponsibility
Desktop ShellMain window, menus, workspaces, tool windows, logs, settings, and saved layouts.
Trading WorkspaceCharts, Chart Trader, DOM tools, account views, orders, positions, and multi-window layouts.
Market And Account CoreInstruments, candles, orders, accounts, positions, providers, simulation, playback, and broker/exchange adapters.
Code Lab RuntimeCompiled C# custom indicators, strategies, bar types, optimizers, commissions, money management modules, and addons.
AI And Local APIsRead-only chart context today, with planned local APIs for agents, CLI tools, Code Lab diagnostics, and eventually permissioned actions.

Desktop Shell​

The desktop shell is the application frame. It owns startup, theme loading, menu actions, workspace restore, tool windows, logs, and global configuration.

Typical shell responsibilities include:

  • Loading application settings.
  • Loading saved connections.
  • Loading and compiling custom scripts.
  • Restoring saved workspaces.
  • Opening charts, DOM tools, Code Lab, and database/research windows.
  • Applying dark/light theme resources.
  • Exporting logs for support and debugging.

Charting Layer​

The charting layer is the primary user workspace. It renders market data, indicators, orders, positions, drawing tools, chart panels, and overlays.

Important chart concepts:

  • A chart owns an instrument and data series.
  • A chart can have one or more panels.
  • Indicators can render in the price panel or their own panel depending on script behavior.
  • Chart Trader is tied to account, connection, instrument, and order state.
  • AI chart context is generated from the active chart.
  • Multi-chart layouts are separate chart instances, not permanent clones.

Provider Layer​

The provider layer maps exchange, broker, playback, and simulation sources into HyperionX's internal models.

Providers are responsible for:

  • Connection status.
  • Historical candle requests.
  • Live market updates.
  • Account state.
  • Order submission and order updates.
  • Position updates.
  • Provider-specific symbol metadata.
  • Mapping provider order states into HyperionX order states.

Provider behavior can vary depending on whether the connection is live, paper, testnet, local simulation, or read-only.

Account And Order Model​

HyperionX normalizes trading state into common objects:

  • Account
  • Instrument
  • Order
  • Position
  • Execution
  • OrderState
  • OrderAction
  • OrderType

This allows charts, strategies, DOM tools, and account windows to reason about trading state without hardcoding every provider's native API.

Order states include accepted, submitted, working, trigger pending, part filled, filled, cancelled, rejected, and expired. A UI should treat more than one state as "active" because some providers report stop and bracket orders as Submitted or TriggerPending before they become fully working.

Code Lab Runtime​

Code Lab compiles user scripts into the HyperionX custom assembly. Those scripts run inside the platform and use HyperionX APIs.

Supported script categories include:

  • Indicators
  • Strategies
  • Bar types
  • Optimizers
  • Optimization fitness modules
  • Money management modules
  • Commissions
  • Addons

The script runtime uses a lifecycle model:

  • State.SetDefaults for defaults, names, versions, and plot declarations.
  • State.Configured for allocating series and connecting plots.
  • Historical, playback, and real-time states for calculation/runtime behavior.
  • OnBarUpdate() for per-bar indicator and strategy logic.

Research Layer​

Research workflows connect strategy scripts to historical data, performance metrics, optimization ranges, validation windows, and playback behavior.

The direction is to support a complete loop:

  1. Write or import a strategy.
  2. Compile it in Code Lab.
  3. Load it into a validation or strategy window.
  4. Select instrument, timeframe, dates, and account assumptions.
  5. Run the test.
  6. Review trades, drawdown, profit factor, consistency, and failure cases.
  7. Iterate the logic.
  8. Move to simulation or playback before live trading.

AI Context Layer​

The current AI integration is intentionally read-only. The chart AI can receive safe chart context, including symbol, timeframe, candles, indicators, strategies, and chart trader state.

The AI context layer must not expose:

  • API keys.
  • Broker secrets.
  • Wallet private keys.
  • Raw filesystem access.
  • Hidden platform memory.
  • Direct live order submission by default.

The long-term design is to expose local APIs and permissioned tools so agents can help with development, research, validation, and eventually controlled trade workflows.

Local API Direction​

The planned local API should act as a safe bridge between HyperionX and external tools.

Expected future surfaces:

  • Read-only chart snapshots.
  • Active chart list.
  • Visible candle range.
  • Loaded indicator metadata.
  • Loaded strategy metadata.
  • Chart trader state.
  • Code Lab build and diagnostics.
  • Workspace metadata.
  • Simulation-only actions.
  • Permissioned live actions after explicit confirmations and audit logging.

This local-first model gives users control while still allowing AI agents, terminal tools, and integrations to build on top of the platform.