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

Nein. Ihr Strategie-Code verbindet sich direkt mit Bitget und sendet Aufträge basierend auf Ihrer eigenen Logik, Ihren Account-Berechtigungen und Ihrer gewählten Integrationsmethode. TradingHost stellt lediglich die Runtime bereit, in der dieser Code ausgeführt wird.

Nein. Der API-Zugang wird von Bitget bereitgestellt. Sie sind selbst für Ihren Bitget-Account, die API-Berechtigungen, Ihre Zugangsdaten und die Einhaltung der Nutzungsbedingungen von Bitget verantwortlich.

Nein. TradingHost ist die Cloud-Runtime, auf der Ihr eigener Strategie-Code ausgeführt wird. Wir bieten keine Handelssignale, KI-Vorhersagemodelle oder fertigen Bots an. Bei TradingHost schreiben oder generieren Sie Ihre Strategie selbst (häufig mit Cursor oder Claude Code), verwalten sie als Ihren eigenen Code in GitHub und nutzen TradingHost, um sie live auszuführen. Während Plattformen wie 3Commas oder Cryptohopper die Strategielogik vorgeben, führt TradingHost Ihre eigene Strategie aus.

AWS und DigitalOcean bieten Ihnen reine Rechenleistung. Sie müssen sich selbst um Betriebssystem-Updates, Container-Orchestrierung, Log-Weiterleitung, Secret-Rotation, Regionen-Failover und das Uptime-Monitoring kümmern. TradingHost bietet Ihnen eine verwaltete Runtime, die speziell für Trading-Strategien entwickelt wurde: GitHub-natives Deployment, MCP-basierte Steuerung direkt aus KI-IDEs sowie integrierte Log- und Statusübersichten. Wenn Sie die Infrastruktur selbst verwalten möchten, ist AWS eine Option. Wenn Sie die Runtime als Managed Service nutzen wollen, ist TradingHost der direktere Weg.

Ja. TradingHost führt Python-Strategien aus. Wählen Sie einfach die passende Framework-Runtime für Ihren Stack oder deployen Sie Ihr eigenes Repository.

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

Ja. CCXT stellt die Spot- und Perpetual-Märkte von Bitget über die einheitliche Klasse `bitget` bereit. Da Copy-Trading-Endpunkte in CCXT nicht standardmäßig integriert sind, laufen Copy-Trading-Prozesse über die native Bitget-V2-API. Details zur Einrichtung finden Sie in der Dokumentation zur CCXT-Framework-Runtime.

TradingHost ist auf Runtime-Ebene plattformunabhängig: Jeder Code, der sich gegenüber Bitget authentifizieren kann, läuft in einem Container – das gilt auch für Strategien auf einem Bitget-Copy-Trading-Parent-Account. Beachten Sie bei der Entwicklung, dass jede von Ihrer Strategie eröffnete Position entsprechende Copy-Orders auf allen verknüpften Follower-Accounts auslöst, gewichtet nach deren Einstellungen. Führen Sie kopierfähige Strategien auf einem separaten Sub-Account aus, getrennt von nicht-öffentlichen Strategien, und isolieren Sie die API-Keys pro Strategie, um Risiken zu minimieren.

Ja, sofern Ihr Projekt entsprechend strukturiert ist. Sie können mehrere Strategieprozesse oder -dienste innerhalb einer Runtime ausführen oder sie zur besseren Isolation und Übersichtlichkeit auf verschiedene Runtimes aufteilen. Weitere Informationen zum Multi-Strategie-Modell finden Sie auf der Runtime-Infoseite von TradingHost.

Der schnellste Weg ist das Forken einer TradingHost-Framework-Runtime, wie CCXT oder Hummingbot, für ein direkt einsatzbereites Projekt. Alternativ können Sie Ihr eigenes GitHub-Repository für Ihre Strategie anbinden. Das Verknüpfen eines GitHub-Repositorys und das Erstellen einer Strategie ist kostenlos; die Tarife für die Runtimes finden Sie auf unserer Preisseite.

In Ihrem von GitHub verwalteten Secrets-Workflow. TradingHost liest diese zur Laufzeit über GitHub Repository Secrets, Environment Secrets oder Ihren eigenen, freigegebenen Secret-Management-Prozess aus. TradingHost benötigt zu keinem Zeitpunkt Zugriff auf Ihren API-Key, Ihr Secret oder Ihre Passphrase. Details zum Sicherheitskonzept finden Sie unter Platform Secrets.

Nein. Strategien sollten niemals Auszahlungsrechte benötigen. Nutzen Sie stattdessen eingeschränkte Berechtigungen (Lesen, Spot-Handel, Futures-Handel) und richten Sie gegebenenfalls ein IP-Whitelisting ein.

Ja. TradingHost unterstützt die MCP-basierte Steuerung für KI-IDEs wie Cursor, Claude Code, GitHub Copilot sowie CLI-basierte KI-Agents. Diese KI-Tools können Deployments prüfen, Logs einsehen, Strategien neu starten und Runtime-Workflows verwalten. Das MCP dient dabei als Steuerungs- und Monitoring-Schnittstelle, nicht als Pfad für die Trade-Ausführung. Mehr dazu erfahren Sie unter MCP-Steuerung.

Beides. Die MCP-Steuerung funktioniert gleichermaßen über CLI-basierte Agents (Claude Code CLI, eigene MCP-Clients, skriptbasierte MCP-Aufrufe) wie auch direkt aus einer IDE heraus. Zudem funktioniert der GitHub-native Deployment-Prozess komplett ohne KI-Tools: Ein einfacher Git-Push auf Ihren Main-Branch löst ein automatisches Redeployment aus.

Die Runtime erkennt den Absturz automatisch und stellt die entsprechenden Logs sowie Statusinformationen bereit. Sofern unterstützt, kann die betroffene Strategie neu gestartet werden, ohne andere im selben Container laufende Strategien zu beeinträchtigen. Ihr Strategie-Code bleibt jedoch selbst für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Details finden Sie unter Monitoring für Logs und Statusübersichten.

Bitget 40009 bedeutet, dass die von Ihrer Strategie gesendete Signatur nicht mit dem erwarteten HMAC-SHA256-Wert aus Zeitstempel + Methode + requestPath + Body (signiert mit Ihrem Secret) übereinstimmt. Die häufigsten Ursachen sind ein fehlender oder falscher ACCESS-PASSPHRASE-Header, ein ACCESS-TIMESTAMP außerhalb des 30-Sekunden-Fensters, das Signieren mit dem falschen Secret (Test-Key vs. Produktions-Key) oder das Signieren des falschen kanonischen Request-Bodys (zusätzliche Leerzeichen, andere Reihenfolge der Keys). Nutzen Sie ein bewährtes SDK oder testen Sie den Signierungspfad per Unit-Test gegen die Bitget-Signaturreferenz. Weitere Details finden Sie oben im Abschnitt 'Betriebshinweise'.

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 liegt. Details zu Routing und physischer Nähe finden Sie auf der Regionen-Seite.

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