Runtime natif IA pour stratégies de trading Ripio
Développez dans Cursor, Claude Code ou n'importe quel IDE IA. Déployez depuis GitHub sur un runtime cloud géré avec contrôle MCP natif, logs et choix de région.
Section 01 · En un coup d’œil
En un coup d’œil
- Plateforme
- Ripio
- Type de plateforme
- Exchange crypto (Amérique latine, 8 juridictions)
- Classe d’actifs
- Crypto avec cotation multi-fiat LATAM (BRL, ARS, MXN, EUR, USD)
- Produits pris en charge
- Trading au comptant (spot) sur paires filtrées par pays (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR, etc.), stablecoins locaux (wARS, wBRL, wMXN), Ripio Trade API v4
- Modèle d’exécution
- Runtime de stratégie conteneurisé
- Source de déploiement
- GitHub
- Langages
- Tout langage compatible avec un conteneur
- Intégrations courantes
- API v4 native Ripio Trade REST et WebSocket, CCXT, connecteurs personnalisés
- Intégration du workflow d’IA
- Surface de contrôle MCP pour Cursor, Claude Code, GitHub Copilot et agents CLI
- Rôle de TradingHost
- Runtime, déploiement, logs, suivis de santé, choix de région, contrôle MCP
- Rôle de Ripio
- Compte d'exchange, accès API, accès au marché, lieu d'exécution
- Affiliation
- TradingHost est indépendant et n'est pas affilié à Ripio
Section 02 · Ce que propose Ripio
Ce que propose Ripio
Ripio propose du trading spot dans 8 juridictions d'Amérique latine avec des paires cotées en multi-fiat (BRL, ARS, MXN, EUR, USD) et des stablecoins locaux (wARS, wBRL, wMXN). Les stratégies s'authentifient via l'API v4 de Ripio Trade et sont soumises à des limites de requêtes (rate limits) échelonnées selon le statut KYC. La disponibilité des paires filtrées par pays via le paramètre de requête `countries` permet de déployer une même stratégie sur différents ensembles de produits régionaux. Les spécificités des endpoints évoluent avec le temps. La structure globale reste stable ; les limites de requêtes précises, les listes de paires et les tailles minimales sont détaillées dans la documentation de Ripio.
Marchés et types de stratégies
- Stratégies spot avec cotation en BRL (BTC_BRL, ETH_BRL, USDC_BRL)
- Stratégies spot avec cotation en ARS sur les paires en peso argentin
- Stratégies spot avec cotation en MXN sur les paires en peso mexicain
- Trading de stablecoins locaux (wARS, wBRL, wMXN)
- Stratégies d'arbitrage cross-fiat en Amérique latine
- Découverte de paires filtrées par pays via le paramètre de requête `countries`
- Abonnements WebSocket authentifiés par ticket pour les flux sensibles
- Planification de la consommation des limites de requêtes selon le niveau KYC par compte
Interface API
- Produits couverts
- Trading spot sur des paires filtrées par pays en Argentine, au Brésil, au Mexique, en Espagne, en Uruguay, en Colombie, au Chili et aux États-Unis. Les codes de paires utilisent la notation avec underscore (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN). Les stablecoins locaux (wARS, wBRL, wMXN) permettent des opérations directes en monnaie numérique. Le montant minimum, la valeur minimale et le pas de cotation (price tick) doivent être consultés pour chaque paire.
- Méthodes de connexion
- REST pour le placement d'ordres, les requêtes de compte et la découverte de paires. Flux WebSocket pour les données de marché en temps réel. L'accès aux flux WebSocket sensibles nécessite un ticket obtenu via POST `/v4/ticket` avant l'abonnement, et pas seulement une clé API.
- Authentification
- Limites de requêtes API échelonnées selon le statut KYC. Comptes non vérifiés : 1 requête par seconde (~86 400 par jour). Comptes vérifiés : 3,5 requêtes par seconde (~302 400 par jour). Tout dépassement de la limite renvoie une erreur HTTP 429 avec l'en-tête standard retry-after.
Pour plus de détails, reportez-vous à Ripio
Les endpoints spécifiques, les poids des limites de requêtes, les listes de paires, les paliers de frais et l'historique des versions sont disponibles dans la documentation de Ripio. Considérez-les comme la source de vérité unique.
Section 03 · Développer avec l’IA
Développez votre stratégie Ripio 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 Ripio
Contrôle direct sur les comportements spécifiques à Ripio, y compris la découverte de paires filtrées par pays et le routage des ordres fiat LATAM.
CCXT
Interface commune entre Ripio et d'autres exchanges crypto. CCXT expose Ripio Trade via la classe unifiée `ripio` pour le trading spot.
Freqtrade ou Hummingbot
Aucun de ces frameworks ne liste Ripio parmi les exchanges officiellement pris en charge aujourd'hui. La meilleure option consiste à utiliser une implémentation personnalisée ou basée sur CCXT.
Connecteur personnalisé
Votre propre moteur de trading interne ou une intégration propriétaire de l'API v4 de Ripio Trade sur les interfaces REST et WebSocket.
Compatibilité des frameworks avec les produits Ripio
La couverture varie selon le framework. Ripio propose uniquement du spot au niveau de l'exchange (pas de contrats perpétuels ni d'options natifs sur Trade), la matrice est donc volontairement restreinte. CCXT expose le spot Ripio Trade via sa classe unifiée `ripio`. Ni Freqtrade ni Hummingbot ne listent Ripio comme un exchange officiellement pris en charge aujourd'hui ; l'accès natif à l'API permet d'accéder à tout ce que publie Ripio Trade v4.
✓ support confirmé selon la documentation officielle du framework. « no » indique qu'il n'est pas officiellement documenté comme supporté. Les liens de workflow renvoient vers les pages /workflows/ actuellement en cours de rédaction.
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
Ripio 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 à Ripio.
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 à Ripio.
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) pour obtenir une base de travail fonctionnelle avec l'API v4 de Ripio Trade.
- É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é API Ripio Trade, code pays, paramètres de ticket WebSocket) et déployez. TradingHost construit votre conteneur à partir du dépôt et exécute votre stratégie sur une infrastructure Kubernetes managé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 Ripio
Les pièges réels rencontrés lors de l'exécution d'une stratégie Ripio dans un runtime cloud conteneurisé, absents des documentations de Ripio ou des fichiers README des frameworks. Chaque point ci-dessous est cité ou paraphrasé à partir de la documentation officielle de Ripio ; les conseils de déploiement sont issus de l'exploitation de ces stratégies sur TradingHost.
01 · Limites de requêtes selon le niveau KYC
Les comptes non vérifiés ont droit à 1 req/s ; les comptes vérifiés à 3,5 req/s
Les limites de requêtes de l'API v4 de Ripio Trade dépendent du niveau KYC plutôt que de la famille d'endpoints. Les comptes non vérifiés sont limités à 1 requête par seconde (environ 86 400 par jour). Les comptes vérifiés passent à 3,5 requêtes par seconde (environ 302 400 par jour). Tout dépassement renvoie une erreur HTTP 429. Une stratégie lancée en mode non vérifié puis promue au statut vérifié en cours de route peut quadrupler sa cadence d'interrogation en toute sécurité ; à l'inverse, une stratégie conçue pour un compte vérifié mais exécutée sur un compte non vérifié subira des erreurs 429 dès le premier jour. Intégrez le niveau KYC dans la configuration d'exécution pour rendre le budget de requêtes explicite.
02 · Paires filtrées par pays
Le paramètre de requête `countries` est la source de vérité pour les paires négociables
Ripio couvre 8 juridictions (AR, BR, MX, ES, UY, CO, CL, US) avec des niveaux de conformité par pays, et la disponibilité des paires est filtrée via le paramètre de requête `countries` plutôt que par une liste globale de symboles. Une paire disponible au Brésil peut ne pas l'être en Argentine, et inversement. Les stratégies qui codent en dur une liste de symboles basée sur l'offre brésilienne échoueront silencieusement (no-op) si elles sont exécutées pour un compte argentin. Récupérez les paires au démarrage via le point de terminaison filtré par pays au lieu de les figer dans le code.
03 · Codes de paires avec underscore
BTC_BRL et ETH_BRL, pas BTCBRL
Les codes de paires Ripio utilisent le tiret du bas (underscore) : BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR. Cette convention diffère de Binance et de la plupart des plateformes mondiales où les paires sont concaténées (BTCBRL). CCXT normalise le symbole en BTC/BRL dans son interface unifiée, mais tout appel direct à l'API native doit utiliser le format avec underscore. Le code d'une stratégie migré depuis une autre plateforme échoue souvent silencieusement avec une erreur de type paire introuvable tant que ce format n'est pas corrigé.
04 · Minimums par paire
`min_amount`, `min_value` et `price_tick` sont spécifiques à chaque paire et doivent être interrogés
Les minimums de paires et les pas de cotation (price ticks) sont spécifiques aux paires fiat. Les paires en BRL, ARS et MXN ont chacune leurs propres valeurs de `min_amount`, `min_value` et `price_tick` qui doivent être interrogées par paire avant de passer un ordre. Une stratégie qui utilise un seul minimum codé en dur pour les paires en BRL et ARS risque de sous-dimensionner ou sur-dimensionner silencieusement les transactions selon le pays actif. Mettez en cache ces champs par paire au démarrage et re-validez-les avant chaque ordre au lieu de supposer un minimum global.
05 · Authentification par ticket WebSocket
Les flux WebSocket sensibles nécessitent un ticket obtenu via POST `/v4/ticket`
Les flux WebSocket publics (données de marché, carnet d'ordres) sont ouverts. Les flux sensibles (état du compte, événements d'ordres) nécessitent un ticket obtenu via POST `/v4/ticket` avant de s'abonner, et pas seulement une clé API. Le ticket a une durée de vie (TTL) courte et doit être renouvelé périodiquement pour les stratégies à long terme. Les conteneurs qui perdent la connexion WebSocket et se reconnectent doivent demander un nouveau ticket à chaque fois ; la réutilisation d'un ticket expiré fait échouer silencieusement l'abonnement, et les callbacks d'état d'ordre cessent de se déclencher.
06 · Stablecoins locaux
wARS, wBRL et wMXN permettent des opérations directes en monnaie numérique
Ripio émet les stablecoins locaux wARS, wBRL et wMXN qui permettent des opérations directes en monnaie numérique sur les marchés BRL, ARS et MXN. Ceux-ci diffèrent de l'USDT/USDC et peuvent présenter des caractéristiques de liquidité, de règlement et de frais différentes. Les hypothèses de stratégies conçues autour de l'USDT ne s'appliquent pas automatiquement au wARS ou au wBRL. Validez la profondeur et le spread sur les paires de stablecoins locaux séparément avant de dimensionner votre exposition réelle.
Section 06 · Conçu pour
Conçu pour
Les runtimes TradingHost pour Ripio 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 (quants)
- Utilisateurs de CCXT
- É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é à Ripio.
Non. Le code de votre stratégie se connecte à Ripio et envoie des instructions selon votre propre logique, les autorisations de votre compte et votre méthode d'intégration. TradingHost fournit l'environnement d'exécution (runtime) dans lequel ce code s'exécute.
Non. L'accès à l'API de Ripio est fourni par Ripio. Vous êtes responsable de votre compte Ripio, des autorisations de votre API, de vos identifiants et du respect des conditions d'utilisation de Ripio.
Non. TradingHost est l'environnement d'exécution cloud (runtime) où 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éconfiguré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, 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 de région et la surveillance de la disponibilité. TradingHost vous offre un environnement d'exécution géré, 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 souhaitez gérer l'infrastructure vous-même, AWS convient. Si vous préférez un environnement d'exécution sous forme de service géré, TradingHost est la voie la plus rapide.
Oui. TradingHost exécute des stratégies Python ; choisissez l'environnement d'exécution 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 propose une classe unifiée `ripio` qui couvre le trading au comptant (spot) sur les paires Ripio Trade. Intégrez votre stratégie CCXT dans un conteneur, liez-la à GitHub, et TradingHost l'exécutera comme n'importe quel autre projet Python ou Node. Consultez l'environnement d'exécution du framework CCXT pour connaître toute la procédure de configuration.
Oui. Les paires fiat d'Amérique latine de Ripio (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR, etc.) sont accessibles via les mêmes API REST et WebSocket que les paires mondiales. Le code de la stratégie dans votre conteneur s'authentifie avec votre clé API Ripio Trade, TradingHost étant totalement agnostique vis-à-vis des plateformes au niveau du runtime. Notez que la disponibilité des paires est filtrée par pays via le paramètre de requête `countries` ; il est donc préférable de récupérer les paires au démarrage plutôt que de les coder en dur.
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 du runtime TradingHost pour découvrir le modèle multi-stratégie.
La voie la plus rapide consiste à forker un environnement d'exécution de framework TradingHost : CCXT 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 pour les environnements d'exécution 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 approuvé de gestion des secrets. TradingHost n'a pas besoin de conserver votre clé API ni votre secret. Consultez la section sur les secrets de la plateforme pour connaître le modèle de gestion complet.
Non. Les stratégies ne devraient jamais avoir besoin d'autorisations de retrait. Limitez la portée de votre clé API uniquement au trading et à la lecture de l'état du compte, et désactivez complètement les retraits pour cette clé.
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 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 en savoir plus.
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 d'IA : un simple git push sur votre branche principale déclenche un redéploiement.
L'environnement d'exécution détecte le plantage et expose les logs ainsi que les informations de santé pertinentes. 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 risque. Consultez la section observabilité pour en savoir plus sur l'interface de logs et de santé.
Les limites de requêtes (rate limits) de l'API v4 de Ripio Trade sont structurées par paliers selon le statut KYC. Les comptes non vérifiés sont limités à 1 requête par seconde, et les comptes vérifiés à 3,5 requêtes par seconde. Tout dépassement du palier renvoie une erreur HTTP 429. La solution consiste à adapter la cadence de vos requêtes au palier actuel de votre compte, à traiter ce palier comme une variable de configuration d'exécution (runtime config) plutôt que comme une constante, et à appliquer un back-off exponentiel avec gigue (exponential jitter) en cas d'erreur 429. Consultez la section Notes opérationnelles ci-dessus pour obtenir toutes les instructions.
TradingHost est disponible 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 plus de détails sur le routage et la proximité.
Non. TradingHost se concentre exclusivement sur l'exécution (runtime) et le déploiement en production. Le backtesting relève de votre environnement de recherche, de votre framework ou d'AlgoBuilder.