AI-native runtime for Crypto.com Exchange trading strategies

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

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

No. TradingHost is the cloud runtime where your strategy code runs. We do not provide signals, AI prediction models or pre-built strategies. 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 Crypto.com as exchange id `cryptocom` and lists it as certified, pro-tier with spot, margin and swap capability flags. Treat CCXT as a convenience layer; rate-limit semantics and the post-Jan-2026 Advanced Order Management endpoints follow the native Exchange v1 contract. See the CCXT framework runtime for the full setup story.

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. Crypto.com Exchange's master / sub-account hierarchy pairs naturally with this: each strategy can address its own sub-account under a single master key. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime such as CCXT for a ready-to-deploy project, or connect your own GitHub strategy repo. 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 API key and secret. See platform secrets for the full handling model.

No. Strategies should never need withdrawal permissions. Crypto.com requires IP whitelisting on keys with trading or withdrawal permissions; keep withdrawal scope off your strategy keys and manage withdrawals separately.

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.

40101 means the HMAC-SHA256 signature, key, or signed-parameter ordering is wrong; recheck the signed string `method + id + api_key + parameter_string + nonce` and the ascending sort of parameter keys. 40102 means your nonce is more than 60 seconds out of step with Crypto.com's server clock; sync NTP. 40103 means your request IP is not in the API key's whitelist; trading and withdrawal keys require an IP whitelist. See the Operational notes section above for the full guidance.

The Crypto.com Exchange is the trading venue with the public, documented v1 API used for algo trading; this is what TradingHost integrates with. The Crypto.com App is the retail wallet and consumer product; it does not publish a trading API. API keys are generated in the Exchange web UI under User Center > API, not in the mobile App.

Take Profit and Stop Loss order creation and cancellation moved from `private/create-order` to `private/advanced/create-order` on 2026-01-28 08:00 UTC, after trigger orders migrated on 2025-12-17 08:00 UTC. Strategies must now call the advanced endpoint for conditional orders and subscribe to `user.advanced.order` for state updates. Plain limit and market orders continue on `private/create-order`.

On the international venue the unified Exchange v1 API key can address spot, margin and perpetuals in one credential, but the underlying derivatives entitlement is bound to the account, not the key. Derivatives must be enabled on the account and the account must be in a non-excluded jurisdiction. In the US, derivatives run on a separately licensed affiliate (CDNA) with its own onboarding.

Freqtrade can reach Crypto.com via CCXT but is not officially supported by the Freqtrade team. Hummingbot's `crypto_com` connector is flagged outdated since the GEN 3 API upgrade and is not on Hummingbot's current exchanges list; treat it as unsupported and use CCXT or native v1 directly.

TradingHost runs in the EU and US-East regions. Pick the region closest to the matching engine your strategy depends on. 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.