KI-native Runtime für WhiteBIT-Trading-Strategien
Entwickeln Sie in Cursor, Claude Code oder einer beliebigen KI-IDE. Deployen Sie direkt aus GitHub in eine verwaltete Cloud-Runtime mit erstklassiger MCP-Steuerung, Logs und Regionen-Auswahl.
Sektion 01 · Auf einen Blick
Auf einen Blick
- Handelsplatz
- WhiteBIT
- Handelsplatz-Typ
- Krypto-Börse (global)
- Anlageklasse
- Krypto
- Unterstützte Produkte
- Spot, Perpetual Futures, Isolated Margin. Gestaffelte Rate-Limits pro Endpunkt; kein öffentliches Testnet (Integrationstests erfolgen über die Live-API mit Mindestbestellgrößen).
- Laufzeit-Modell
- Containerisierte Strategie-Runtime
- Deployment-Quelle
- GitHub
- Programmiersprachen
- Jede Programmiersprache, die in einem Container läuft
- Gängige Integrationen
- Native WhiteBIT REST- und WebSocket-APIs, CCXT, eigene Connectoren
- KI-Workflow-Integration
- MCP-Steuerungsoberfläche für Cursor, Claude Code, GitHub Copilot und CLI-Agents
- Rolle von TradingHost
- Runtime, Deployment, Logs, Health Checks, Regionen-Auswahl, MCP-Steuerung
- Rolle von WhiteBIT
- Börsenkonto, API-Zugriff, Marktzugang, Ausführungsplatz
- Verbindung
- TradingHost ist unabhängig und steht in keiner Verbindung zu WhiteBIT
Sektion 02 · Das Angebot von WhiteBIT
Das Angebot von WhiteBIT
WhiteBIT bietet Spot, Perpetual Futures und Isolated Margin über REST- und WebSocket-APIs mit gestaffelten Rate-Limits pro Endpunkt. Wichtige operative Besonderheit: Es gibt kein öffentliches Testnet, weshalb Integrationstests direkt gegen die Live-API mit Mindestbestellgrößen durchgeführt werden müssen. Copy-Trading, Auto-Invest und Staking sind nur über die Plattform-UI verfügbar und bieten keinen API-Zugriff. Die Details der Endpunkte können sich ändern. Die grundlegende Struktur bleibt jedoch bestehen; genaue Rate-Limits, Symbollisten und Gebührenstufen finden Sie in der Dokumentation von WhiteBIT.
Märkte und Strategiemuster
- Spot-Trading für Paare mit USDT-, BTC- und ETH-Notierung
- Perpetual-Futures-Strategien
- Isolated-Margin-Strategien
- WebSocket-Abonnement mit bis zu 200 Nachrichten pro Minute und Verbindung
- Gestaffeltes Rate-Limit-Budgeting pro Endpunkt
- Integrationstests auf der Live-API (kein öffentliches Testnet verfügbar)
- Guthabentransfer zwischen Trade Balance und Main Balance
- API-gesteuerte Strategien ohne plattformexklusive Funktionen (Copy-Trading, Auto-Invest)
API-Schnittstelle
- Produktbereiche
- Spot, Perpetual Futures und Isolated Margin. Copy-Trading, Auto-Invest und Staking existieren zwar auf WhiteBIT, sind jedoch plattformexklusiv (kein API-Zugriff). Strategien, die auf diese Funktionen angewiesen sind, erfordern manuelle Zwischenschritte.
- Verbindungsmethoden
- REST-API für Orderplatzierung und Kontoabfragen mit gestaffelten Rate-Limits pro Endpunkt: Main Balance 1.000 Anfragen pro 10 Sekunden, Trade Balance 12.000 pro 10 Sekunden, Order-Erstellung 10.000 pro 10 Sekunden, öffentliche Märkte 2.000 pro 10 Sekunden. WebSocket erlaubt bis zu 1.000 gleichzeitige Verbindungen pro Minute mit 200 Nachrichten pro Minute und Einzelverbindung.
- Authentifizierung
- API-Key und Secret pro Strategie mit HMAC-signierten Anfragen. Berechtigungen können pro Key eingeschränkt werden. WebSocket-Abonnements für private Kanäle erfordern einen Token-Refresh-Flow, den der Client selbst verwalten muss.
Details finden Sie direkt bei WhiteBIT
Spezifische Endpunkte, Rate-Limit-Gewichtungen, Symbollisten, Gebührenstufen und die Versionshistorie finden Sie in der Dokumentation von WhiteBIT. Betrachten Sie diese als maßgebliche Quelle.
Sektion 03 · Mit KI entwickeln
Entwickeln Sie Ihre WhiteBIT-Strategie mit KI
Wählen Sie eine Integrationsmethode, forken Sie ein TradingHost-Framework-Starter-Repository und schreiben Sie Ihre Strategie in einer AI IDE. Cursor, Claude Code, GitHub Copilot und CLI-basierte KI-Agenten nutzen alle denselben GitHub-nativen Deployment-Prozess.
Native WhiteBIT-API
Direkte Kontrolle über WhiteBIT-spezifisches Verhalten, Guthabentransfers und gestaffelte Rate-Limits.
CCXT
Einheitliche Schnittstelle für WhiteBIT und andere Krypto-Börsen. CCXT stellt WhiteBIT über die vereinheitlichte Klasse `whitebit` für das Spot-Trading bereit.
Freqtrade oder Hummingbot
Keines der beiden Frameworks führt WhiteBIT derzeit als nativ unterstützte Börse. Eigene oder CCXT-basierte Implementierungen sind der dokumentierte Weg.
Eigener Connector
Ihre eigene interne Trading-Engine oder proprietäre WhiteBIT-Integration direkt über die REST- und WebSocket-APIs.
Framework-Unterstützung für WhiteBIT-Produkte
Die Abdeckung variiert je nach Framework. CCXT unterstützt WhiteBIT-Spot über die vereinheitlichte Klasse `whitebit`; die Abdeckung von Futures und Margin in CCXT ist unvollständig. Weder Freqtrade noch Hummingbot führen WhiteBIT derzeit als nativ unterstützte Börse. Der native API-Zugriff deckt alle von WhiteBIT angebotenen Produkte ab, einschließlich Futures und Isolated Margin.
✓ Bestätigter Support laut offizieller Framework-Dokumentation. „nein“ bedeutet, dass kein offizieller Support dokumentiert ist. „teilweise“ weist auf eine eingeschränkte Abdeckung hin. Workflow-Links verweisen auf /workflows/-Seiten, die sich derzeit in der Erstellung befinden.
TradingHost schreibt kein Framework vor. Es führt Ihr Projekt einfach aus.
Mit KI programmieren
Die oben genannten Framework-Starter lassen sich nahtlos mit KI-IDEs kombinieren. Die TradingHost-MCP-Steuerungsebene schließt den Kreis: KI-Tools können Deployments analysieren, Logs prüfen und die Laufzeitumgebung gemeinsam mit Ihnen verwalten, ohne jemals in den Pfad der Trade-Ausführung einzugreifen.
Bereich 04 · Auf TradingHost ausführen
Ihren Code auf TradingHost ausführen
WhiteBIT stellt die Börse und den API-Zugang bereit. TradingHost liefert die Produktionsumgebung, in der Ihre mit WhiteBIT verbundene Strategie läuft.
Statt Ihren Strategie-Code auf einem Laptop, Desktop-PC, einem gewöhnlichen VPS oder einem manuell konfigurierten Server auszuführen, deployen Sie direkt aus GitHub in eine von TradingHost verwaltete Container-Runtime.
Sie
- Ihr Repository enthält Ihren Code.
- Ihr Deployment definiert, wie er ausgeführt wird.
- Ihre Strategie verbindet sich mit WhiteBIT.
TradingHost
- Hält die Runtime online.
- Stellt Logs und Health-Checks bereit.
- Auswahl der Region.
- Kontrollierte Deployment-Umgebung.
Deployment-Ablauf
- SCHRITT 01
GitHub verbinden
Autorisieren Sie TradingHost für den Zugriff auf Ihr GitHub-Konto.
- SCHRITT 02
Repository verknüpfen oder mit einem Framework starten
Verknüpfen Sie TradingHost mit Ihrem bestehenden Strategie-Repository oder forken Sie eine TradingHost-Framework-Runtime (CCXT) für eine funktionierende Ausgangsbasis mit den REST- und WebSocket-APIs von WhiteBIT.
- SCHRITT 03
In einen TradingHost-Container deployen
Wählen Sie eine Region (EU oder US-East), hinterlegen Sie die von Ihrer Strategie benötigten Umgebungsvariablen (WhiteBIT-API-Schlüssel und -Secret, Einstellungen für den Guthabentransfer) und deployen Sie. TradingHost erstellt Ihren Container aus dem Repository und führt Ihre Strategie auf einer verwalteten Kubernetes-Infrastruktur aus. Keine lokale Docker-Installation erforderlich.
- SCHRITT 04
Logs und Status überwachen
Verfolgen Sie Live-Logs, Systemzustand und Runtime-Status direkt im TradingHost-Dashboard. Dieselbe Schnittstelle ist über MCP aus jeder beliebigen AI IDE erreichbar. So können Cursor, Claude Code oder ein CLI-Agent den Deployment-Status auslesen und die Runtime an Ihrer Seite verwalten.
- SCHRITT 05
Aktualisieren und neu deployen
Pushen Sie Änderungen in Ihren GitHub-Main-Branch und TradingHost deployt automatisch neu.
Sektion 05 · Betriebshinweise
Betriebshinweise für WhiteBIT
Stolpersteine, auf die Sie stoßen, wenn Sie eine WhiteBIT-Strategie in einer containerisierten Cloud-Runtime ausführen – Dinge, die weder in der Dokumentation von WhiteBIT noch in den READMEs der Frameworks stehen. Jede der folgenden Aussagen basiert auf der offiziellen Dokumentation von WhiteBIT; die Hinweise zur Bereitstellung stammen aus der Praxis beim Betrieb dieser Strategien auf TradingHost.
01 · Kein Testnet
WhiteBIT bietet kein öffentliches Testnet; Integrationstests erfolgen auf der Live-API
WhiteBIT stellt kein öffentliches Testnet bereit. Alle Integrationstests müssen gegen die Live-Produktions-API mit echten Assets und Mindestbestellgrößen durchgeführt werden. Dies ist ein erheblicher operativer Nachteil im Vergleich zu Binance, Coinbase oder Bybit, die alle Sandbox-Umgebungen für eine sichere Validierung vor dem Deployment anbieten. Der richtige Ansatz besteht darin, ein separates Konto mit geringem Guthaben oder ein Sub-Konto für erste Tests einzurichten, die kleinstmögliche Ordergröße zu nutzen und den Code vom ersten Tag an mit den üblichen Sicherheitsvorkehrungen (Idempotenz-Keys, Positionslimits, Kill-Switch) auszustatten – und nicht erst nach dem ersten Vorfall.
QuelleWhiteBIT API reference02 · Gestaffelte Rate-Limits
Rate-Limits pro Endpunkt: Main Balance 1k/10s, Trade Balance 12k/10s, Order-Erstellung 10k/10s, öffentlich 2k/10s
WhiteBIT wendet Ratenbegrenzungen pro Endpunkt anstelle eines einzigen globalen Budgets an. Endpunkte für Main Balance: 1.000 Anfragen pro 10 Sekunden. Endpunkte für Trade Balance: 12.000 pro 10 Sekunden. Endpunkt zur Ordererstellung: 10.000 pro 10 Sekunden. Endpunkte für öffentliche Marktdaten: 2.000 pro 10 Sekunden. Eine Strategie, die eine bestimmte Endpunkt-Familie stark beansprucht, schöpft das Budget einer anderen nicht aus, leert jedoch ihren eigenen Bucket sehr schnell. Bilden Sie das Budget der jeweiligen Endpunkt-Klasse in Ihrem Client-Wrapper ab, anstatt einen einzigen globalen Zähler zu tracken.
QuelleWhiteBIT API reference03 · WebSocket-Limits
1.000 gleichzeitige Verbindungen pro Minute; 200 Nachrichten pro Minute pro einzelner Verbindung
Der WebSocket-Layer von WhiteBIT begrenzt den Gesamtdurchsatz auf 1.000 gleichzeitige Verbindungsversuche pro Minute und 200 Nachrichten pro Minute pro einzelner offener Verbindung. Eine Strategie, die viele private Kanäle über eine einzige Verbindung abonniert, kann das Limit pro Verbindung erreichen, noch bevor das Orderbuch vollständig abonniert ist. Das richtige Pattern für Multi-Strategie-Deployments ist eine WebSocket-Verbindung pro Strategie mit eigenem Nachrichtenbudget, anstatt einer gemeinsamen Verbindung, die an viele Consumer geroutet wird. Der Token-Refresh auf privaten Kanälen liegt in der Verantwortung des Clients; geht der Token verloren, bricht das Abonnement geräuschlos ab.
QuelleWhiteBIT API reference04 · Transfer-Fehlercodes
Error 1 = disabled from-trade, 2 = disabled from-main, 3 = insufficient
WhiteBIT unterteilt Guthaben in Main Balance und Trade Balance. Strategien, die Orders gegen die Trade Balance platzieren, aber die Main Balance zur Deckung auslesen, müssen den Endpunkt für den Guthabentransfer aufrufen. Der Transfer-Endpunkt gibt drei spezifische Fehlercodes zurück, die man kennen sollte: Error 1 bedeutet, dass Transfers von Trade deaktiviert sind (meist durch eine Einstellung auf Account-Ebene), Error 2 bedeutet, dass Transfers von Main deaktiviert sind, und Error 3 bedeutet unzureichendes Guthaben (insufficient balance). Keiner dieser drei Fehler lässt sich durch einen erneuten Versuch (Retry) beheben; sie erfordern entweder eine Anpassung auf Account-Ebene oder eine andere Entscheidung der Strategielogik.
05 · Reine Plattform-Features
Copy-Trading, Auto-Invest und Staking bieten keinen API-Zugriff
WhiteBIT bietet Copy-Trading, Auto-Invest-Pläne und Staking an, aber alle drei sind reine Plattform-Features ohne API-Zugriff. Strategien, die WhiteBIT integrieren, können nicht programmatisch einem Copy-Trading-Leader folgen, einen Auto-Invest-Plan konfigurieren oder Guthaben staken. Das richtige Pattern besteht darin, diese als externe, manuelle Workflows zu behandeln, die manuell in der WhiteBIT-Benutzeroberfläche konfiguriert werden, während der Strategiecode das resultierende Guthaben und den Orderstatus über die API ausliest.
QuelleWhiteBIT API reference06 · Mindestordergrößen
Mindestgrößen pro Handelspaar gelten im Live-Betrieb; vor dem Testen abfragen
Da es kein Testnet gibt, sind die ersten Orders einer Strategie Echtgeld-Orders gegen echte Liquidität. Es gelten Mindestordergrößen pro Handelspaar, und das Ausführen einer Strategie, die Orders unterhalb dieses Minimums sendet, führt zur Ablehnung jeder Anfrage. Fragen Sie den Endpunkt für Mindestgrößen beim Start ab, cachen Sie die Werte pro Symbol und validieren Sie jede ausgehende Order vor dem Senden gegen das gecachte Minimum. Aktualisieren Sie den Cache regelmäßig, da WhiteBIT die Mindestgrößen an die Marktbedingungen anpasst.
QuelleWhiteBIT API reference
Sektion 06 · Entwickelt für
Entwickelt für
TradingHost-Runtimes für WhiteBIT eignen sich besonders für:
- Entwickler, die Strategien in KI-IDEs (Cursor, Claude Code) erstellen
- Systematische Krypto-Trader
- Quant-Entwickler
- CCXT-Nutzer
- Teams, die von VPS-Hosting auf containerisierte Deployments umstellen
Die Verknüpfung mit GitHub und das Erstellen Ihrer ersten Strategie sind kostenlos.
Sektion 08 · FAQ
FAQ
Nein. TradingHost ist unabhängig und steht in keiner Verbindung zu WhiteBIT.
Nein. Ihr Strategiecode verbindet sich mit WhiteBIT und sendet Anweisungen basierend auf Ihrer eigenen Logik, Ihren Kontoberechtigungen und Ihrer Integrationsmethode. TradingHost stellt die Runtime bereit, in der dieser Code ausgeführt wird.
Nein. Der Zugriff auf die WhiteBIT-API wird von WhiteBIT bereitgestellt. Sie sind selbst für Ihr WhiteBIT-Konto, Ihre API-Berechtigungen, Ihre Zugangsdaten und die Einhaltung der Nutzungsbedingungen von WhiteBIT verantwortlich.
Nein. TradingHost ist die Cloud-Runtime, auf der Ihr Strategiecode läuft. Wir bieten keine Signale, KI-Vorhersagemodelle oder fertigen Bots 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 Live-Umgebung auszuführen. Produkte wie 3Commas oder Cryptohopper besitzen die Strategielogik; TradingHost führt 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 Trading-Strategien entwickelt wurde: GitHub-natives Deployment, MCP-basierte Steuerung aus KI-IDEs sowie integrierte Log- und Health-Dashboards. Wenn Sie die Infrastruktur selbst betreiben 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. CCXT bietet eine einheitliche `whitebit`-Klasse, die den Spot-Handel abdeckt. Die Abdeckung von Futures und Margin in CCXT ist unvollständig. Packen Sie Ihre CCXT-Strategie in einen Container, verknüpfen Sie sie mit GitHub, und TradingHost führt sie wie jedes andere Python- oder Node-Projekt aus. Weitere Informationen zur Einrichtung finden Sie bei der CCXT-Framework-Runtime.
Ja. Perpetual Futures sind über die WhiteBIT-API erreichbar, sobald Ihr Konto dafür freigeschaltet ist. TradingHost ist auf Runtime-Ebene plattformunabhängig: Jeder Code, der sich gegenüber den Futures-Endpunkten authentifizieren kann, kann in einem Container ausgeführt werden. Bitte beachten Sie, dass Copy-Trading, Auto-Invest und Staking reine Plattform-Features ohne API-Zugriff sind; Strategien können nicht programmatisch einem Copy-Trading-Leader folgen oder einen Auto-Invest-Plan konfigurieren.
Ja, sofern Ihr Projekt so konzipiert ist. Sie können mehrere Strategieprozesse oder -dienste innerhalb einer Runtime ausführen oder sie zur besseren Isolierung und operativen Klarheit auf verschiedene Runtimes aufteilen. Speziell für WhiteBIT empfiehlt sich eine WebSocket-Verbindung pro Strategie, damit jede Strategie ihr eigenes Budget von 200 Nachrichten pro Minute pro Verbindung erhält, anstatt es sich zu teilen. Weitere Informationen zum Multi-Strategie-Modell finden Sie auf der TradingHost-Runtime-Seite.
Der schnellste Weg ist das Forken einer TradingHost-Framework-Runtime: CCXT für ein sofort einsatzbereites Projekt. Alternativ können Sie Ihr eigenes GitHub-Strategie-Repository anbinden. 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 keine Verwahrung Ihres API-Keys oder Secrets. Weitere Informationen zum Sicherheitsmodell finden Sie unter Platform Secrets.
Nein. Strategien sollten niemals Auszahlungsberechtigungen benötigen. Beschränken Sie Ihren API-Key ausschließlich auf das Trading und das Auslesen des Kontostatus, und deaktivieren Sie Auszahlungen für diesen Key vollständig.
Ja. TradingHost unterstützt die MCP-basierte Steuerung für KI-IDEs wie Cursor, Claude Code, GitHub Copilot und CLI-basierte KI-Agenten. KI-Tools können Deployments überprüfen, Logs einsehen, Strategien neu starten und Runtime-Workflows verwalten. MCP ist eine Steuerungs- und Observability-Schnittstelle, nicht der Pfad für die Trade-Ausführung. Weitere Informationen finden Sie unter MCP-Steuerungsschnittstelle.
Beides. Die MCP-Steuerungsschnittstelle funktioniert ebenso gut über CLI-basierte Agenten (Claude Code CLI, benutzerdefinierte MCP-Clients, geskriptete MCP-Aufrufe) wie 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 relevanten 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 bleibt weiterhin für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Weitere Informationen finden Sie unter Observability für Logs und Statusanzeigen.
WhiteBIT stellt kein öffentliches Testnet bereit. Alle Integrationstests müssen daher über die Live-Produktions-API mit echten Assets und minimalen Ordergrößen durchgeführt werden. Best Practice hierfür ist, ein separates Unterkonto mit geringem Guthaben für die ersten Deployments einzurichten, die kleinstmögliche Ordergröße zu wählen und den Code von Anfang an mit Standard-Schutzmechanismen (Idempotency-Keys, Positionslimits, Kill-Switch) abzusichern. Detaillierte Empfehlungen 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 Regions-Seite.
Nein. TradingHost ist rein auf die Live-Ausführung (Production Runtime) und das Deployment spezialisiert. Backtesting gehört in Ihren Research-Stack, Ihr Framework oder in Tools wie AlgoBuilder.