AI-native runtime for Uphold trading strategies

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

No. Uphold API access is provided by Uphold. You are responsible for your Uphold account, API permissions, credentials and compliance with Uphold’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; the typical pattern for Uphold is a custom Python client against the native Uphold REST APIs because there is no first-class CCXT, Freqtrade or Hummingbot connector.

Yes. TradingHost supports any language that can run inside a container.

CCXT does not list Uphold as a unified exchange because Uphold is swap-based rather than orderbook-based, which is outside CCXT's primary abstraction. Strategies that want a framework abstraction route through the native Uphold modular APIs directly. See the CCXT framework runtime for context on how the framework integration shape changes when a venue is not natively supported.

On an orderbook venue, you place a limit or market order against a depth-of-book and pay maker or taker fees. On Uphold, you request a swap quote from the venue, the quote is derived from pool depth and includes the venue spread, and you accept or refuse. There is no separate maker fee, no post-only flag, no orderbook depth subscription. Strategies must plan slippage against pool depth rather than book depth; larger swap sizes against thinner pools see disproportionately worse prices. Strategy code authored against an orderbook abstraction does not port to Uphold without rework. See the Operational notes section above for the full context.

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.

Uphold does not have framework starter kits the way Binance does, so the fastest path is to connect your own GitHub strategy repo that targets the native Uphold modular APIs (Core, Market Pulse, Topper) with a Personal Access Token. 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 Personal Access Token or OAuth credentials. See platform secrets for the full handling model.

A Personal Access Token grants bearer access to your single Uphold account. Strategies should be scoped to swap and read access only; if Uphold ever offers a finer-grained scoping for PATs in your account dashboard, prefer the tighter scope. Keep withdrawal off any token a strategy loads.

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.

The Uphold swap model does not expose native slippage-protection thresholds the way an orderbook venue would. Strategies must implement slippage controls client-side: request the quote, compare against a price-feed reference, and accept or refuse based on the strategy's own tolerance. Larger swap sizes against thinner pools see disproportionately worse prices, so size scaling is not linear. 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.