Platform Architecture

HyperionX 1.1.10 is a Windows desktop application built on .NET 8. Charts, provider adapters, order state, research jobs, Code Lab scripts, local storage, and Rion services run as cooperating parts of the desktop product.

Runtime map

Area	Owns
Desktop shell	Startup, main menu, settings, connections, workspaces, licensing, updates, logs, and tool windows.
Provider layer	Historical/live market data, instrument metadata, accounts, orders, positions, executions, depth, and provider reconciliation where implemented.
Chart layer	Candles, panes, indicators, drawings, Chart Trader, order/position overlays, and modular chart layouts.
Trading core	Normalized accounts, orders, executions, positions, OCO/bracket handling, strategy order routing, and local simulation.
Custom runtime	One compiled HyperionX.Custom.dll containing Code Lab indicators, strategies, add-ons, bar builders, optimizers, fitness modules, commissions, and money-management modules.
Research	Validator, Optimizer, performance calculation/storage, Research Lab, and worker/cloud-assisted research paths.
Rion services	In-chart AI context, configured AI providers, Agent Builder profiles, a Preview loopback API, and internal cloud bridge services.
Persistence	Main SQLite data, historical market-data files, workspaces, custom source/build output, research files, agent profiles/history, audit logs, and protected credential stores.

Provider boundary

A connection adapter maps provider-native data into common HyperionX models such as Instrument, Account, Order, Position, and Execution.

That normalization does not make providers identical. Order types, depth, account scopes, bracket handling, change/cancel behavior, reconciliation, paper environments, and timestamps remain provider-dependent. Use Feature And Provider Status and the provider guides instead of assuming that one successful connection proves every capability.

For externally routed orders, the broker or exchange remains the authority. A local timeout, disconnect, or missing UI update does not prove an order was rejected or cancelled.

Chart and trading boundary

A chart binds an instrument and data series to a calculation context. Indicators consume that context; Chart Trader and strategy instances add account/order behavior.

These contexts are related but independent:

• A chart can have valid market data without a tradable account.
• A provider account can remain exposed after a chart or connection UI changes.
• Playback supplies replayed data and time without changing the selected account. In the current release-candidate build, the account mutation layer rejects Broker and Server Paper submissions, changes, and cancellations while Playback is active; replay trading requires LocalPaper.
• Hyperion Sim (LocalPaper) uses a simplified local fill model rather than provider matching-engine behavior.

See Accounts And Trading Environments before moving from analysis to execution.

Code Lab boundary

Code Lab compiles the complete custom source tree into one in-process assembly. A compiler error in any included .cs file blocks the new assembly, and extensions share the desktop process with the platform.

The supported public script surface is the generated HyperionX.Custom indicator/strategy layer plus explicitly documented Core contracts. Internal desktop objects are not stable public APIs merely because they are visible to reflection or present in a referenced assembly.

After a build, existing objects do not automatically become instances of the new assembly. Disable affected objects before building and recreate them afterward. See API Status And Compatibility and Build, Test, And Debug.

Research boundary

Validator and Optimizer create historical strategy runs from selected instruments, data-series settings, periods, fill models, commission modules, and strategy inputs. Research results are evidence produced by those assumptions, not forecasts.

Research Lab is a separate Preview surface with local dataset/worker storage and optional cloud ML transfer. Its data and retention boundary is documented in Research Lab.

Rion and API boundary

Rion can assemble chart, indicator, strategy, drawing, news, and trading-state context for a configured model provider. Ollama is local; cloud providers necessarily receive the context included in a request.

The localhost HTTP surface is Preview, loopback-only, and token-protected. It is not a general broker API. The 1.1.10 baseline limits trading actions to Hyperion Sim; newer release-enabled builds can expose guarded Hyperliquid and KuCoin routes. Agent Builder profile settings and the global local API remain separate enforcement paths unless an installed build explicitly reports otherwise.

See AI Data And Privacy, Local API, and Local Agent Live Trading API for the operational contract.

Storage boundary

HyperionX data is split across Windows user locations rather than one portable project file. Important categories include:

• %USERPROFILE%\Documents\HyperionX for workspaces, custom code/build output, historical data, research artifacts, logs, and agent workspaces.
• %APPDATA%\HyperionX for AI settings/history, license/session state, and Rion API audit logs.
• %LOCALAPPDATA%\HyperionX for Marketplace and WalletConnect protected state and installed runtime payloads where applicable.
• The HyperionX database for application records, instruments, performance records, and protected connection fields.

Protection differs by item. Some credentials use Windows DPAPI for the current Windows user; exports, workspaces, custom source, worker requests, and many diagnostic artifacts are plaintext. Use Install, Update, And Uninstall, Support And Diagnostics, and Risk And Security before backup or sharing.

Failure isolation

Not every subsystem has the same failure policy:

• A custom build is atomic, but an already running object can continue from an older assembly.
• Indicators can be disabled after repeated callback errors.
• Strategy callback errors are logged without an automatic strategy stop in 1.1.10.
• Provider reconnect/reconciliation behavior varies.
• A restored tool window does not necessarily restore its in-progress task.

Operational instructions should therefore include a visible expected result, a log check, and an authoritative-state check where money or external data is involved.