Read time … min

AI-native runtime for BitMEX 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.

By the TradingHost engineering team

Section 01 · At a glance

At a glance

Venue
BitMEX
Venue type
Crypto exchange (perpetual futures pioneer)
Asset class
Crypto derivatives (perpetual swaps and futures)
Supported products
XBTUSD inverse perpetual (each contract 1 USD notional), USDT and BTC-quoted perpetual swaps, dated futures, prediction-market style contracts on select underlyings. Testnet available at testnet.bitmex.com. US users are blocked via IP geolocation on API keys.
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
Native BitMEX 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
BitMEX role
Exchange account, API access, market access, execution venue
Affiliation
TradingHost is independent and is not affiliated with BitMEX.

Section 02 · What BitMEX offers

What BitMEX offers

BitMEX pioneered the crypto perpetual swap and remains a derivatives-only venue. XBTUSD is the flagship inverse perpetual, with each contract worth 1 USD notional and settled in Bitcoin. USDT-quoted and BTC-quoted perpetuals plus dated futures fill out the surface. All Bitcoin quantities are denominated in XBt (satoshis) and all USD quantities in USDt; client-side conversion is required. Endpoint specifics change over time. The shape is durable; the precise contract specs, rate-limit weights and fee tiers live in BitMEX's docs.

Markets and strategy patterns

  • XBTUSD inverse perpetual market making
  • BTC-quoted perpetual swap strategies
  • USDT-quoted perpetual swap strategies
  • Dated futures basis and calendar spread trading
  • Funding-rate carry on inverse perpetuals
  • Testnet-validated deployments before mainnet rollout
  • WebSocket private channel order and position streams
  • Cross-venue arbitrage paired with non-BitMEX spot or derivatives venues

API surface

Product surfaces
Perpetual swaps (XBTUSD inverse, USDT-quoted, BTC-quoted), dated futures, and prediction-market style contracts on select underlyings. Testnet at testnet.bitmex.com mirrors the production API surface with distinct keys and balances.
Connection methods
REST at https://www.bitmex.com/api/v1 for order placement and account queries. WebSocket streams for real-time market data, depth and trades. WebSocket private channels for account, position and order events.
Authentication
Permanent API key and secret per strategy. Private requests are signed with HMAC-SHA256 against verb + path + nonce + body. The nonce can be either a Unix-epoch microsecond timestamp or an api-expires header value. US users are blocked via IP geolocation enforcement on API keys; key creation succeeds but trading endpoints refuse access.
Denomination
All Bitcoin amounts are denominated in XBt (satoshis, 1 XBt = 0.00000001 XBT). All USD amounts are denominated in USDt (1 USDt = 0.000001 USDT). XBTUSD perpetual contracts are 1 USD notional each, settled in Bitcoin. Client-side conversion is required to render or reason in standard BTC or USD units.

For specifics, refer to BitMEX

Specific endpoints, contract specifications, rate-limit weights, fee tiers and version history live in BitMEX's documentation. Treat these as the source of truth.

Section 03 · Build with AI

Build your BitMEX 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 BitMEX API

    Direct control over BitMEX-specific behaviour, XBt and USDt denominations and order execution logic.

  • CCXT

    Common interface across BitMEX and other crypto derivatives venues.

    Get started with CCXT

  • Hummingbot

    Framework-based deployments using Hummingbot strategy structure and configuration model.

    Get started with Hummingbot

  • Custom connector

    Your own internal trading engine or proprietary BitMEX integration.

Framework support for BitMEX products

BitMEX is a derivatives-only venue: no spot column in the matrix. CCXT exposes perpetuals and dated futures through the unified bitmex class; Hummingbot covers perpetual swaps through bitmex_perpetual; Freqtrade does not list BitMEX as a supported exchange. Native BitMEX API access reaches every contract BitMEX lists.

FrameworkPerpFuturesOptions
Native BitMEX APISupportedSupportedNot documented as supported
CCXTSupportedSupportedNot documented as supported
HummingbotSupportedNot documented as supportedNot documented as supported
FreqtradeNot documented as supportedNot documented as supportedNot documented as supported

✓ 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

BitMEX provides the exchange and API access. TradingHost provides the production environment where your BitMEX-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 BitMEX.

TradingHost

  • Keeps the runtime online.
  • Surfaces logs and health checks.
  • Region selection.
  • Controlled deployment surface.

Deployment flow

  1. STEP 01

    Connect GitHub

    Authorise TradingHost to access your GitHub account.

  2. 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.

  3. STEP 03

    Deploy into a TradingHost container

    Pick a region (EU or US-East), supply the environment values your strategy needs (BitMEX API key and secret, etc.), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.

  4. 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.

  5. STEP 05

    Update and redeploy

    Push changes to your GitHub main branch and TradingHost redeploys automatically.

Deploy

Section 05 · Operational notes

Operational notes for BitMEX

