AI-native runtime for Phemex 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
- Phemex
- Venue type
- Crypto exchange
- Asset class
- Crypto
- Supported products
- Spot, USDT and inverse perpetual contracts, dated futures, sub-accounts, plus a public testnet
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native Phemex REST and WebSocket, 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
- Phemex role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with Phemex
Section 02 · What Phemex offers
What Phemex offers
Phemex offers spot, USDT-margined perpetuals, inverse perpetuals and dated futures via REST and WebSocket APIs. Authentication is HMAC-SHA256 with an explicit request expiry timestamp, and the rate limiter splits into three independent groups (contract, spotOrder, others) so a busy contract loop does not throttle spot orders. A separate testnet at testnet-api.phemex.com lets you validate against the same API shape without real capital. Phemex US runs as a distinct entity; the global API does not cover it. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, fee tiers and symbol lists live in Phemex's docs.
Markets and strategy patterns
- USDT-margined perpetual contract strategies
- Inverse (coin-margined) perpetual contracts
- Spot strategies on USDT and BTC pairs
- Sub-account-isolated multi-strategy deployments
- Testnet-validated deployments before mainnet rollout
- Funding-rate carry on perpetuals
- WebSocket order book and trade stream consumers
- Cross-rate-limit-group execution (contract + spot)
API surface
- Product surfaces
- Spot, USDT-margined perpetuals, inverse (coin-margined) perpetuals, dated futures, and sub-account hierarchies. A public testnet at testnet-api.phemex.com runs against a separate pool with its own rate budget and cannot trade real assets. Phemex US operates as a distinct entity on separate infrastructure; global Phemex accounts are not interchangeable with Phemex US accounts.
- Connection methods
- REST for order placement and account queries. WebSocket for real-time market data, order book updates, trades and account events. Private WebSocket subscriptions require auth on the connection.
- Authentication
- API key, secret and a request expiry timestamp signed with HMAC-SHA256. Three rate-limit groups (contract, spotOrder, others) each carry their own request budget; exceeding one does not throttle the others. Sub-accounts can hold keys with permissions scoped beneath the parent.
For specifics, refer to Phemex
Specific endpoints, rate-limit weights, symbol lists, fee tiers and version history live in Phemex's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your Phemex 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 Phemex API
Direct control over Phemex-specific behaviour, account data and order execution logic across spot, USDT perps and inverse perps.
CCXT
Common interface across Phemex and other crypto exchanges. CCXT exposes Phemex spot and perpetual swap markets via the unified `phemex` class.
Freqtrade or Hummingbot
Framework-based deployments using their strategy structure and configuration model. Both list Phemex among supported exchanges.
Custom connector
Your own internal trading engine or proprietary Phemex integration, signing requests with HMAC-SHA256 against the published expiry-stamped scheme.
Framework support for Phemex products
Coverage varies by framework. CCXT spans the broadest Phemex surface for spot and perpetual swap; Freqtrade and Hummingbot cover spot, with perpetual support depending on connector version; native Phemex API access covers everything Phemex offers, including inverse contracts and sub-account hierarchies.
✓ confirmed support per official framework docs. "no" indicates not officially documented as supported. "partial" indicates limited coverage, see prose above for detail.
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
Phemex provides the exchange and API access. TradingHost provides the production environment where your Phemex-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 Phemex.
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 (Phemex API key, secret and the expiry timestamp scheme your code uses), 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 Phemex
Things that bite you when you actually run a Phemex strategy in a containerised cloud runtime, not in Phemex's docs, not in framework READMEs. Every claim below is quoted or paraphrased from Phemex's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Rate-limit split
Three independent request groups: contract, spotOrder, others
Phemex's API rate limiter is split into three independent groups rather than one global pool. The `contract` group covers contract trading endpoints, `spotOrder` covers spot order placement, and `others` covers everything else. Each group carries its own request budget; exceeding one does not throttle the others. Plan a strategy that touches both spot and perp surfaces against the per-group budget, not against a single combined cap.
02 · Request expiry
Every signed request needs an explicit expiry timestamp
Phemex's signature scheme requires an explicit expiry timestamp on every authenticated request (in Unix seconds, typically `now + 60`). Requests with an expiry already past or set unreasonably far in the future are rejected. A common silent failure: client code computes the expiry once at startup and reuses it across calls, so after a minute every request 401s. Compute the expiry at signing time, not at construction time, and keep container clocks NTP-synced.
03 · Testnet pool
Testnet runs on a separate host with its own keys and rate budget
Phemex testnet at `testnet-api.phemex.com` issues separate API keys, holds separate balances and serves separate endpoints. A common silent auth failure is configuring a production strategy with 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. The testnet rate budget is materially lower than mainnet; do not size strategy throughput from testnet observations.
SourcePhemex testnet docs04 · US separation
Phemex US is a separate entity with its own infrastructure
Phemex US (`phemex.com/us`) operates as a distinct corporate entity from global Phemex and runs on separate infrastructure. A global Phemex account does not grant Phemex US access, and a Phemex US account cannot sign requests against global Phemex endpoints. If your strategy moves between US and non-US jurisdictions, encode venue selection as a first-class config value, not a switch on key type. Restricted-jurisdiction enforcement is handled at account creation and may reject API requests with IP-based rejections.
05 · Post-incident posture
Re-issue keys post-January 2025 if you held one through the incident
Phemex disclosed a hot-wallet security incident on January 23 2025 at 11:30 UTC. Deposits and withdrawals were temporarily suspended; cold-wallet funds were unaffected. The exchange engaged third-party security firms and law enforcement and gradually restored services in the following weeks. If you held a Phemex API key through that period and have not rotated it since, treat the key as suspect and re-issue. The signing scheme itself is unchanged; the operational hygiene point is to rotate any key that pre-dates the post-incident posture changes.
06 · Sub-account scoping
Sub-accounts hold their own keys; route per-strategy keys through them
Phemex sub-accounts are a first-class boundary: each sub-account holds its own balance, its own positions and its own API keys. Per-strategy keys scoped to a sub-account contain the blast radius if a key leaks, and let you cap each strategy at the sub-account balance rather than the full account. Use one sub-account per production strategy as a default pattern, with a separate operational key on the parent for transfers between sub-accounts that should not be reachable from strategy code.
Section 06 · Built for
Built for
TradingHost Phemex 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 Phemex.
No. Your strategy code connects to Phemex and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. Phemex API access is provided by Phemex. You are responsible for your Phemex account, API permissions, credentials and compliance with Phemex’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 Phemex spot and perpetual swap markets via the unified `phemex` class. Drop your CCXT strategy into a container, point it at GitHub, and TradingHost runs it like any other Python or Node project. 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. Phemex sub-accounts pair naturally with the multi-strategy model: scope a key per sub-account and per strategy. 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 Phemex 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 keep withdrawal off the strategy key entirely. Phemex sub-accounts let you contain the blast radius per strategy, so the master account never holds a withdrawal-capable strategy key.
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.
Phemex's rate limiter splits into three independent groups (contract, spotOrder, others), and exceeding one does not throttle the others. If your contract loop is being throttled while spot keeps working, the contract group's budget is the constraint, not the global account. Back off the contract rate, or split contract and spot work onto separate sub-accounts each with their own keys. 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.