Runtime natif IA pour stratégies de trading bitFlyer
Créez vos stratégies 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
- bitFlyer
- Type de plateforme
- Plateforme d'échange crypto (licenciée au JP, US, EU)
- Classe d’actifs
- Crypto (spot, JP Crypto CFD)
- Produits pris en charge
- Trading spot sur les paires BTC, ETH et JPY. Japon uniquement : produit Crypto CFD FX_BTC_JPY (anciennement Lightning FX). La disponibilité des produits varie selon la juridiction ; les comptes US et EU ont accès à un sous-ensemble de la liste product_code du Japon.
- 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 native bitFlyer Lightning (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 bitFlyer
- Compte d'échange, accès API, accès au marché, lieu d'exécution
- Affiliation
- TradingHost est indépendant et n'est pas affilié à bitFlyer.
Section 02 · Ce que propose bitFlyer
Ce que propose bitFlyer
bitFlyer propose du trading spot sur BTC, ETH et d'autres paires dans trois juridictions (JP, US, EU), ainsi qu'un produit Crypto CFD réservé au Japon (FX_BTC_JPY). Toutes les juridictions partagent le même endpoint d'API Lightning à l'adresse api.bitflyer.com mais affichent des listes product_code et des disponibilités de produits différentes. Les stratégies s'authentifient via des requêtes à trois en-têtes signées par HMAC-SHA256. Les spécificités des endpoints évoluent avec le temps. La structure globale reste stable ; les limites de requêtes précises, les paliers de frais et les listes de produits sont détaillés dans la documentation de bitFlyer.
Marchés et types de stratégies
- Stratégies spot libellées en JPY (BTC_JPY, ETH_JPY)
- Stratégies spot libellées en USD (comptes US)
- Stratégies spot libellées en EUR (comptes EU)
- Stratégies Crypto CFD JP via FX_BTC_JPY
- Trading sur taux de financement (funding rate) sur le Crypto CFD JP
- Arbitrage de prix inter-juridictions avec la même structure de compte
- Abonnements aux données de marché en temps réel via WebSocket
- Déploiements multi-stratégies isolés par sous-comptes
Interface API
- Produits couverts
- Trading spot sur BTC, ETH et d'autres paires listées. Japon uniquement : Crypto CFD (FX_BTC_JPY, anciennement Lightning FX), réglé en JPY. La disponibilité des produits est restreinte par juridiction ; le même endpoint d'API Lightning dessert les trois juridictions, mais la liste product_code diffère selon le compte.
- Méthodes de connexion
- REST sur https://api.bitflyer.com/v1/ pour le passage d'ordres, les données de marché et les requêtes de compte. WebSocket via JSON-RPC 2.0 sur l'endpoint lightning.bitflyer.com pour les données de marché en temps réel et les canaux privés. Les canaux WebSocket publics ne nécessitent pas d'authentification ; les canaux privés oui.
- Authentification
- Clé API et secret par stratégie. Les requêtes REST privées contiennent les en-têtes ACCESS-KEY, ACCESS-TIMESTAMP et ACCESS-SIGN. La signature est un HMAC-SHA256 sur le timestamp + méthode HTTP + chemin + corps, avec une sortie au format hexadécimal. Les permissions sont définies par clé (lecture, trading, retraits). Les stratégies ne devraient jamais avoir besoin de la permission de retrait.
Pour plus de détails, reportez-vous à bitFlyer
Les endpoints spécifiques, les limites de requêtes, les listes product_code, les paliers de frais et l'historique des versions se trouvent dans la documentation de bitFlyer. Considérez-les comme la source de vérité.
Section 03 · Développer avec l’IA
Développez votre stratégie bitFlyer 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 bitFlyer Lightning
Contrôle direct du comportement spécifique à bitFlyer, des listes product_code et de la 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 bitFlyer.
Compatibilité des frameworks avec les produits bitFlyer
La prise en charge par les frameworks est plus limitée pour bitFlyer que pour les plateformes de premier plan (Tier-1). CCXT expose le spot bitFlyer via la classe unifiée bitflyer ; le produit JP Crypto CFD n'est pas une primitive CCXT de premier ordre. Hummingbot et Freqtrade ne listent pas bitFlyer parmi leurs plateformes officiellement supportées. L'accès natif à l'API Lightning de bitFlyer permet d'accéder à tout ce que bitFlyer propose dans chaque juridiction.
✓ 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
bitFlyer 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 à bitFlyer.
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 à bitFlyer.
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.
- É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 et secret bitFlyer, product_code spécifique à la juridiction, etc.), puis 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 bitFlyer
Les pièges qui vous guettent lorsque vous exécutez réellement une stratégie bitFlyer dans un runtime cloud conteneurisé, absents de la documentation de bitFlyer ou des fichiers README des frameworks. Chaque point ci-dessous est cité ou paraphrasé à partir de la propre documentation de bitFlyer ; les conseils liés au déploiement proviennent de l'exécution de ces stratégies sur TradingHost.
01 · Endpoint partagé
Les juridictions JP, US et EU partagent api.bitflyer.com mais affichent des listes product_code différentes
Les trois juridictions de bitFlyer (Japon, États-Unis, Europe) utilisent le même endpoint d'API Lightning à l'adresse https://api.bitflyer.com/v1/. Le paramètre product_code sert de différenciateur : un compte JP voit la liste complète incluant FX_BTC_JPY (Crypto CFD) ; un compte US voit un sous-ensemble autorisé aux États-Unis ; un compte EU voit un sous-ensemble autorisé en Europe. Les stratégies qui codent en dur un product_code réservé au Japon avec un compte non-JP renvoient des erreurs de produit non disponible lors de la soumission de l'ordre. Définissez la liste product_code comme une configuration indexée sur la juridiction du compte, et non comme une constante dans le code.
02 · Renommage du Crypto CFD
FX_BTC_JPY est le code produit actuel ; l'ancien Lightning FX « FX BTC/JPY » a été abandonné en mars 2024
bitFlyer a renommé son produit de trading sur marge Lightning FX en Crypto CFD en mars 2024 et a standardisé le code produit sur FX_BTC_JPY. L'ancien endpoint Lightning FX a été déprécié ; les signatures et les en-têtes sont restés rétrocompatibles pendant la période de transition, mais les intégrations qui ciblent encore l'ancien chemin renvoient aujourd'hui des erreurs de produit indisponible. Les stratégies antérieures à 2024 doivent migrer vers le product_code FX_BTC_JPY sous la structure Crypto CFD.
03 · Limites de requêtes à trois niveaux
Requêtes privées : 500 req / 5 min par IP ; placements d'ordres limités par minute sous 0,1 BTC ; 300 opérations d'ordre/annulation par 5 min
bitFlyer applique plusieurs plafonds de limites de requêtes distincts : 500 requêtes privées par 5 minutes par IP et clé, 100 placements d'ordres par minute pour les ordres inférieurs à 0,1 BTC, et 300 opérations de création/annulation d'ordres par 5 minutes. Les stratégies qui atteignent le plafond des petits ordres atteignent généralement aussi la limite de la fenêtre de 5 minutes peu après. Ajustez le rythme de vos placements sur la plus basse de ces limites, et privilégiez WebSocket pour les mises à jour d'état plutôt que d'interroger l'API REST de manière agressive. La documentation de bitFlyer précise que ces limites "may be changed depending on system load" sans garantie de préavis.
04 · Authentification à trois en-têtes
ACCESS-KEY, ACCESS-TIMESTAMP et ACCESS-SIGN sont tous requis
Les requêtes REST privées de bitFlyer comportent trois en-têtes : ACCESS-KEY (votre clé API), ACCESS-TIMESTAMP (timestamp Unix) et ACCESS-SIGN (HMAC-SHA256 du timestamp + méthode HTTP + chemin + corps, signé avec votre clé secrète, sortie hexadécimale). Les stratégies qui omettent l'un de ces trois éléments renvoient des erreurs de signature. Le corps canonique doit correspondre exactement à ce qui est envoyé, y compris les espaces ; sérialisez le JSON avec un ordre de clés stable avant de signer.
05 · Protocole WebSocket
JSON-RPC 2.0 sur lightning.bitflyer.com ; les canaux privés nécessitent une authentification par message, et non au niveau de la connexion
Le WebSocket bitFlyer Lightning utilise JSON-RPC 2.0 sur l'endpoint lightning.bitflyer.com. Les canaux publics (executions, board, ticker) ne nécessitent aucune authentification. Les canaux privés (child orders, parent orders, exécutions sur votre compte) nécessitent un message d'authentification après la connexion, contenant ACCESS-KEY, ACCESS-TIMESTAMP et ACCESS-SIGN dans les paramètres JSON-RPC. Les stratégies qui s'authentifient uniquement lors de la poignée de main HTTPS et non dans le corps du message JSON-RPC voient leurs abonnements privés s'interrompre silencieusement.
06 · Portée des clés
Une clé à portée limitée par stratégie, jamais de clé maîtresse partagée entre plusieurs stratégies
Les clés API bitFlyer disposent de portées par autorisation (lecture, trading, retraits). Les stratégies ne devraient jamais avoir besoin de l'autorisation de retrait ; isolez les clés permettant les retraits dans un identifiant distinct géré manuellement en dehors du runtime de conteneur. Des clés par stratégie dotées uniquement des autorisations nécessaires limitent la zone d'impact en cas de fuite de clé. La restriction par IP est disponible ; configurez-la si la plage d'IP de sortie du runtime est stable pour votre région.
Section 06 · Conçu pour
Conçu pour
Les runtimes TradingHost pour bitFlyer 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
- Titulaires de comptes bitFlyer au Japon, aux États-Unis et dans l'UE
- 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é à bitFlyer.
Non. Le code de votre stratégie se connecte à bitFlyer et envoie des instructions 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 bitFlyer est fourni par bitFlyer. Vous êtes responsable de votre compte bitFlyer, des autorisations de l'API, de vos identifiants et du respect des conditions d'utilisation de bitFlyer.
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é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 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 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 centralisation des journaux, 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 GitHub, contrôle via MCP depuis vos IDE IA, ainsi que des interfaces de logs et de suivi 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 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 bitFlyer via la classe unifiée `bitflyer`, couvrant le spot pour les juridictions du Japon, des États-Unis et de l'UE. Le produit JP Crypto CFD (FX_BTC_JPY) n'est pas une primitive CCXT de premier plan ; pour ce produit sur marge, ciblez directement l'API native bitFlyer Lightning. Consultez le runtime du framework CCXT pour connaître tous les détails de configuration.
Non. Le produit JP Crypto CFD (FX_BTC_JPY, anciennement Lightning FX) est sous licence de bitFlyer Japan et n'est disponible que pour les utilisateurs agréés au Japon. Les comptes bitFlyer américains et européens voient une cartographie de product_code différente et ne peuvent pas trader le FX_BTC_JPY via l'API, quelle que soit la logique de la stratégie. Les stratégies nécessitant ce produit doivent s'exécuter sur un compte bitFlyer agréé au Japon, et l'IP de sortie du runtime doit être cohérente avec la juridiction de ce compte.
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 en savoir plus sur le modèle multi-stratégie.
La voie la plus rapide consiste à forker un runtime de framework TradingHost : CCXT pour un projet spot prêt à être déployé. Ou connectez votre propre dépôt de stratégie GitHub si vous ciblez l'API native Lightning pour le produit JP Crypto CFD. 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 approuvé de gestion des secrets. TradingHost n'a pas besoin de conserver votre clé API ni votre secret. Consultez les secrets de la plateforme pour connaître le modèle complet de gestion.
Non. Les stratégies ne devraient jamais avoir besoin d'autorisations de retrait. Utilisez des autorisations limitées (lecture, trading) et la restriction par IP si nécessaire.
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 l'interface de contrôle MCP pour en savoir plus.
Les deux. L'interface de contrôle MCP fonctionne tout aussi bien à partir d'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 vers votre branche principale déclenche un redéploiement.
Le runtime détecte le plantage et expose les logs et les indicateurs de santé 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 observabilité pour en savoir plus sur les logs et l'interface de santé.
La correspondance product_code de bitFlyer est restreinte par juridiction. Le même point de terminaison Lightning API dessert les utilisateurs JP, US et EU, mais chaque juridiction accède à un sous-ensemble de produits différent. Un compte US ou EU ciblant FX_BTC_JPY (le produit Crypto CFD réservé au Japon) recevra des erreurs product-not-available, quelles que soient les autorisations de sa clé API. Les stratégies qui ciblaient « Lightning FX » avant 2024 doivent également migrer vers FX_BTC_JPY suite au changement de nom en mars 2024. Configurez la liste des product_code en fonction de la juridiction du compte. 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 des détails sur le routage et la proximité.
Non. TradingHost se concentre exclusivement sur l'exécution en production (runtime) et le déploiement. Le backtesting relève de votre environnement de recherche, de votre framework ou d'AlgoBuilder.