Read time … min

AI-native runtime for AscendEX 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
AscendEX
Venue type
Crypto exchange (formerly BitMax)
Asset class
Crypto
Supported products
Cash (spot) account, margin account and futures (v2) account; isolated and cross margin futures positions
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
Native AscendEX 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
AscendEX role
Exchange account, API access, market access, execution venue
Affiliation
TradingHost is independent and is not affiliated with AscendEX

Section 02 · What AscendEX offers

What AscendEX offers

AscendEX (rebranded from BitMax in March 2021) splits each account into three account objects (cashAccount, marginAccount, futuresAccount), and every private request URL has to carry the per-user `accountGroup` value returned at first auth. The futures v2 API runs on its own documentation surface. The legacy BitMax domains (bitmax.io, btmx.com, btmx.io) were decommissioned in May 2021 and are no longer routable. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, fee tiers and symbol lists live in AscendEX's docs.

Markets and strategy patterns

  • Spot strategies on USDT pairs
  • Margin lending and isolated-margin spot
  • USDT-margined perpetual futures (v2 API)
  • Cross-account transfers between cash, margin and futures
  • Isolated and cross margin futures positions
  • Per-account-object scoped API keys
  • WebSocket order-book and trade-stream consumers
  • Sub-account-isolated multi-strategy deployments

API surface

Product surfaces
AscendEX accounts hold three separate account objects: cashAccount (spot), marginAccount (margin) and futuresAccount (futures v2). Transfers between them are explicit. The futures v2 API runs on its own documentation set; the legacy BitMax domains (bitmax.io, btmx.com, btmx.io) were decommissioned in May 2021 and are no longer routable.
Connection methods
REST for order placement and account queries, with an `accountGroup` value required as a URL path prefix on private requests (the value comes from the account-info endpoint at first auth). WebSocket for market data and private account events. Public WebSocket streams are open; private subscriptions are auth-scoped.
Authentication
API key and secret signed with HMAC-SHA256. The account-info endpoint at first auth returns the `accountGroup` value, which then has to prefix every private request URL. A key is valid against a specific account-object pairing (cash, margin, futures); using a cash-account key on a futures endpoint returns a permission error rather than a transparent fallback.

For specifics, refer to AscendEX

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

Section 03 · Build with AI

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

    Direct control over AscendEX-specific behaviour, including the accountGroup-prefixed URL scheme and the cash/margin/futures account-object split.

  • CCXT

    Common interface across AscendEX and other crypto exchanges. CCXT exposes AscendEX spot and swap markets via the unified `ascendex` class.

    Get started with CCXT

  • Freqtrade or Hummingbot

    Framework-based deployments using their strategy structure and configuration model. Both list AscendEX among supported exchanges.

    Get started with FreqtradeGet started with Hummingbot

  • Custom connector

    Your own internal trading engine or proprietary AscendEX integration, handling the accountGroup discovery and HMAC-SHA256 signing scheme.

Framework support for AscendEX products

Coverage varies by framework. CCXT spans AscendEX spot and swap markets including futures v2; Freqtrade covers spot; Hummingbot covers spot with partial swap support; native AscendEX API covers everything AscendEX offers, including the cross-account transfers between cash, margin and futures.

FrameworkSpotPerpMarginFutures v2
Native AscendEX APISupportedSupportedSupportedSupported
CCXTSupportedSupportedPartially supportedSupported
FreqtradeSupportedNot documented as supportedNot documented as supportedNot documented as supported
HummingbotSupportedPartially supportedNot documented as supportedPartially supported

✓ confirmed support per official framework docs. "no" indicates not officially documented as supported. "partial" indicates limited coverage. Workflow links target /workflows/ pages currently in authoring.

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

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

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, Freqtrade 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 (AscendEX API key, secret and the accountGroup value returned by the account-info endpoint), 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 AscendEX

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

  1. 01 · accountGroup

    Private requests need an accountGroup prefix in the URL

    AscendEX private requests are routed under `https://ascendex.com/<accountGroup>/api/pro/...`. The `accountGroup` value is per-user and is returned by the account-info endpoint on first auth. A common silent failure is hard-coding `accountGroup` to a known value in a starter and forgetting it differs per account; private requests then 404 or return a routing error even though the key is correct. Fetch `accountGroup` once at strategy startup and cache it in the runtime's environment for the life of the deployment.

    SourceAscendEX Pro API authentication

  2. 02 · Account objects

    Cash, margin and futures are three separate account objects

    An AscendEX user account holds three account objects: `cashAccount` (spot), `marginAccount` (margin), and `futuresAccount` (futures v2). Each has its own balance and its own API scope. Transfers between them are explicit endpoints, not implicit margin moves. A strategy that expects to liquidate a futures position into the spot account has to call the transfer endpoint after closing the position; it does not happen automatically. Issue per-account-object keys for production strategies so a cash-account key cannot accidentally place a futures order.

    SourceAscendEX Pro API account structure

  3. 03 · Legacy domains

    bitmax.io, btmx.com and btmx.io stopped routing on May 21 2021

    AscendEX rebranded from BitMax in March 2021. The legacy domains (`bitmax.io`, `btmx.com`, `btmx.io`) were fully decommissioned at 15:00 UTC on May 21, 2021. Older integrations still pointing at those domains return DNS or routing failures. New integrations must target the AscendEX domains and the updated documentation. Legacy BitMax tutorials and forum posts are still discoverable on the open web; treat them as superseded and verify against the current docs before copying code.

  4. 04 · Risk isolation

    Isolated futures positions limit cross-account liquidation risk

    AscendEX futures supports both cross and isolated margin per position. Isolated positions cap the loss at the moved margin; a liquidation does not cascade into the cross-account or other positions. For multi-strategy deployments where one strategy is a bigger position than the rest, prefer isolated margin: an isolated liquidation cleans up cleanly without taking the other positions out with it. Document the margin mode in your repo so a redeploy never silently changes it.

    SourceAscendEX Futures v2 docs

  5. 05 · WebSocket scope

    Private WebSocket subscriptions are auth-scoped per account object

    AscendEX's private WebSocket channels are scoped to a specific account object (cash, margin, or futures). Subscribing to a private channel with a key issued against a different account object returns a subscription error rather than transparently swapping scopes. Match the WebSocket subscription path to the account object the key was issued against, and document the pairing alongside the key in your secrets manifest. A futures strategy that uses a cash-account key for order placement and a futures-account WebSocket subscription is a common mismatch source.

    SourceAscendEX Pro API WebSocket

Section 06 · Built for

Built for

TradingHost AscendEX 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 AscendEX.

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

No. AscendEX API access is provided by AscendEX. You are responsible for your AscendEX account, API permissions, credentials and compliance with AscendEX’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 AscendEX spot and swap markets via the unified `ascendex` 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. AscendEX's per-account-object key scoping pairs well with the multi-strategy model. 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 AscendEX API key, secret or accountGroup value. 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. AscendEX issues keys per account object so the cash, margin and futures sides each carry their own key surface; keep the withdrawal-capable key entirely separate and never on a strategy runtime.

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.

AscendEX private requests are routed under `https://ascendex.com/<accountGroup>/api/pro/...`. The `accountGroup` value is per-user and is returned by the account-info endpoint on first auth. If you copied a starter that hard-codes `accountGroup` to a known value or assumes it is `0`, requests will 404 even though the key is correct. Fetch `accountGroup` at startup, cache it in the runtime's environment, and never hard-code it. 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.