Runtime natif IA pour stratégies de trading MEXC
Développez dans Cursor, Claude Code ou n'importe quel IDE IA. Déployez depuis GitHub sur un runtime cloud managé avec contrôle MCP natif, logs et choix de région.
Section 01 · En un coup d’œil
En un coup d’œil
- Plateforme
- MEXC
- Type de plateforme
- Plateforme d'échange crypto
- Classe d’actifs
- Crypto (spot, contrats perpétuels USDT-M et coin-M)
- Produits pris en charge
- Spot, contrats à terme perpétuels USDT-M, contrats à terme perpétuels coin-M. Les contrats à terme sont interdits aux utilisateurs situés aux États-Unis, au Royaume-Uni et dans diverses juridictions restreintes.
- Modèle d’exécution
- Runtime de stratégie conteneurisé
- Source de déploiement
- GitHub
- Langages
- Tout langage s'exécutant dans un conteneur
- Intégrations courantes
- API natives MEXC Spot v3 et Contract v1 (REST et WebSocket), CCXT, connecteurs personnalisés
- Intégration du workflow d’IA
- Interface de contrôle MCP pour Cursor, Claude Code, GitHub Copilot et agents CLI
- Rôle de TradingHost
- Runtime, déploiement, logs, bilans de santé, choix de région, contrôle MCP
- Rôle de MEXC
- Compte d'échange, accès API, accès au marché, lieu d'exécution
- Affiliation
- TradingHost est indépendant et n'est pas affilié à MEXC.
Section 02 · Ce que propose MEXC
Ce que propose MEXC
MEXC propose le trading au comptant (spot) sur plus de 2 000 paires via l'API Spot v3, ainsi que des contrats à terme perpétuels USDT-M et coin-M via l'API Contract v1 sur un domaine de documentation distinct. Les contrats à terme sont interdits aux États-Unis, au Royaume-Uni et dans plusieurs autres juridictions restreintes. Les stratégies s'authentifient par HMAC-SHA256 sur l'interface Spot v3 avec des signatures hexadécimales en minuscules. Les spécificités des endpoints évoluent avec le temps. La structure globale reste stable ; les poids précis des limites de taux, les paliers de frais et les listes de symboles figurent dans la documentation de MEXC.
Marchés et types de stratégies
- Stratégies spot sur plus de 2 000 paires de trading
- Stratégies sur contrats à terme perpétuels USDT-M (hors juridictions restreintes)
- Stratégies sur contrats perpétuels Coin-M
- Trading de base et taux de financement (funding rate) sur contrats perpétuels
- Market making spot sur altcoins de second rang (long-tail)
- Déploiements multi-stratégies isolés par sous-comptes
- Flux d'ordres et de soldes via canaux privés WebSocket
- Capture programmatique des nouveaux listings
Interface API
- Produits couverts
- Spot v3 couvre le trading spot et la gestion de compte. Contract v1 couvre les contrats à terme perpétuels USDT-M et coin-M sur un domaine de documentation distinct. Les contrats à terme ne sont pas disponibles pour les utilisateurs des juridictions restreintes, notamment les États-Unis et le Royaume-Uni ; le géorepérage s'applique lors de la soumission des ordres, et pas seulement à la création du compte.
- Méthodes de connexion
- REST pour le placement d'ordres et les requêtes de compte. Flux WebSocket pour les données de marché en temps réel, la profondeur du carnet et les transactions. Flux de données utilisateur WebSocket pour les événements de compte, de solde et d'ordres. Les endpoints WebSocket spot et contrats sont distincts.
- Authentification
- Clé API et secret par stratégie. Les requêtes privées sont signées par HMAC-SHA256 sur une chaîne de paramètres triés avec un résultat hexadécimal en minuscules. La valeur par défaut de recvWindow est de 5000 ms et est plafonnée à 60000 ms. Les autorisations sont définies par clé (lecture, trading, retrait). Les stratégies ne devraient jamais avoir besoin de l'autorisation de retrait. Le filtrage par IP est disponible ; les clés sans liste blanche d'IP expirent automatiquement après 90 jours.
Pour plus de détails, reportez-vous à MEXC
Les endpoints spécifiques, les poids des limites de taux, les listes de symboles, les paliers de frais et l'historique des versions figurent dans la documentation de MEXC. Considérez-les comme la source de vérité.
Section 03 · Développer avec l’IA
Développez votre stratégie MEXC avec l’IA
Choisissez une méthode d’intégration, dupliquez (fork) un starter de framework TradingHost et concevez votre stratégie dans un AI IDE. Cursor, Claude Code, GitHub Copilot et les agents IA en ligne de commande fonctionnent tous avec le même cycle de déploiement natif sur GitHub.
API native MEXC
Contrôle direct du comportement spécifique à MEXC, accès à l'API de contrat et logique d'exécution des ordres.
Hummingbot
Déploiements basés sur un framework utilisant la structure de stratégie et le modèle de configuration de Hummingbot.
Connecteur personnalisé
Votre propre moteur de trading interne ou intégration propriétaire MEXC.
Compatibilité des frameworks avec les produits MEXC
La couverture varie selon le framework. CCXT prend en charge le spot et les contrats de MEXC ; Hummingbot propose un connecteur uniquement pour le spot ; Freqtrade ne liste pas MEXC parmi les plateformes d'échange prises en charge. L'accès à l'API native MEXC permet d'accéder à tout ce que propose MEXC, y compris l'API de contrat sur son domaine distinct.
✓ compatibilité confirmée selon la documentation officielle du framework. « no » indique que la compatibilité n’est pas officiellement documentée.
TradingHost n’impose aucun framework. Il exécute votre projet.
Développer avec l’IA
Les starters de framework ci-dessus s’associent naturellement avec les AI IDE. L’interface de contrôle MCP de TradingHost ferme la boucle : les outils d’IA peuvent inspecter les déploiements, consulter les journaux et gérer l’environnement d’exécution à vos côtés, sans jamais interférer avec le flux d’exécution des ordres.
Section 04 · Exécuter sur TradingHost
Exécutez votre code sur TradingHost
MEXC fournit la plateforme d’échange et l’accès API. TradingHost fournit l’environnement de production où s’exécute votre stratégie connectée à MEXC.
Au lieu d’exécuter le code de votre stratégie sur un ordinateur portable, un ordinateur de bureau, un VPS générique ou un serveur configuré manuellement, vous le déployez depuis GitHub dans un environnement d’exécution de conteneurs géré par TradingHost.
Vous
- Votre dépôt contient votre code.
- Votre déploiement définit son mode d’exécution.
- Votre stratégie se connecte à MEXC.
TradingHost
- Maintient l’environnement d’exécution en ligne.
- Affiche les logs et les contrôles d’état.
- Sélection de la région.
- Surface de déploiement contrôlée.
Flux de déploiement
- ÉTAPE 01
Connecter GitHub
Autorisez TradingHost à accéder à votre compte GitHub.
- ÉTAPE 02
Associez un dépôt ou démarrez depuis un framework
Pointez TradingHost vers votre dépôt de stratégie existant, ou dupliquez (fork) un runtime de framework TradingHost (CCXT ou Hummingbot) pour obtenir une base de travail fonctionnelle.
- ÉTAPE 03
Déployer dans un conteneur TradingHost
Choisissez une région (EU ou US-East), renseignez les variables d’environnement requises par votre stratégie (clés API MEXC, etc.) et déployez. TradingHost construit votre conteneur à partir du dépôt et exécute votre stratégie sur une infrastructure Kubernetes gérée. Aucune installation locale de Docker n’est requise.
- ÉTAPE 04
Suivre les logs et l’état de santé
Suivez en direct les logs, l’état de santé et l’état d’exécution depuis le tableau de bord TradingHost. Cette même interface est accessible via MCP depuis n’importe quel AI IDE, permettant à Cursor, Claude Code ou un agent en ligne de commande de lire l’état du déploiement et de gérer le runtime à vos côtés.
- ÉTAPE 05
Mettre à jour et redéployer
Poussez vos modifications sur votre branche principale GitHub et TradingHost relance automatiquement le déploiement.
Section 05 · Notes opérationnelles
Notes opérationnelles pour MEXC
Les pièges qui vous guettent lorsque vous exécutez réellement une stratégie MEXC dans un runtime cloud conteneurisé, absents de la documentation de MEXC ou des fichiers README des frameworks. Chaque affirmation ci-dessous est citée ou paraphrasée de la propre documentation de MEXC ; les conseils côté déploiement sont issus de l'exécution de ces stratégies sur TradingHost.
01 · Marchés restreints
Les utilisateurs des États-Unis et du Royaume-Uni sont interdits de trading de contrats à terme et de diverses paires spot
MEXC applique des restrictions de juridiction lors de la soumission des ordres, et pas seulement à la création du compte. Un runtime basé aux États-Unis qui interroge les endpoints de contrat renverra des erreurs d'accès refusé, quel que soit le statut de vérification du compte. Si votre stratégie cible les contrats à terme MEXC, déployez-la depuis une région TradingHost dont la géographie de sortie est conforme à vos conditions d'utilisation et à vos propres exigences de conformité ; les conteneurs situés dans des régions restreintes seront rejetés à la frontière de la plateforme.
SourceMEXC Spot v3 API docs02 · Doubles limites de taux
Les limites de taux par IP et par UID fonctionnent indépendamment
MEXC applique deux plafonds de limite de taux distincts pour chaque requête signée : une limite basée sur l'IP et une limite basée sur l'UID. Les endpoints spot sont généralement plafonnés à 500 requêtes par 10 secondes et par endpoint ; les connexions WebSocket sont plafonnées à 100 messages par seconde avec un maximum de 30 abonnements par connexion. Le dépassement de l'un ou l'autre de ces plafonds renvoie des erreurs 429. Les stratégies qui partagent une IP de sortie entre plusieurs sous-comptes peuvent atteindre le plafond d'IP bien avant qu'un seul UID ne soit proche de son quota ; dimensionnez votre modèle de concurrence par rapport à la plus basse des deux limites.
SourceMEXC Spot v3 API docs03 · Limite d'ordres groupés
Réduction de mars 2025 : l'endpoint d'ordres groupés spot limité à 5 ordres par seconde
MEXC a publié un ajustement des limites de requêtes le 25 mars 2025, réduisant le quota de l'endpoint d'ordres groupés spot à 5 ordres par seconde, contre un plafond auparavant plus élevé. Les intégrations de tenue de marché (market-making) existantes, dimensionnées selon l'ancien plafond, dépassent désormais ce nouveau seuil et reçoivent des erreurs 429. Adaptez le rythme de soumission de vos ordres à cette nouvelle limite et suivez régulièrement les annonces de MEXC au lieu de les considérer comme une information ponctuelle.
04 · Cycle de vie des clés
Clés API : 30 max par compte, expiration automatique après 90 jours sans whitelist IP
MEXC autorise jusqu'à 30 clés API par compte. Les clés créées sans whitelist IP expirent automatiquement après 90 jours ; celles avec whitelist n'expirent pas. Par défaut, les runtimes cloud ne disposent pas d'une IP de sortie unique et stable. Sur TradingHost, la bonne pratique consiste à utiliser la plage d'IP de sortie publiée pour la région choisie comme cible de whitelist, ou à accepter la rotation tous les 90 jours en automatisant le renouvellement des clés dans votre gestionnaire de secrets. Les comptes principaux sont également limités à 30 sous-comptes.
SourceMEXC Spot v3 API docs05 · Format de signature
Signatures HMAC en hexadécimal minuscule ; recvWindow par défaut à 5000 ms, max 60000 ms
MEXC accepte uniquement les signatures HMAC-SHA256 au format hexadécimal en minuscules. Les SDK qui génèrent de l'hexadécimal en majuscules ou du base64 provoquent des rejets pour signature invalide, qui ressemblent à des erreurs de clé secrète incorrecte. Le paramètre recvWindow est fixé par défaut à 5000 ms et plafonné à 60000 ms ; tout conteneur dont la dérive d'horloge dépasse recvWindow est rejeté. Les runtimes TradingHost étant synchronisés via NTP, la valeur par défaut de 5000 convient parfaitement. N'augmentez pas recvWindow sauf en cas de rejets avérés, et jamais pour compenser un défaut de synchronisation horaire.
SourceMEXC Spot v3 API docs06 · Séparation des domaines de contrats
L'API Contract réside sur un domaine de documentation distinct avec son propre pool de limites
MEXC publie l'API Contract v1 sur mexcdevelop.github.io/apidocs/contract_v1_en/, un domaine de documentation différent de celui de spot v3. Les endpoints de contrats dépendent d'un pool de limites de requêtes distinct : l'épuisement du quota spot ne restreint pas les requêtes de contrats, et inversement. Une stratégie utilisant les deux doit être conçue pour gérer deux enveloppes de limites indépendantes, et non un seul budget partagé.
Section 06 · Conçu pour
Conçu pour
Les runtimes TradingHost pour MEXC sont particulièrement adaptés aux :
- Développeurs concevant des stratégies dans des IDE IA (Cursor, Claude Code)
- Traders crypto systématiques
- Développeurs quantitatifs
- Utilisateurs de CCXT et Hummingbot
- Équipes migrant d'un hébergement VPS vers un déploiement conteneurisé
La connexion à GitHub et la création de votre première stratégie sont gratuites.
Section 08 · FAQ
FAQ
Non. TradingHost est indépendant et n'est pas affilié à MEXC.
Non. Le code de votre stratégie se connecte à MEXC et envoie des instructions selon votre propre logique, vos autorisations de compte et votre méthode d'intégration. TradingHost fournit uniquement l'environnement d'exécution (runtime) où tourne ce code.
Non. L'accès à l'API est fourni par MEXC. Vous êtes responsable de votre compte MEXC, des autorisations de l'API, de vos identifiants et du respect des conditions d'utilisation de MEXC.
Non. TradingHost est l'environnement d'exécution cloud (runtime) où tourne 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 votre 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 possèdent la logique de la stratégie ; TradingHost exécute 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 transmission des journaux (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 vos IDE IA, ainsi que des interfaces de logs et de santé prêtes à l'emploi. Si vous préférez gérer l'infrastructure vous-même, AWS convient. Si vous souhaitez un runtime sous forme de service managé, TradingHost est la voie la plus rapide.
Oui. TradingHost exécute des stratégies en Python ; choisissez le runtime de framework correspondant à 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 à la fois les interfaces spot et contract de MEXC via la classe unifiée `mexc`. Consultez le runtime du framework CCXT pour connaître toute la procédure de configuration.
Non. MEXC interdit le trading de futures aux utilisateurs situés aux États-Unis, au Royaume-Uni et dans plusieurs autres juridictions restreintes. Cette restriction est appliquée lors de la soumission des ordres, et pas seulement à la création du compte. Ainsi, un conteneur avec une IP de sortie américaine recevra des erreurs d'accès refusé de la part des endpoints de contrats, quel que soit le statut de vérification du compte. L'éligibilité est déterminée par MEXC, et non par TradingHost. Choisissez une région TradingHost dont la géographie de sortie est conforme à vos conditions d'utilisation et à vos exigences de conformité.
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 plus d'isolation et de clarté opérationnelle. Consultez la page des runtimes TradingHost pour découvrir le modèle multi-stratégie.
La voie la plus rapide consiste à forker un runtime de framework TradingHost : CCXT ou Hummingbot pour un projet prêt à être déployé. Vous pouvez également connecter votre propre dépôt de stratégie GitHub. 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 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 détenir vos clés API et secrètes. Consultez la section sur les secrets de la plateforme pour en savoir plus sur le modèle de gestion.
Non. Les stratégies ne devraient jamais avoir besoin d'autorisations de retrait. Utilisez des autorisations restreintes (lecture, trading) et le whitelisting d'IP lorsque c'est possible.
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é, pas le chemin d'exécution des transactions. Consultez l'interface de contrôle MCP pour une présentation complète.
Les deux. L'interface de contrôle MCP fonctionne 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 via GitHub fonctionne également sans aucun outil d'IA : un simple git push vers votre branche principale déclenche un redéploiement.
Le runtime d'exécution détecte le plantage et expose les logs et informations de santé correspondants. Lorsque cela est pris en charge, 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 risques. Consultez la section observabilité pour en savoir plus sur l'interface de logs et de santé.
MEXC applique deux plafonds de limites de requêtes indépendants : une limite par IP et une limite par UID. Les endpoints spot sont généralement plafonnés à 500 requêtes par 10 secondes ; l'endpoint d'ordres groupés (batch order) a été réduit à 5 ordres par seconde en mars 2025. Les connexions WebSocket sont limitées à 100 messages par seconde avec un maximum de 30 abonnements par connexion. Calibrez votre concurrence sur la plus basse des limites (IP ou UID) et adaptez la cadence de soumission de vos ordres à la limite actuelle de requêtes groupées. Consultez la section Notes opérationnelles ci-dessus pour obtenir toutes les recommandations.
TradingHost fonctionne 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 les détails de routage et de proximité.
Non. TradingHost se concentre exclusivement sur l'environnement d'exécution (runtime) de production et le déploiement. Le backtesting relève de votre environnement de recherche, de votre framework ou d'AlgoBuilder.