Skip to main content

Connections

Connections link HyperionX to market data, trading accounts, brokers, exchanges, simulation providers, and playback sources.

Provider support can vary by build, credentials, region, exchange permissions, and account type. A connection can be live, paper, testnet, read-only, playback, or local simulation.

Connection Types​

TypePurpose
Live exchange/brokerMarket data, account state, order routing, and position updates through a real provider account.
Testnet/paperProvider-supported non-live trading environment where available.
Local simulationHyperionX-managed paper trading using local market updates and simulated fills.
PlaybackHistorical replay for research, validation, and training.
Read-onlyMarket/account context without live order submission.
Gated or disabledUI-visible provider surface that requires additional implementation, credentials, entitlement, or release approval before production use.

Provider Areas​

The codebase has provider areas or UI surfaces for:

  • Hyperliquid.
  • KuCoin.
  • Binance.
  • Rithmic.
  • Jupiter Exchange.
  • o1.exchange.
  • Playback.
  • Local simulation/mock trading.
  • Legacy or disconnected areas such as DxFeed, Interactive Brokers, and CQG.
  • Tradovate.

Not every provider area should be treated as production-ready. Some providers are complete connection surfaces, some are gated, and some are visible configuration surfaces that still need provider implementation. Always verify the implementation, account type, provider permissions, and supported order features before using live trading.

What A Provider Must Map​

A provider adapter converts native provider data into HyperionX models.

The adapter usually maps:

  • Connection status.
  • Instruments and metadata.
  • Historical candles.
  • Real-time candles or ticks.
  • Market depth where supported.
  • Account balances.
  • Orders and order states.
  • Positions.
  • Executions.
  • Leverage or margin settings where supported.
  • Fees, tick size, lot size, multiplier, and quantity precision.

Provider Order State Differences​

Providers do not all report order states the same way.

For example:

  • A limit order may be Working.
  • A stop order may be TriggerPending.
  • A submitted order may not become Working until provider confirmation.
  • A market order can fill before the UI receives the first working update.
  • Some providers report partial fills before final fills.

HyperionX UI should treat active orders as more than only Working. Active display and sibling-cancel logic should include accepted, submitted, trigger pending, part filled, and working states.

Hyperliquid Notes​

Hyperliquid support is focused on crypto perpetual trading workflows.

Important considerations:

  • Instruments can have different tick sizes, lot sizes, quantity precision, and max leverage.
  • Order value in USD mode is converted to instrument quantity using price and multiplier.
  • Stop and bracket orders can appear as trigger-pending before they become active.
  • Live order routing requires valid account and wallet/provider setup.
  • Risk controls should be tested in simulation before live use.

KuCoin Notes​

KuCoin support depends on the current provider implementation and WebSocket behavior on the local system.

If a WebSocket subscription fails, turning the connection off and back on may temporarily recover the connection, but the proper fix is provider-level transport stability.

When validating KuCoin:

  • Test connection startup.
  • Confirm market data subscription.
  • Confirm historical data loading.
  • Confirm account status updates.
  • Confirm order submission only in the intended environment.
  • Watch logs for transport exceptions.

Jupiter And o1.exchange Notes​

Jupiter and o1.exchange integrations should be handled carefully and incrementally.

Recommended build order:

  1. Add provider branding and a clear UI surface.
  2. Add market metadata and pricing through official provider APIs.
  3. Add account/portfolio read context where supported.
  4. Add transaction builders only after the data model is stable.
  5. Add wallet signing through a secure wallet bridge.
  6. Add live trading only after explicit confirmations, permissions, and audit logs.

Private keys should never be stored in HyperionX scripts, logs, memory files, AI context, or plain-text configuration.

Connection Configuration Safety​

Connection windows should follow these rules:

  • Theme-aware dark and light UI.
  • No white hover states in dark mode.
  • Provider logos should match the active theme.
  • Credential fields should not leak into AI context.
  • API keys and secrets should use protected local storage where supported.
  • Logs should redact secrets.
  • Gated or disabled providers should be clearly marked if trading is not wired.

Troubleshooting Checklist​

When a connection does not behave correctly:

  1. Confirm the provider is enabled in the build.
  2. Confirm credentials and permissions.
  3. Confirm the account type, such as live, testnet, paper, or local simulation.
  4. Check the log window for provider errors.
  5. Confirm historical data works before live updates.
  6. Confirm account state loads before order entry.
  7. Confirm instrument metadata such as tick size and lot size.
  8. Test in simulation before live trading.