Runtime natif IA pour stratégies de trading CEX.IO

Non. Le code de votre stratégie se connecte à CEX.IO et envoie des instructions selon votre propre logique, les permissions 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 CEX.IO est fourni par CEX.IO. Vous êtes responsable de votre compte CEX.IO, des permissions d'API, de vos identifiants et du respect des conditions d'utilisation de CEX.IO.

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é-intégrés. 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 en tant que code personnel, 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 exécute votre stratégie.

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 transmission des logs, la rotation des secrets, le basculement de région 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 des IDE IA, ainsi que des interfaces de logs et de santé prêtes à l'emploi. Si vous souhaitez gérer l'infrastructure vous-même, AWS convient. Si vous préférez le runtime sous forme de service managé, TradingHost est la voie la plus directe.

Oui. TradingHost exécute des stratégies Python ; choisissez le runtime de framework qui correspond à votre stack ou déployez votre propre dépôt.

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

Oui. CCXT expose le marché spot retail de CEX.IO via la classe unifiée `cex`. La liquidité agrégée de CEX.IO Prime est institutionnelle et n'est pas un marché CCXT natif de premier ordre ; pour Prime, ciblez l'API native Prime Liquidity ou FIX 4.4. Consultez le runtime du framework CCXT pour obtenir les détails complets de la configuration.

Oui. TradingHost est indépendant de la plateforme au niveau du runtime : tout code capable de s'authentifier auprès de CEX.IO Prime peut s'exécuter dans un conteneur, y compris une session FIX 4.4. La contrainte que vous devez intégrer à votre conception est que FIX possède son propre contrat de gestion de session (logon, heartbeat, récupération des numéros de séquence) qui diffère de REST/WebSocket. Figez une bibliothèque éprouvée comme QuickFIX, supervisez l'état de la session en dehors de la logique de la stratégie, et traitez les réinitialisations de session FIX comme des événements d'exécution récupérables.

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.

La voie la plus rapide consiste à forker un runtime de framework TradingHost : CCXT pour un projet spot retail prêt à être déployé. Ou connectez votre propre dépôt de stratégie GitHub si vous ciblez l'API native Prime Liquidity ou FIX 4.4. Associer 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 workflow de secrets contrôlé par GitHub. TradingHost les lit au moment de l'exécution via les secrets de dépôt GitHub, les secrets d'environnement ou votre propre processus de gestion des secrets approuvé. TradingHost n'a pas besoin de conserver votre clé API Prime, votre secret ou votre configuration de session FIX. Consultez les secrets de la plateforme pour connaître le modèle de gestion complet.

Non. Les stratégies ne devraient jamais avoir besoin de la permission Funds External (retrait). CEX.IO divise les permissions des clés API en cinq portées : Read, Trade, Funds Internal, Funds Wallet et Funds External. Des clés spécifiques à chaque stratégie, dotées uniquement des portées nécessaires, limitent la zone d'impact en cas de fuite de clé ; isolez les clés permettant les retraits dans un identifiant distinct géré manuellement en dehors du runtime du conteneur.

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 IA peuvent inspecter les déploiements, consulter les logs, redémarrer les stratégies et gérer les workflows d'exécution. MCP est une interface de contrôle et d'observabilité, et non le chemin d'exécution des transactions. Consultez l'interface de contrôle MCP pour une vue d'ensemble.

Les deux. L'interface de contrôle MCP fonctionne tout aussi bien depuis des agents en ligne de commande (CLI de Claude Code, clients MCP personnalisés, appels MCP scriptés) que depuis un IDE. Le cycle de déploiement natif GitHub fonctionne également sans aucun outil IA : un simple git push vers votre branche principale déclenche un redéploiement.

Le runtime détecte le plantage et expose les logs ainsi que les informations d'état pertinents. Lorsque cela est possible, 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 sécurisée des erreurs, de la protection contre les ordres doublons et des contrôles de risque. Consultez la section sur l'observabilité pour en savoir plus sur les logs et l'interface d'état.

CEX.IO Prime signe l'HMAC sur l'ensemble action + timestamp + corps (body), et non sur le seul corps brut, à l'aide d'un secret décodé en base64. Les stratégies qui hachent uniquement le corps, signent avec le secret sous forme de chaîne UTF-8 au lieu de le décoder depuis base64, ou omettent le préfixe de l'action, reçoivent des réponses d'erreur de signature qui ressemblent à des erreurs de clé incorrecte. Testez unitairement le processus de signature avec une requête valide connue avant le déploiement. Consultez la section Notes opérationnelles ci-dessus pour obtenir les instructions complètes.

TradingHost est disponible dans les régions EU et US-East. Pour CEX.IO Prime, la région EU est généralement le bon choix car le trafic en provenance des États-Unis est bloqué sur les niveaux Prime, malgré l'enregistrement FCA MLR de l'entité mère. Choisissez la région dont la géographie de sortie est conforme à la fois à votre contrat d'utilisation et à votre propre posture de conformité. Consultez la page des régions pour obtenir des détails sur le routage et la proximité.

Non. TradingHost se concentre exclusivement sur l'environnement d'exécution en production et le déploiement. Le backtesting doit être effectué au sein de votre infrastructure de recherche, de votre framework ou d'AlgoBuilder.