KI-native Runtime für Bitstamp-Trading-Strategien

Nein. Ihr Strategiecode verbindet sich mit Bitstamp und sendet Anweisungen gemäß Ihrer eigenen Logik, Ihren Kontoberechtigungen und Ihrer Integrationsmethode. TradingHost stellt die Runtime bereit, in der dieser Code ausgeführt wird.

Nein. Der Zugang zur Bitstamp-API wird von Bitstamp bereitgestellt. Sie sind selbst für Ihr Bitstamp-Konto, die API-Berechtigungen, Ihre Zugangsdaten und die Einhaltung der Nutzungsbedingungen von Bitstamp verantwortlich.

Keine wesentlichen Änderungen. Robinhood hat die Übernahme am 2. Juni 2025 abgeschlossen, und Bitstamp läuft weiterhin unter eigener Marke, mit eigener API-Struktur, eigenem FIX-Gateway und eigenem Lizenzportfolio. Authentifizierung, Endpunkte, Sub-Accounts und Rate Limits bleiben unverändert. Robinhood Crypto bleibt ein separater Handelsplatz mit einer separaten API.

Nein. TradingHost ist die Cloud-Runtime, in der Ihr Strategiecode ausgeführt wird. Wir bieten keine Signale, KI-Vorhersagemodelle oder vorgefertigte Strategien an. Mit TradingHost schreiben oder generieren Sie die Strategie selbst (oft mit Cursor oder Claude Code), verwalten sie als Ihren eigenen Code in GitHub und nutzen TradingHost, um sie in der Produktion auszuführen. Während 3Commas, Cryptohopper und ähnliche Produkte die Strategielogik vorgeben, führt TradingHost Ihre eigene Strategie aus.

AWS and DigitalOcean bieten Ihnen reine Rechenleistung. Sie müssen sich selbst um Betriebssystem-Updates, Container-Orchestrierung, Log-Weiterleitung, Secret-Rotation, Regionen-Failover und Uptime-Monitoring kümmern. TradingHost bietet Ihnen eine verwaltete Runtime, die speziell für Handelsstrategien entwickelt wurde: GitHub-natives Deployment, MCP-gesteuerte Kontrolle über AI-IDEs sowie direkt einsatzbereite Log- und Health-Dashboards. Wenn Sie die Infrastruktur selbst verwalten möchten, ist AWS eine Option. Wenn Sie die Runtime als Managed Service nutzen möchten, ist TradingHost der direktere Weg.

Ja. TradingHost führt Python-Strategien aus. Wählen Sie einfach die Framework-Runtime, die zu Ihrem Stack passt, oder deployen Sie Ihr eigenes Repository.

Ja. TradingHost unterstützt jede Programmiersprache, die in einem Container ausgeführt werden kann.

Ja. Die Exchange-ID `bitstamp` von CCXT deckt den Spot-Handel vollständig ab. Da Margin-, Swap-, Future- und Option-Flags in der vereinheitlichten Konfiguration deaktiviert sind, sollten Sie den Derivate-Flow stattdessen über die native FIX- oder HTTP-Schnittstelle von Bitstamp leiten. Instanziieren Sie CCXT innerhalb des TradingHost-Containers mit dem API-Key und dem Secret aus den Runtime-Secrets, nicht aus dem Repository. Details finden Sie in der Dokumentation zur CCXT-Framework-Runtime.

Ja. Bitstamp unterstützt Sub-Accounts und Berechtigungen pro Key. Jeder Request kann über den Header X-Auth-Subaccount-Id auf einen bestimmten Sub-Account beschränkt werden. Erstellen Sie auf TradingHost einen Key pro Deployment, beschränken Sie dessen Berechtigungen auf das für die Strategie absolut Notwendige, setzen Sie die Egress-IPs von TradingHost auf die Whitelist und isolieren Sie die Keys pro Sub-Account, damit eine Strategie nicht die Orders einer anderen lesen oder stornieren kann. Weitere Informationen zum Multi-Strategie-Modell finden Sie auf der TradingHost-Runtime-Seite.

