KI-native Runtime für CEX.IO-Trading-Strategien

Nein. Ihr Strategie-Code verbindet sich mit CEX.IO 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 Zugang zur CEX.IO-API wird von CEX.IO bereitgestellt. Sie sind selbst für Ihr CEX.IO-Konto, die API-Berechtigungen, Zugangsdaten und die Einhaltung der Nutzungsbedingungen von CEX.IO verantwortlich.

Nein. TradingHost ist die Cloud-Runtime, in der Ihr Strategie-Code läuft. Wir bieten keine Signale, KI-Vorhersagemodelle oder vorgefertigten 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 live auszuführen. Bei 3Commas, Cryptohopper und ähnlichen Produkten liegt die Strategielogik beim Anbieter; TradingHost führt 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 Uptime-Monitoring kümmern. TradingHost bietet Ihnen eine verwaltete Runtime, die speziell für Trading-Strategien entwickelt wurde: GitHub-natives Deployment, MCP-gestützte Steuerung aus KI-IDEs sowie direkt einsatzbereite Log- und Health-Oberflächen. 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 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 stellt den CEX.IO Retail Spot über die vereinheitlichte Klasse `cex` bereit. Die aggregierte Liquidität von CEX.IO Prime ist für institutionelle Kunden gedacht und kein nativer CCXT-Markt. Nutzen Sie für Prime die native Prime Liquidity API oder FIX 4.4. Details zur Einrichtung finden Sie in der Dokumentation zur CCXT-Framework-Runtime.

Ja. TradingHost ist auf Runtime-Ebene plattformunabhängig: Jeder Code, der sich gegenüber CEX.IO Prime authentifizieren kann, läuft in einem Container – einschließlich einer FIX 4.4-Session. Sie müssen jedoch berücksichtigen, dass FIX ein eigenes Session-Management (Logon, Heartbeat, Sequenznummer-Wiederherstellung) erfordert, das sich von REST/WebSocket unterscheidet. Nutzen Sie eine bewährte Bibliothek wie QuickFIX, überwachen Sie den Session-Status außerhalb der Strategielogik und behandeln Sie FIX-Session-Resets als behebbare Runtime-Ereignisse.

Ja, sofern Ihr Projekt so konzipiert ist. Sie können mehrere Strategieprozesse oder -dienste innerhalb einer Runtime ausführen oder sie für eine bessere Isolierung und operative Klarheit auf verschiedene Runtimes aufteilen. 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 Retail-Spot-Projekt. Oder verbinden Sie Ihr eigenes GitHub-Strategie-Repository, wenn Sie die native Prime Liquidity API oder FIX 4.4 nutzen. 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 zu keinem Zeitpunkt Zugriff auf Ihren Prime-API-Schlüssel, Ihr Secret oder Ihre FIX-Session-Konfiguration. Details zum Sicherheitsmodell finden Sie unter Platform Secrets.

Nein. Strategien sollten niemals die Berechtigung Funds External (Auszahlung) benötigen. CEX.IO unterteilt API-Schlüssel-Berechtigungen in fünf Bereiche: Read, Trade, Funds Internal, Funds Wallet und Funds External. Wenn Sie strategiespezifische Schlüssel verwenden, die nur die absolut notwendigen Berechtigungen besitzen, begrenzen Sie den potenziellen Schaden im Falle eines Datenlecks erheblich. Isolieren Sie auszahlungsberechtigte Schlüssel in separaten, manuell verwalteten Zugangsdaten außerhalb der Container-Runtime.

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 dient als Steuerungs- und Observability-Schnittstelle, nicht als Pfad für die Trade-Ausführung. Details dazu finden Sie unter MCP-Steuerungsoberfläche.

Beides. Die MCP-Steuerungsoberfläche funktioniert über CLI-basierte Agenten (Claude Code CLI, benutzerdefinierte MCP-Clients, skriptbasierte MCP-Aufrufe) genauso gut 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 selbst für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Details zu Logs und Status-Schnittstellen finden Sie unter Observability.

CEX.IO Prime signiert HMAC über action + timestamp + body (nicht nur den rohen Body) mit einem base64-dekodierten Secret. Strategien, die nur den Body hashen, mit dem Secret als UTF-8-String signieren (statt es aus base64 zu dekodieren) oder das action-Präfix weglassen, erhalten Signaturfehler-Antworten, die wie Fehler wegen eines falschen Keys aussehen. Führen Sie vor dem Deployment Unit-Tests für den Signierungspfad mit einer bekannten, funktionierenden Anfrage durch. Die vollständige Anleitung finden Sie oben im Abschnitt „Betriebliche Hinweise“.

TradingHost läuft in den Regionen EU und US-East. Für CEX.IO Prime ist die Region EU in der Regel die richtige Wahl, da der US-Datenverkehr auf den Prime-Tiers trotz der FCA MLR-Registrierung der Muttergesellschaft blockiert wird. Wählen Sie die Region, deren Egress-Geografie sowohl mit Ihrer Nutzungsvereinbarung als auch mit Ihren eigenen Compliance-Vorgaben übereinstimmt. Details zu Routing und Latenzen finden Sie auf der Regions-Seite.

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