Risk And Security

HyperionX is trading software. Any feature that can affect orders, accounts, wallets, or strategy execution must be designed with clear risk boundaries.

Core Principles

HyperionX should follow these principles:

• Simulation first.
• Read-only AI by default.
• Explicit user confirmation for high-risk actions.
• No hidden credential exposure.
• No private keys in scripts, logs, prompts, or AI context.
• Local APIs bound to localhost with session tokens.
• Audit logs for tool actions.
• Clear separation between research results and live trading.

Trading Risk

Trading systems can fail for many reasons:

• Bad strategy logic.
• Poor historical data.
• Overfitting.
• Provider outages.
• Slippage.
• Fees.
• Latency.
• Partial fills.
• Incorrect tick size or lot size.
• Unexpected order state mapping.
• Connection disconnects.
• User configuration mistakes.

Backtests and optimizations are research tools. They do not guarantee live results.

AI Risk

AI can help users move faster, but it can also produce incorrect code, wrong assumptions, or overconfident analysis.

AI-generated output should be treated as a draft until verified.

Safe AI rules:

• Compile AI-generated scripts before using them.
• Review strategy logic before enabling.
• Run in simulation before live use.
• Keep AI read-only unless a tool is explicitly enabled.
• Redact secrets from AI context.
• Do not allow AI to submit live orders without confirmation.
• Keep audit logs of agent actions.

Credential Safety

Credential-like values should never be sent to chart AI, local API snapshots, log files, or public support exports.

Secret-like fields include names containing:

• key
• secret
• password
• token
• private
• seed
• mnemonic
• wallet

Connection settings should use protected local storage where supported by Windows and should avoid plain-text secrets.

Wallet Safety

For wallet-based providers, HyperionX should never ask users to paste private keys into Code Lab scripts, strategy parameters, AI prompts, log files, or plain-text config files.

Recommended wallet model:

• Use an external wallet or secure wallet bridge.
• Build transactions inside HyperionX only after explicit user action.
• Sign through the wallet.
• Show clear transaction details before signing.
• Keep AI read-only until transaction tools are explicitly permissioned.

Local API Safety

Future local APIs should be safe by default:

• Bind only to 127.0.0.1.
• Use random per-session ports or tokens.
• Require a token for every request.
• Default to read-only endpoints.
• Redact secrets.
• Include build/version metadata.
• Log high-risk requests.
• Reject live trading calls unless explicitly enabled.

Strategy Safety Checklist

Before trusting a strategy:

1. Compile without errors.
2. Confirm it uses HyperionX APIs.
3. Guard early bars.
4. Validate indicator values.
5. Test on historical data.
6. Test out-of-sample.
7. Run with realistic fees and slippage.
8. Run in playback or simulation.
9. Confirm order sizes, stops, and targets.
10. Monitor live behavior with small size first.

UI Safety

Trading UI should make dangerous actions obvious:

• Sell/close/destructive actions should use danger/red styling where appropriate.
• Confirmations should use clear language.
• Disabled actions should be visually disabled and not clickable.
• Order quantity modes should be clear, especially USD versus direct quantity.
• OCO/bracket parameters should not mix entry sizing with exit rules.
• PnL display units should be obvious.

Support Logs

Support logs are useful for diagnosing provider, script, and workspace problems. They should avoid including credentials or private account secrets.

Useful log categories:

• Connection status.
• Provider errors.
• Code Lab compile diagnostics.
• Indicator runtime exceptions.
• Strategy runtime exceptions.
• Workspace restore errors.
• Order state transitions.
• AI provider errors without secret values.