AI-native runtime for CEX.IO trading strategies

No. Your strategy code connects to CEX.IO and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.

No. CEX.IO API access is provided by CEX.IO. You are responsible for your CEX.IO account, API permissions, credentials and compliance with CEX.IO’s terms.

No. TradingHost is the cloud runtime where your strategy code runs. We do not provide signals, AI prediction models or pre-built bots. With TradingHost you write or generate the strategy yourself (often with Cursor or Claude Code), keep it in GitHub as your code, and use TradingHost to run it in production. 3Commas, Cryptohopper and similar products own the strategy logic; TradingHost runs your strategy.

AWS and DigitalOcean give you raw compute. You handle OS updates, container orchestration, log shipping, secret rotation, region failover and uptime monitoring yourself. TradingHost gives you a managed runtime purpose-built for trading strategies: GitHub-native deployment, MCP-driven control from AI IDEs, log and health surfaces out of the box. If you want to operate the infrastructure yourself, AWS works. If you want the runtime as a managed service, TradingHost is the shorter path.

Yes. TradingHost runs Python strategies; pick the framework runtime that matches your stack or deploy your own repo.

Yes. TradingHost supports any language that can run inside a container.

Yes. CCXT exposes CEX.IO retail spot through the unified `cex` class. CEX.IO Prime aggregated liquidity is institutional and not a first-class CCXT market; for Prime, target the native Prime Liquidity API or FIX 4.4. See the CCXT framework runtime for the full setup story.

Yes. TradingHost is venue-agnostic at the runtime level: any code that can authenticate against CEX.IO Prime can run inside a container, including a FIX 4.4 session. The implication you have to design for is that FIX has its own session-management contract (logon, heartbeat, sequence-number recovery) that differs from REST/WebSocket. Pin a battle-tested library such as QuickFIX, supervise the session state outside the strategy logic, and treat FIX session resets as recoverable runtime events.

Yes, if your project is designed that way. You can run multiple strategy processes or services inside one runtime, or separate them into different runtimes for isolation and operational clarity. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime: CCXT for a ready-to-deploy retail spot project. Or connect your own GitHub strategy repo if you target the native Prime Liquidity API or FIX 4.4. Linking a GitHub repo and creating a strategy is free; runtime plans are listed on the pricing page.

In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your Prime API key, secret or FIX session config. See platform secrets for the full handling model.

No. Strategies should never need Funds External (withdrawal) permission. CEX.IO splits API key permissions into five scopes: Read, Trade, Funds Internal, Funds Wallet and Funds External. Per-strategy keys with only the scopes that strategy needs contain the blast radius if a key leaks; isolate withdrawal-capable keys on a separate manually-managed credential outside the container runtime.

Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. AI tools can inspect deployments, review logs, restart strategies and manage runtime workflows. MCP is a control and observability surface, not the trade execution path. See the MCP control surface for the full picture.

Both. The MCP control surface works equally well from CLI-based agents (Claude Code CLI, custom MCP clients, scripted MCP calls) and from inside an IDE. The GitHub-native deployment loop also works without any AI tooling: a regular git push to your main branch triggers a redeploy.

The runtime detects the crash and exposes the relevant logs and health information. Where supported, the affected strategy can be restarted without disrupting other strategies running in the same container. Your strategy code is still responsible for safe error handling, duplicate-order protection and risk controls. See observability for the logs and health surface.

CEX.IO Prime signs HMAC over action + timestamp + body, not raw body alone, with a base64-decoded secret. Strategies that hash just the body, sign with the secret as a UTF-8 string instead of decoding from base64, or omit the action prefix see signature-error responses that look like wrong-key errors. Unit-test the signing path against a known-good request before shipping. See the Operational notes section above for the full guidance.

TradingHost runs in the EU and US-East regions. For CEX.IO Prime, the EU region is typically the right choice because US traffic is blocked on Prime tiers despite the parent entity's FCA MLR registration. Pick the region whose egress geography is consistent with both your user agreement and your own compliance posture. See the regions page for routing and proximity details.

No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.