AI-native runtime for Binance trading strategies
Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.
Section 01 · At a glance
At a glance
- Venue
- Binance
- Venue type
- Crypto exchange
- Asset class
- Crypto
- Supported products
- Spot, USD-M futures, COIN-M futures, options, cross and isolated margin
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native API code, CCXT, Freqtrade, Hummingbot, custom connectors
- AI workflow integration
- MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
- TradingHost role
- Runtime, deployment, logs, health checks, region selection, MCP control
- Binance role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with Binance
Section 02 · What Binance offers
What Binance offers
Binance offers spot, USD-M and COIN-M futures, options, and cross/isolated margin trading via REST and WebSocket APIs. Strategies authenticate with HMAC-SHA256-signed API keys scoped to specific permissions, and both spot and futures have separate public testnets. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, fee tiers and symbol lists live in Binance's docs.
Markets and strategy patterns
- USD-M perpetual futures strategies
- COIN-M inverse futures and quarterly contracts
- BTC and ETH options strategies
- Funding-rate and basis trading on perpetuals
- Sub-account-isolated multi-strategy deployments
- Spot and margin strategies (cross or isolated)
- WebSocket User Data Stream consumers
- Spot and Futures Testnet-validated deployments
API surface
- Product surfaces
- Spot, USD-M futures (perpetuals and delivery), COIN-M futures, options, cross and isolated margin, and sub-account hierarchies. Each has a public testnet so a strategy can be validated against the same API surface without real capital.
- Connection methods
- REST for order placement and account queries. WebSocket streams for real-time market data and depth. WebSocket User Data Streams for account, balance and order events. A WebSocket API for request/response runs alongside the REST surface.
- Authentication
- API key and secret per strategy. Private requests are signed with HMAC-SHA256. Permissions are scoped per key (read, spot trade, futures trade, withdrawal) with optional IP whitelisting. Strategies should never need withdrawal permission.
For specifics, refer to Binance
Specific endpoints, rate-limit weights, symbol lists, fee tiers and version history live in Binance's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your Binance strategy with AI
Pick an integration method, fork a TradingHost framework starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.
Native Binance API
Direct control over Binance-specific behaviour, account data and order execution logic.
Freqtrade or Hummingbot
Framework-based deployments using their strategy structure and configuration model.
Custom connector
Your own internal trading engine or proprietary Binance integration.
Framework support for Binance products
Coverage varies by framework. CCXT spans the broadest Binance surface; Freqtrade and Hummingbot cover spot and USD-M perpetuals; native Binance API access covers everything Binance offers, including options.
✓ confirmed support per official framework docs. "no" indicates not officially documented as supported.
TradingHost does not force a framework. It runs your project.
Author with AI
The framework starters above pair naturally with AI IDEs. The TradingHost MCP control surface closes the loop: AI tools can inspect deployments, review logs and manage the runtime alongside you, never the trade execution path.
Section 04 · Run on TradingHost
Run your code on TradingHost
Binance provides the exchange and API access. TradingHost provides the production environment where your Binance-connected strategy runs.
Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.
You
- Your repo contains your code.
- Your deployment defines how it runs.
- Your strategy connects to Binance.
TradingHost
- Keeps the runtime online.
- Surfaces logs and health checks.
- Region selection.
- Controlled deployment surface.
Deployment flow
- STEP 01
Connect GitHub
Authorise TradingHost to access your GitHub account.
- STEP 02
Link a repo or start from a framework
Point TradingHost at your existing strategy repo, or fork a TradingHost framework runtime (CCXT, Freqtrade or Hummingbot) for a working baseline.
- STEP 03
Deploy into a TradingHost container
Pick a region (EU or US-East), supply the environment values your strategy needs (Binance API keys, etc.), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.
- STEP 04
Monitor logs and health
Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE, so Cursor, Claude Code or a CLI agent can read deployment state and manage the runtime alongside you.
- STEP 05
Update and redeploy
Push changes to your GitHub main branch and TradingHost redeploys automatically.
Section 05 · Operational notes
Operational notes for Binance
Things that bite you when you actually run a Binance strategy in a containerised cloud runtime, not in Binance's docs, not in framework READMEs. Every claim below is quoted or paraphrased from Binance's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Error -2015
"Invalid API-key, IP, or permissions for action"
The most common Binance auth failure. It means your key exists but either the request IP is not whitelisted on the key, or the key lacks permission for the endpoint (e.g. a spot key hitting a futures endpoint, or a read-only key trying to place an order). On TradingHost, container egress IPs are pinned per region. Whitelist the published egress range for your selected region rather than a single IP, because containers reschedule.
02 · Withdrawal scope
Withdrawal permission requires IP whitelisting
Binance: "Adding IP access restrictions is mandatory to enable withdrawal permission." Cloud runtimes do not have stable single egress IPs, so withdrawal-scoped keys are difficult to operate from containers. The right pattern: do not enable withdrawal scope on strategy keys at all. Strategies do not need it. Keep withdrawal on a separate manually-managed key on a fixed-IP host.
03 · Read-only fallback
Fresh system-generated keys are read-only without IP restrictions
Effective 2023-01-30, Binance: "the system-generated API Key's permission can only be set to [Enable Reading] if your IP is unrestricted." If you generate a fresh key for a TradingHost strategy without whitelisting, it cannot trade, only read. Either whitelist the runtime's egress range for your region, or use a self-generated Ed25519 / RSA key which bypasses the default security control.
04 · Key scoping
One scoped key per strategy, not one master key shared across strategies
Binance offers four endpoint security types: NONE (public market data), TRADE (orders), USER_DATA (account state), USER_STREAM (User Data Stream subscription). Binance: "you can have an API key with TRADE permission for trading, while using a separate API key with USER_DATA permission to monitor your order status." Per-strategy keys with only the scopes that strategy needs contain the blast radius if a key leaks.
05 · recvWindow
Default 5000 ms; clock drift causes error -1021 INVALID_TIMESTAMP
Binance: "If recvWindow is not sent, it defaults to 5000 milliseconds. Maximum recvWindow is 60000 milliseconds." And: "It is recommended to use a small recvWindow of 5000 or less!" Containers with clock drift greater than recvWindow are rejected with -1021. TradingHost runtimes are NTP-synced so the default 5000 is fine. Do not increase recvWindow unless you are seeing actual rejections, and never as a substitute for fixing time sync.
06 · Testnet split
Spot Testnet and Futures Testnet are separate environments
testnet.binance.vision (spot) and testnet.binancefuture.com (futures) issue separate keys, hold separate balances, and serve separate endpoints. A common silent auth failure is configuring a futures strategy with spot testnet keys, or shipping testnet-validated code to production without swapping the key set. Keep testnet and production secrets in separate TradingHost Secrets entries; never reuse one across environments.
Section 06 · Built for
Built for
TradingHost Binance runtimes are best suited to:
- Developers building strategies in AI IDEs (Cursor, Claude Code)
- Systematic crypto traders
- Quant developers
- CCXT, Freqtrade and Hummingbot users
- Teams moving from VPS hosting to containerised deployment
Connecting GitHub and creating your first strategy is free.
Section 08 · FAQ
FAQ
No. TradingHost is independent and is not affiliated with Binance.
No. Your strategy code connects to Binance and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. Binance API access is provided by Binance. You are responsible for your Binance account, API permissions, credentials and compliance with Binance’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-based Binance strategies run on TradingHost. 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 permissions (read, spot trade, futures trade) and IP whitelisting where appropriate.
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.
Error -2015 "Invalid API-key, IP, or permissions for action" usually means the request IP is not whitelisted on your key, or the key lacks permission for the endpoint (e.g. a spot key hitting a futures endpoint). On TradingHost, whitelist the published egress range for your selected region rather than a single IP, since containers reschedule. See the Operational notes section above for the full guidance.
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.