AI-native Runtime für Uphold-Trading-Strategien

Nein. Ihr Strategie-Code verbindet sich mit Uphold und sendet Swap-Anweisungen gemäß 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 Uphold-API wird von Uphold bereitgestellt. Sie sind selbst für Ihr Uphold-Konto, Ihre API-Berechtigungen, Ihre Zugangsdaten und die Einhaltung der Nutzungsbedingungen von Uphold verantwortlich.

Nein. TradingHost ist die Cloud-Runtime, auf der Ihr Strategie-Code ausgeführt wird. Wir bieten keine Signale, KI-Vorhersagemodelle oder vorgefertigten Bots an. Mit TradingHost schreiben oder generieren Sie die Strategie selbst (häufig mit Cursor oder Claude Code), verwalten sie als Ihren eigenen Code in GitHub und nutzen TradingHost, um sie in der Live-Umgebung auszuführen. Während Produkte 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 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 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 möchten, ist TradingHost der direktere Weg.

Ja. TradingHost führt Python-Strategien aus. Das typische Muster für Uphold ist ein maßgeschneiderter Python-Client, der direkt mit den nativen REST-APIs von Uphold kommuniziert, da kein erstklassiger Connector für CCXT, Freqtrade oder Hummingbot existiert.

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

CCXT führt Uphold nicht als standardisierte Exchange auf, da Uphold auf einem Swap-Modell statt auf einem Orderbuch basiert, was außerhalb der primären Abstraktion von CCXT liegt. Strategien, die eine Framework-Abstraktion nutzen möchten, müssen direkt über die nativen modularen APIs von Uphold kommunizieren. Weitere Informationen dazu, wie sich die Framework-Integration verändert, wenn ein Handelsplatz nicht nativ unterstützt wird, finden Sie in der Dokumentation zur CCXT-Framework-Runtime.

Auf einem Orderbuch-Handelsplatz platzieren Sie eine Limit- oder Market-Order gegen die Orderbuchtiefe und zahlen maker- oder taker-Gebühren. Bei Uphold fordern Sie einen Swap-Quote vom Handelsplatz an. Dieser Quote basiert auf der Tiefe des Liquidity Pools und enthält den Spread des Handelsplatzes. Sie können diesen Quote dann annehmen oder ablehnen. Es gibt keine separate maker-Gebühr, kein post-only-Flag und kein Abonnement für die Orderbuchtiefe. Strategien müssen die Slippage im Verhältnis zur Pool-Tiefe statt zur Buchtiefe kalkulieren; größere Swap-Volumina in weniger liquiden Pools führen zu überproportional schlechteren Preisen. Strategie-Code, der für eine Orderbuch-Abstraktion geschrieben wurde, lässt sich nicht ohne Anpassungen auf Uphold portieren. Den vollständigen Kontext finden Sie oben im Abschnitt „Betriebliche Hinweise“.

Ja, sofern Ihr Projekt entsprechend konzipiert ist. Sie können mehrere Strategieprozesse oder -dienste innerhalb einer Runtime ausführen oder sie zur besseren Isolierung und betrieblichen Klarheit auf verschiedene Runtimes aufteilen. Weitere Informationen zum Multi-Strategie-Modell finden Sie auf der TradingHost-Runtime-Seite.

Uphold bietet keine Framework-Starter-Kits wie Binance an. Der schnellste Weg ist daher, Ihr eigenes GitHub-Strategie-Repository, das die nativen modularen APIs von Uphold (Core, Market Pulse, Topper) anspricht, über einen Personal Access Token zu verbinden. 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, Umgebungs-Secrets oder Ihren eigenen freigegebenen Secret-Management-Prozess aus. TradingHost benötigt zu keinem Zeitpunkt Zugriff auf Ihren Personal Access Token oder Ihre OAuth-Zugangsdaten. Das vollständige Sicherheitsmodell finden Sie unter Plattform-Secrets.

Ein Personal Access Token gewährt Bearer-Zugriff auf Ihr einzelnes Uphold-Konto. Der Berechtigungsumfang von Strategien sollte sich ausschließlich auf Swap- und Lesezugriffe beschränken. Falls Uphold in Ihrem Account-Dashboard eine feiner abgestufte Rechtevergabe für PATs anbietet, sollten Sie stets die restriktivste Option wählen. Deaktivieren Sie Auszahlungsberechtigungen (withdrawal) für alle Token, die von einer Strategie geladen werden.

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 dient als Steuerungs- und Observability-Schnittstelle, nicht als Pfad für die Trade-Ausführung. Das vollständige Konzept finden Sie unter MCP-Steuerungsschnittstelle.

Beides. Die MCP-Steuerungsschnittstelle funktioniert über CLI-basierte Agents (Claude Code CLI, benutzerdefinierte MCP-Clients, geskriptete MCP-Aufrufe) ebenso 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 relevanten Logs und Health-Informationen 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 die Health-Schnittstelle.

Das Swap-Modell von Uphold bietet keine nativen Schwellenwerte für den Slippage-Schutz, wie es bei einem Orderbuch-Handelsplatz der Fall wäre. Strategien müssen Slippage-Kontrollen clientseitig implementieren: den Quote anfordern, mit einer Price-Feed-Referenz vergleichen und basierend auf der eigenen Toleranz der Strategie annehmen oder ablehnen. Größere Swap-Volumina in dünneren Liquidity Pools führen zu unverhältnismäßig schlechteren Preisen, weshalb die Skalierung der Ordergröße nicht linear verläuft. Die vollständige Anleitung finden Sie oben im Abschnitt „Operational notes“.

TradingHost wird in den Regionen EU und US-East betrieben. 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 Regionen-Seite.

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