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

Type	Purpose
Live exchange/broker	Market data, account state, order routing, and position updates through a real provider account.
Testnet/paper	Provider-supported non-live trading environment where available.
Local simulation	HyperionX-managed paper trading using local market updates and simulated fills.
Playback	Historical replay for research, validation, and training.
Read-only	Market/account context without live order submission.
Coming soon	UI-visible provider surface that is not wired for production use yet.

Current And Planned Provider Areas

The codebase has provider areas or UI surfaces for:

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

Not every provider area should be treated as production-ready. Always verify the connection implementation, account type, 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 Exchange Plan

Jupiter should be integrated carefully and incrementally.

Recommended build order:

1. Add read-only provider branding and UI surface.
2. Add market metadata and pricing through official Jupiter 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.
• Coming-soon 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.