Runtime natif IA pour stratégies de trading Uphold

Non. Le code de votre stratégie se connecte à Uphold et envoie des instructions de swap selon votre propre logique, les autorisations de votre compte et votre méthode d'intégration. TradingHost fournit le runtime dans lequel ce code s'exécute.

Non. L'accès à l'API d'Uphold est fourni par Uphold. Vous êtes responsable de votre compte Uphold, des autorisations d'API, de vos identifiants et du respect des conditions d'utilisation d'Uphold.

Non. TradingHost est le runtime cloud dans lequel s'exécute le code de votre stratégie. Nous ne fournissons pas de signaux, de modèles de prédiction IA ou de bots prêts à l'emploi. Avec TradingHost, vous écrivez ou générez vous-même la stratégie (souvent avec Cursor ou Claude Code), vous la conservez sur GitHub sous forme de code, et vous utilisez TradingHost pour l'exécuter en production. Des produits comme 3Commas ou Cryptohopper détiennent la logique de la stratégie ; TradingHost se charge d'exécuter la vôtre.

AWS et DigitalOcean vous fournissent de la puissance de calcul brute. Vous devez gérer vous-même les mises à jour de l'OS, l'orchestration des conteneurs, la centralisation des journaux (logs), la rotation des secrets, le basculement régional et la surveillance de la disponibilité. TradingHost vous offre un runtime managé conçu spécifiquement pour les stratégies de trading : déploiement natif via GitHub, contrôle piloté par MCP depuis vos IDE IA, ainsi que des interfaces de logs et de suivi d'état de santé prêtes à l'emploi. Si vous souhaitez gérer l'infrastructure vous-même, AWS convient parfaitement. Si vous préférez un runtime sous forme de service managé, TradingHost est la voie la plus rapide.

Oui. TradingHost exécute des stratégies en Python. Pour Uphold, le modèle classique consiste à utiliser un client Python personnalisé qui interagit avec les API REST natives d'Uphold, car il n'existe pas de connecteur natif de premier plan pour CCXT, Freqtrade ou Hummingbot.

Oui. TradingHost prend en charge n'importe quel langage capable de s'exécuter dans un conteneur.

CCXT ne liste pas Uphold comme une plateforme d'échange unifiée car Uphold repose sur un modèle de swap et non de carnet d'ordres, ce qui sort de l'abstraction principale de CCXT. Les stratégies nécessitant une abstraction de framework doivent s'interfacer directement avec les API modulaires natives d'Uphold. Consultez la page du runtime du framework CCXT pour comprendre comment l'intégration d'un framework s'adapte lorsqu'une plateforme n'est pas prise en charge nativement.

Sur une plateforme à carnet d'ordres, vous placez un ordre limit ou market contre la profondeur du carnet et payez des frais maker ou taker. Sur Uphold, vous demandez une cotation de swap à la plateforme ; cette cotation est calculée selon la profondeur du pool de liquidité et inclut le spread de la plateforme, puis vous l'acceptez ou la refusez. Il n'y a pas de frais maker distincts, pas de paramètre post-only, ni d'abonnement à la profondeur du carnet d'ordres. Les stratégies doivent anticiper le slippage par rapport à la profondeur du pool plutôt qu'à celle d'un carnet ; des volumes de swap plus importants sur des pools peu profonds subissent des prix proportionnellement moins avantageux. Un code de stratégie écrit pour une abstraction de carnet d'ordres ne peut pas être transposé sur Uphold sans réécriture. Consultez la section Notes opérationnelles ci-dessus pour obtenir tous les détails.

Oui, si votre projet est conçu ainsi. Vous pouvez exécuter plusieurs processus ou services de stratégie au sein d'un même runtime, ou les séparer dans différents runtimes pour des raisons d'isolation et de clarté opérationnelle. Consultez la page du runtime TradingHost pour découvrir le modèle multi-stratégie.

Contrairement à Binance, Uphold ne propose pas de kits de démarrage de framework. La voie la plus rapide consiste donc à connecter votre propre dépôt de stratégie GitHub ciblant les API modulaires natives d'Uphold (Core, Market Pulse, Topper) à l'aide d'un Personal Access Token. Lier un dépôt GitHub et créer une stratégie est gratuit ; les abonnements de runtime sont détaillés sur la page des tarifs.

Dans votre flux de gestion des secrets contrôlé par GitHub. TradingHost les lit au moment de l'exécution (runtime) via les secrets de dépôt GitHub, les secrets d'environnement ou votre propre processus approuvé de gestion des secrets. TradingHost n'a pas besoin de conserver votre Personal Access Token ou vos identifiants OAuth. Consultez la page sur les secrets de la plateforme pour connaître l'intégralité du modèle de gestion.

Un Personal Access Token octroie un accès porteur à votre compte unique Uphold. Les stratégies doivent être limitées aux accès en lecture et de swap uniquement. Si Uphold propose un jour un ciblage plus précis des autorisations pour les PAT dans le tableau de bord de votre compte, privilégiez la restriction la plus stricte. Veillez à désactiver l'autorisation de retrait sur tout jeton chargé par une stratégie.

Oui. TradingHost prend en charge le contrôle basé sur MCP pour les IDE IA, notamment Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande (CLI). Les outils d'IA peuvent inspecter les déploiements, consulter les logs, redémarrer les stratégies et gérer les flux de travail du runtime. MCP est une interface de contrôle et d'observabilité, et non le chemin d'exécution des transactions. Consultez la page sur l'interface de contrôle MCP pour en savoir plus.

Les deux. L'interface de contrôle MCP fonctionne tout aussi bien avec des agents en ligne de commande (CLI de Claude Code, clients MCP personnalisés, appels MCP scriptés) qu'au sein d'un IDE. De plus, la boucle de déploiement native de GitHub fonctionne sans aucun outil d'IA : un simple git push vers votre branche principale déclenche un redéploiement.

Le runtime détecte le plantage et expose les logs et les informations d'état pertinents. Si le framework le permet, la stratégie concernée peut être redémarrée sans perturber les autres stratégies exécutées dans le même conteneur. Le code de votre stratégie reste responsable de la gestion des erreurs, de la protection contre les ordres doublons et des contrôles de risque. Consultez la section sur l'observabilité pour accéder aux logs et aux indicateurs d'état.

Le modèle de swap d'Uphold ne propose pas de seuils de protection natifs contre le slippage comme le ferait une plateforme à carnet d'ordres. Les stratégies doivent implémenter les contrôles de slippage côté client : demander la cotation, la comparer à un flux de prix de référence, puis l'accepter ou la refuser selon la tolérance propre à la stratégie. Les swaps de taille importante sur des liquidity pools peu profonds subissent des prix disproportionnellement moins avantageux ; la sensibilité à la taille n'est donc pas linéaire. Consultez la section Notes opérationnelles ci-dessus pour obtenir des instructions complètes.

TradingHost s'exécute dans les régions EU et US-East. Choisissez la région la plus proche du moteur d'appariement dont dépend votre stratégie. Consultez la page des régions pour obtenir plus de détails sur le routage et la proximité.

Non. TradingHost se concentre exclusivement sur le runtime de production et le déploiement. Le backtesting relève de votre environnement de recherche, de votre framework ou d'AlgoBuilder.