Der schnellste Weg ist das Forken einer TradingHost-Framework-Runtime: CCXT, Freqtrade oder Hummingbot bieten direkt einsatzbereite Projekte. Alternativ können Sie Ihr eigenes GitHub-Strategie-Repository verknüpfen. Das Verknüpfen eines GitHub-Repositorys und das Erstellen einer Strategie ist kostenlos. Die Runtime-Tarife finden Sie auf der Preisseite.

In Ihrem von GitHub gesteuerten Secrets-Workflow. TradingHost liest sie zur Laufzeit über GitHub-Repository-Secrets, Environment-Secrets oder Ihren eigenen freigegebenen Secret-Management-Prozess aus. TradingHost benötigt keinen direkten Zugriff auf Ihren API-Key und Ihr Secret. Details zum Sicherheitsmodell finden Sie unter Platform Secrets.

Nur die absolut notwendigen Mindestrechte. Bitstamp unterstützt Berechtigungen pro Key, sodass eine Market-Making-Strategie beispielsweise nur Lese- und Handelsrechte erhält, aber niemals Auszahlungsrechte. Verknüpfen Sie jeden Key mit einem IP-Whitelisting für den Egress-Bereich der TradingHost-Runtime in Ihrer gewählten Region, und beschränken Sie ihn bei Bedarf über X-Auth-Subaccount-Id auf einen bestimmten Sub-Account, um Strategien sauber voneinander zu isolieren.

Ja, über Bitstamp USA Inc., die eine NYDFS BitLicense sowie staatliche Geldtransferlizenzen und eine FinCEN MSB-Registrierung besitzt. Die Verfügbarkeit in den einzelnen Bundesstaaten variiert, prüfen Sie daher die Abdeckung von Bitstamp USA. Die API-Schnittstelle von Bitstamp USA entspricht im Wesentlichen der globalen Schnittstelle für die dort angebotenen Produkte.

Ja. TradingHost unterstützt die MCP-basierte Steuerung für KI-IDEs wie Cursor, Claude Code, GitHub Copilot und CLI-basierte KI-Agents. KI-Tools können Deployments überprüfen, Logs einsehen, Strategien neu starten und Runtime-Workflows verwalten. MCP ist eine Steuerungs- und Observability-Ebene, nicht der Pfad für die Orderausführung. Siehe MCP-Steuerungsebene für alle Details.

Beides. Die MCP-Steuerungsebene funktioniert mit CLI-basierten Agents (Claude Code CLI, benutzerdefinierten MCP-Clients, geskripteten MCP-Aufrufen) ebenso gut wie direkt aus einer IDE heraus. Der GitHub-native Deployment-Prozess funktioniert zudem völlig ohne KI-Tools: Ein normaler git push auf Ihren main-Branch löst ein erneutes Deployment aus.

Die Runtime erkennt den Absturz und stellt die entsprechenden Logs und Statusinformationen bereit. Sofern unterstützt, kann die betroffene Strategie neu gestartet werden, ohne andere im selben Container ausgeführte Strategien zu beeinträchtigen. Ihr Strategiecode ist weiterhin selbst für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Siehe Observability für Logs und Status-Ebene.

Die v2-Authentifizierung von Bitstamp behandelt jeden X-Auth-Nonce als einmalig verwendbar innerhalb eines 150-Sekunden-Fensters und weist Zeitstempel ab, die mehr als 150 Sekunden von der Serverzeit abweichen. Die Ursache für diesen Fehler ist fast immer ein horizontal skaliertes Deployment, bei dem sich mehrere Worker einen Key teilen, oder zwei co-lokalisierte Strategien, die um denselben Nonce konkurrieren. Beheben Sie dies, indem Sie die Nonce-Quelle serialisieren (ein monoton steigender Generator pro Key) oder indem Sie einen Key pro Worker erstellen und beide Egress-IPs auf die Whitelist setzen.

TradingHost läuft in den Regionen EU und US-East. Wählen Sie die Region, die der von Ihrer Strategie genutzten Matching-Engine am nächsten ist. Details zu Routing und Latenzen finden Sie auf der Regions-Seite.

Nein. TradingHost konzentriert sich rein auf die Produktions-Runtime und das Deployment. Backtesting gehört in Ihren Research-Stack, Ihr Framework oder AlgoBuilder.