AI-native runtime for Gate.io trading strategies

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

No. Gate.io API access is provided by Gate.io. You are responsible for your Gate.io account, API permissions, credentials and compliance with Gate.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 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.

Use `gate`. That is the active class. `gateio` still resolves and inherits from `gate`, but new code should use `gate`. Initialise with ccxt.gate({"apiKey": ..., "secret": ..., "options": {"defaultType": "swap"}}) for USDT-margined perps, "spot" for spot, "future" for delivery, "option" for options. 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. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime: CCXT, Freqtrade or Hummingbot 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. Use scoped v4 permissions (Spot Trade, Perpetual Futures, etc.) and bind the key to your runtime's egress IP using Gate.io's IP whitelist. Keys without an IP whitelist expire at 90 days.

Yes, that's the recommended pattern on Gate. Create sub-accounts under the main account, issue a dedicated API v4 key per sub-account (with the minimum permissions the strategy needs), and let TradingHost inject the key as a secret. Sub-account volume and VIP tier still roll up to the main account, but blast radius from a compromised key or runaway strategy is scoped to that sub-account. Assets can only move main to sub, never sub to sub.

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.

Gate v4 signs with HMAC-SHA512 (not SHA256) and the signature string concatenates with literal \n: Method + "\n" + URL_Path + "\n" + QueryString + "\n" + HexEncode(SHA512(Body)) + "\n" + Timestamp. The output is hex, not base64. The three required headers are KEY, Timestamp, SIGN; no passphrase (that is OKX). The body hash must be hex SHA512 of the raw request body, with empty body hashing to the SHA512 of an empty string. See the Operational notes section above for the full guidance.

Yes, futures only. Futures TestNet runs at https://fx-api-testnet.gateio.ws/api/v4 (REST) and wss://fx-ws-testnet.gateio.ws/v4/ws/{usdt,btc} (WebSocket). You must generate separate TestNet API keys; production keys do not authenticate against TestNet. Spot has no public sandbox; test spot strategies with Freqtrade dry_run or CCXT in record-and-replay mode before going live.

No. Gate.io blocks US persons and US residents. TradingHost cannot route orders to Gate.io from a US account; the restriction is at the venue. You also cannot use Gate from mainland China; Gate exited that market after the September 24, 2021 People's Bank of China ban. Other restricted jurisdictions include Canada, Singapore and UK.

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.