AI-native runtime for MEXC 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
- MEXC
- Venue type
- Crypto exchange
- Asset class
- Crypto (spot, USDT-M and coin-M perpetuals)
- Supported products
- Spot, USDT-M perpetual futures, coin-M perpetual futures. Futures are prohibited for users in the US, UK and various restricted jurisdictions.
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native MEXC Spot v3 and Contract v1 REST and WebSocket, CCXT, 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
- MEXC role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with MEXC.
Section 02 · What MEXC offers
What MEXC offers
MEXC offers spot trading on 2,000+ pairs through the Spot v3 API and USDT-M plus coin-M perpetual futures through the Contract v1 API on a separate documentation domain. Futures are prohibited in the US, UK and several other restricted jurisdictions. Strategies authenticate with HMAC-SHA256 against the Spot v3 surface with lowercase hex signatures. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, fee tiers and symbol lists live in MEXC's docs.
Markets and strategy patterns
- Spot strategies on 2,000+ trading pairs
- USDT-M perpetual futures strategies (restricted jurisdictions excluded)
- Coin-M perpetual strategies
- Funding-rate and basis trading on perpetuals
- Long-tail altcoin spot market making
- Sub-account-isolated multi-strategy deployments
- WebSocket private channel order and balance streams
- New-listing programmatic capture
API surface
- Product surfaces
- Spot v3 covers spot trading and account management. Contract v1 covers USDT-M and coin-M perpetual futures on a separate documentation domain. Futures are unavailable for users in restricted jurisdictions including the US and UK; geofencing applies at order submission, not just account creation.
- Connection methods
- REST for order placement and account queries. WebSocket streams for real-time market data, depth and trades. WebSocket User Data Streams for account, balance and order events. Spot and contract WebSocket endpoints are separate.
- Authentication
- API key and secret per strategy. Private requests are signed with HMAC-SHA256 against a sorted parameter string with lowercase hex output. recvWindow defaults to 5000 ms and is capped at 60000 ms. Permissions are scoped per key (read, trade, withdrawal). Strategies should never need withdrawal permission. IP whitelisting available; keys without IP whitelist auto-expire after 90 days.
For specifics, refer to MEXC
Specific endpoints, rate-limit weights, symbol lists, fee tiers and version history live in MEXC's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your MEXC 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 MEXC API
Direct control over MEXC-specific behaviour, contract-API access and order execution logic.
Hummingbot
Framework-based deployments using Hummingbot strategy structure and configuration model.
Custom connector
Your own internal trading engine or proprietary MEXC integration.
Framework support for MEXC products
Coverage varies by framework. CCXT spans MEXC spot and contracts; Hummingbot ships a spot-only connector; Freqtrade does not list MEXC as a supported exchange. Native MEXC API access reaches everything MEXC offers, including the contract API on its separate domain.
✓ 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
MEXC provides the exchange and API access. TradingHost provides the production environment where your MEXC-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 MEXC.
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 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 (MEXC 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 MEXC
Things that bite you when you actually run a MEXC strategy in a containerised cloud runtime, not in MEXC's docs, not in framework READMEs. Every claim below is quoted or paraphrased from MEXC's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Restricted markets
US and UK users are prohibited from futures trading and various spot pairs
MEXC enforces jurisdiction restrictions at order submission, not only at account creation. A US-based runtime hitting the contract endpoints returns access-denied errors regardless of account verification status. If your strategy targets MEXC futures, deploy from a TradingHost region whose egress geography is consistent with your user agreement and your own compliance posture; restricted-region containers will be refused at the venue boundary.
SourceMEXC Spot v3 API docs02 · Dual rate limits
IP and UID rate limits operate independently
MEXC enforces two separate rate-limit ceilings against every signed request: an IP-based limit and a UID-based limit. Spot endpoints generally cap at 500 requests per 10 seconds per endpoint; WebSocket connections cap at 100 messages per second with a maximum of 30 subscriptions per connection. Exceeding either ceiling returns 429s. Strategies that share an egress IP across many sub-accounts can hit the IP ceiling well before any single UID is near its quota; size your concurrency model against the lower of the two.
SourceMEXC Spot v3 API docs03 · Batch order limit
March 2025 cut: spot batch order endpoint reduced to 5 orders per second
MEXC published a rate-limit adjustment on March 25, 2025 cutting the spot batch order endpoint quota to 5 orders per second from its previous higher ceiling. Legacy market-making integrations that were sized against the older ceiling now exceed the new threshold and see 429s. Re-pace order submission against the current limit, and treat MEXC announcements as a tracked source rather than a one-time read.
04 · Key lifecycle
API keys: 30 max per account, 90-day auto-expiry if no IP whitelist
MEXC permits up to 30 API keys per account. Keys created without an IP whitelist auto-expire after 90 days; keys with an IP whitelist do not. Cloud runtimes do not have stable single egress IPs by default, so the right pattern on TradingHost is to use the published egress range for your selected region as the whitelist target, or accept the 90-day rotation cadence and automate key rotation into your secret-management workflow. Master accounts also cap at 30 sub-accounts.
SourceMEXC Spot v3 API docs05 · Signature format
HMAC signatures must be lowercase hex; recvWindow defaults 5000 ms, max 60000 ms
MEXC accepts HMAC-SHA256 signatures only in lowercase hex output. SDKs that emit uppercase hex or base64 see invalid-signature rejections that look like wrong-secret errors. recvWindow defaults to 5000 ms and is capped at 60000 ms; a container with clock drift greater than recvWindow is rejected. 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.
SourceMEXC Spot v3 API docs06 · Contract domain split
Contract API lives on a separate documentation domain with a distinct rate pool
MEXC publishes the Contract v1 API on mexcdevelop.github.io/apidocs/contract_v1_en/, a different documentation domain from spot v3. Contract endpoints sit behind a separate rate-limit pool: spot quota exhaustion does not throttle contract requests and vice versa. A strategy that needs both should be designed to budget two independent rate-limit envelopes, not a single shared one.
Section 06 · Built for
Built for
TradingHost MEXC runtimes are best suited to:
- Developers building strategies in AI IDEs (Cursor, Claude Code)
- Systematic crypto traders
- Quant developers
- CCXT 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 MEXC.
No. Your strategy code connects to MEXC and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. MEXC API access is provided by MEXC. You are responsible for your MEXC account, API permissions, credentials and compliance with MEXC’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 both MEXC spot and contract surfaces through the unified `mexc` class. See the CCXT framework runtime for the full setup story.
No. MEXC prohibits futures trading for users in the US, UK and several other restricted jurisdictions. The restriction is enforced at order submission, not only at account creation, so a US-egress container will see access-denied errors from the contract endpoints regardless of account verification status. Eligibility is decided by MEXC, not TradingHost. Pick a TradingHost region whose egress geography is consistent with both your user agreement and your own compliance posture.
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 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, 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.
MEXC enforces two independent rate-limit ceilings: an IP-based limit and a UID-based limit. Spot endpoints generally cap at 500 requests per 10 seconds; the batch order endpoint was cut to 5 orders per second in March 2025. WebSocket connections cap at 100 messages per second with a maximum of 30 subscriptions per connection. Size your concurrency against the lower of IP and UID, and re-pace order submission against the current batch limit. 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.