AI-native runtime for Bitvavo trading strategies

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

No. Bitvavo API access is provided by Bitvavo. You are responsible for your Bitvavo account, API permissions, credentials and compliance with Bitvavo’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. Bitvavo is supported in both CCXT and CCXT Pro under the exchange id bitvavo, covering REST and WebSocket. Bitvavo also publishes first-party SDKs in Python, Node.js, Go and Java if you prefer the native client. 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. See the TradingHost runtime page for the multi-strategy model.

The fastest path is to fork a TradingHost framework runtime: CCXT or Freqtrade 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 the Withdraw scope. Use the View and Trade scopes only, and enable IP whitelisting where appropriate. Bitvavo flags that withdrawals initiated via API bypass 2FA, so the Withdraw scope is high-risk and should be reserved for keys you operate manually from a fixed-IP host.

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.

This is Bitvavo’s IP-whitelist rejection. Either add the TradingHost runtime’s egress IP to the API key’s whitelist in the Bitvavo dashboard, or regenerate the key without a whitelist (not recommended). Confirm the egress IP via TradingHost’s runtime info before whitelisting.

The HMAC was built incorrectly or the API secret was copied with stray whitespace. Recompute the signature as HMAC-SHA256(secret, timestamp + method + url + body) hex digest, ensure the request body string matches exactly what is signed, and check that Bitvavo-Access-Timestamp is in milliseconds within the Bitvavo-Access-Window. Regenerating the key is the fastest fix if the secret may be corrupted.

No. Bitvavo is spot-only with 1:1 leverage; there are no futures, no perpetuals, no options and no margin product. For perpetuals or USD-M futures, deploy a separate strategy against Binance, Bybit or OKX.

Yes. Bitvavo is authorised under MiCA by the Dutch AFM (June 2025) and registered with De Nederlandsche Bank since 2020. The MiCA authorisation passports across the EEA, so an EEA-resident strategy operator can host on a licensed venue without separate per-country registrations. Bitvavo is a CASP, not a credit institution; this does not extend MiFID protections to trading activity.

EUR via free SEPA bank transfer (1 to 2 working days), SEPA Instant where your bank supports it, or iDEAL for instant Dutch-bank top-ups up to €50,000 per transaction. There is no USD fiat rail; USD-denominated PnL requires stablecoin or FX conversion.

TradingHost runs in the EU and US-East regions. For Bitvavo specifically, the EU region is geographically closest to Bitvavo’s Amsterdam-adjacent matching engine and usually gives the lowest round-trip. 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.