Things that bite you when you actually run a BitMEX strategy in a containerised cloud runtime, not in BitMEX's docs, not in framework READMEs. Every claim below is quoted or paraphrased from BitMEX's own documentation; the deployment-side guidance is from running these strategies on TradingHost.

  1. 01 · XBt denomination

    All Bitcoin amounts are in satoshis (1 XBt = 0.00000001 XBT); USD in USDt (1 USDt = 0.000001 USDT)

    BitMEX API responses use non-standard denominations. Bitcoin balances, walletBalance fields, position margin and order notional values are all expressed in XBt (satoshis), not XBT. USD-quoted amounts are in USDt, six decimal places below USDT. Strategies that render or reason about positions in user-facing units must convert client-side. The most common shipping-day bug is a strategy that intends to size a 0.1 BTC position and instead sizes 0.1 XBt because the conversion was forgotten.

    SourceBitMEX API overview

  2. 02 · XBTUSD contract

    Each XBTUSD perpetual contract is 1 USD notional, settled in Bitcoin (inverse)

    XBTUSD is an inverse perpetual: each contract represents 1 USD of notional exposure, with PnL and margin settled in Bitcoin. Liquidation price calculations are in USD terms. This differs from a linear USDT-margined perp where contract size scales with the underlying coin amount. Strategies that mix venues must encode contract multiplier and settlement currency per instrument rather than assume a single shape across the book.

    SourceBitMEX API overview

  3. 03 · US geofence

    US users are blocked via IP geolocation enforcement on API keys

    BitMEX prohibits US-based traders. The enforcement is applied at the API key level by IP geolocation: a key whose recent traffic geolocates to the US sees private endpoints refused regardless of account verification status. A TradingHost runtime in the US-East region with US egress will be blocked from trading on BitMEX. Pick a TradingHost region whose egress geography is consistent with both BitMEX user agreement and your own compliance posture.

    SourceBitMEX API overview

  4. 04 · Nonce signing

    HMAC-SHA256 signature over verb + path + nonce + body; api-expires preferred over raw nonce

    BitMEX REST signatures are HMAC-SHA256 of the concatenation verb + path + nonce + body, signed with your secret. The nonce can be either a Unix microsecond timestamp or, preferred, an api-expires header that gives the request a future expiry timestamp. Using api-expires sidesteps the strict monotonic-nonce requirement and is more robust to clock skew across containers. Most BitMEX SDKs default to api-expires; check yours and pin it.

    SourceBitMEX API overview

  5. 05 · Permanent keys

    API keys are permanent until manually revoked; testnet keys are isolated

    BitMEX API keys do not auto-expire. Rotation is a manual responsibility: rotate keys periodically rather than relying on platform expiry. The testnet at testnet.bitmex.com issues separate keys, holds separate balances and serves separate endpoints; a common silent auth failure is shipping testnet-validated code to production without swapping the key set, or vice versa. Keep testnet and production secrets in separate TradingHost Secrets entries; never reuse one across environments.

    SourceBitMEX API overviewBitMEX testnet

  6. 06 · Rate limits

    Per-minute REST rate limit on private endpoints; WebSocket strongly preferred for hot loops

    BitMEX rate-limits private REST endpoints on a per-minute window. The recommended pattern for active strategies is to drive market data and account state from WebSocket subscriptions and only use REST for the actions WebSocket cannot perform (order placement, cancellation). Polling REST in a tight loop for orderbook updates or position state will exhaust the quota and produce 429s.

    SourceBitMEX API overview

Section 06 · Built for

Built for

TradingHost BitMEX runtimes are best suited to:

  • Developers building strategies in AI IDEs (Cursor, Claude Code)
  • Systematic crypto traders
  • Quant developers
  • CCXT and Hummingbot users
  • Derivatives-focused desks and perpetual market makers
  • 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 BitMEX.

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

No. BitMEX API access is provided by BitMEX. You are responsible for your BitMEX account, API permissions, credentials and compliance with BitMEX’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 BitMEX through the unified `bitmex` class, covering perpetuals and dated futures. There is no spot product to support. See the CCXT framework runtime for the full setup story.

No. BitMEX prohibits US-based traders. The enforcement is applied at the API key level by IP geolocation: a key whose recent traffic geolocates to the US sees private endpoints refused regardless of account verification status. A TradingHost runtime in the US-East region with US egress will be blocked from trading on BitMEX. Pick a TradingHost region whose egress geography is consistent with both BitMEX 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 BitMEX API key and secret. See platform secrets for the full handling model.

No. Strategies should never need withdrawal permissions. Use scoped permissions (order, account read) and rotate keys manually because BitMEX keys do not auto-expire.

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.

BitMEX denominates all Bitcoin amounts in XBt (satoshis). 1 XBt = 0.00000001 XBT, so a balance you read as 100,000,000 XBt is 1 BTC. USD amounts are in USDt, six decimal places below USDT. The most common shipping-day bug is a strategy that intends to size in BTC and instead sizes in XBt because the conversion was forgotten. XBTUSD perpetual contracts are 1 USD notional each, settled in Bitcoin. 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.