AI-native runtime for bitFlyer trading strategies
Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.
Section 01 · At a glance
At a glance
- Venue
- bitFlyer
- Venue type
- Crypto exchange (JP, US, EU licensed)
- Asset class
- Crypto (spot, JP Crypto CFD)
- Supported products
- Spot trading on BTC, ETH and JPY pairs. JP-only: Crypto CFD product FX_BTC_JPY (formerly Lightning FX). Product availability differs by jurisdiction; US and EU accounts see a subset of the JP product_code list.
- Runtime model
- Containerised strategy runtime
- Deployment source
- GitHub
- Languages
- Any language that runs in a container
- Common integrations
- Native bitFlyer Lightning API (REST and WebSocket), CCXT, custom connectors
- AI workflow integration
- MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
- TradingHost role
- Runtime, deployment, logs, health checks, region selection, MCP control
- bitFlyer role
- Exchange account, API access, market access, execution venue
- Affiliation
- TradingHost is independent and is not affiliated with bitFlyer.
Section 02 · What bitFlyer offers
What bitFlyer offers
bitFlyer offers spot trading on BTC, ETH and other pairs across three jurisdictions (JP, US, EU), plus a JP-only Crypto CFD product (FX_BTC_JPY). All jurisdictions share the same Lightning API endpoint at api.bitflyer.com but see different product_code maps and product availability. Strategies authenticate with HMAC-SHA256-signed three-header requests. Endpoint specifics change over time. The shape is durable; the precise rate-limit weights, fee tiers and product lists live in bitFlyer's docs.
Markets and strategy patterns
- JPY-quoted spot strategies (BTC_JPY, ETH_JPY)
- USD-quoted spot strategies (US accounts)
- EUR-quoted spot strategies (EU accounts)
- JP Crypto CFD strategies via FX_BTC_JPY
- Funding-rate trading on JP Crypto CFD
- Cross-jurisdiction price arbitrage with the same account framework
- WebSocket realtime market data subscriptions
- Sub-account-isolated multi-strategy deployments
API surface
- Product surfaces
- Spot trading on BTC, ETH and other listed pairs. JP-only: Crypto CFD (FX_BTC_JPY, formerly Lightning FX), settled in JPY. Product availability is jurisdiction-gated; the same Lightning API endpoint serves all three jurisdictions but the product_code map differs by account.
- Connection methods
- REST at https://api.bitflyer.com/v1/ for order placement, market data and account queries. WebSocket via JSON-RPC 2.0 over the lightning.bitflyer.com endpoint for real-time market data and private channels. Public WebSocket channels do not require auth; private channels do.
- Authentication
- API key and secret per strategy. Private REST requests carry ACCESS-KEY, ACCESS-TIMESTAMP and ACCESS-SIGN headers. The signature is HMAC-SHA256 over timestamp + HTTP method + path + body, with hex output. Permissions are scoped per key (read, trade, withdrawal). Strategies should never need withdrawal permission.
For specifics, refer to bitFlyer
Specific endpoints, rate-limit weights, product_code lists, fee tiers and version history live in bitFlyer's documentation. Treat these as the source of truth.
Section 03 · Build with AI
Build your bitFlyer strategy with AI
Pick an integration method, fork a TradingHost framework starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.
Native bitFlyer Lightning API
Direct control over bitFlyer-specific behaviour, product_code maps and order execution logic.
Hummingbot
Framework-based deployments using Hummingbot strategy structure and configuration model.
Custom connector
Your own internal trading engine or proprietary bitFlyer integration.
Framework support for bitFlyer products
Framework coverage is thinner for bitFlyer than for Tier-1 venues. CCXT exposes bitFlyer spot through the unified bitflyer class; the JP Crypto CFD product is not a first-class CCXT primitive. Hummingbot and Freqtrade do not list bitFlyer in their officially supported exchanges. Native bitFlyer Lightning API access reaches everything bitFlyer offers in each jurisdiction.
✓ confirmed support per official framework docs. "no" indicates not officially documented as supported.
TradingHost does not force a framework. It runs your project.
Author with AI
The framework starters above pair naturally with AI IDEs. The TradingHost MCP control surface closes the loop: AI tools can inspect deployments, review logs and manage the runtime alongside you, never the trade execution path.
Section 04 · Run on TradingHost
Run your code on TradingHost
bitFlyer provides the exchange and API access. TradingHost provides the production environment where your bitFlyer-connected strategy runs.
Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.
You
- Your repo contains your code.
- Your deployment defines how it runs.
- Your strategy connects to bitFlyer.
TradingHost
- Keeps the runtime online.
- Surfaces logs and health checks.
- Region selection.
- Controlled deployment surface.
Deployment flow
- STEP 01
Connect GitHub
Authorise TradingHost to access your GitHub account.
- STEP 02
Link a repo or start from a framework
Point TradingHost at your existing strategy repo, or fork a TradingHost framework runtime (CCXT) for a working baseline.
- STEP 03
Deploy into a TradingHost container
Pick a region (EU or US-East), supply the environment values your strategy needs (bitFlyer API key and secret, jurisdiction-specific product_code, etc.), and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. No local Docker install required.
- STEP 04
Monitor logs and health
Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE, so Cursor, Claude Code or a CLI agent can read deployment state and manage the runtime alongside you.
- STEP 05
Update and redeploy
Push changes to your GitHub main branch and TradingHost redeploys automatically.
Section 05 · Operational notes
Operational notes for bitFlyer
Things that bite you when you actually run a bitFlyer strategy in a containerised cloud runtime, not in bitFlyer's docs, not in framework READMEs. Every claim below is quoted or paraphrased from bitFlyer's own documentation; the deployment-side guidance is from running these strategies on TradingHost.
01 · Shared endpoint
JP, US and EU jurisdictions share api.bitflyer.com but see different product_code maps
All three bitFlyer jurisdictions (Japan, US, EU) use the same Lightning API endpoint at https://api.bitflyer.com/v1/. The product_code parameter is the differentiator: a JP account sees the full list including FX_BTC_JPY (Crypto CFD); a US account sees a US-licensed subset; an EU account sees an EU-licensed subset. Strategies that hard-code a JP-only product_code against a non-JP account return product-not-available errors at order submission. Pin the product_code list as configuration keyed on the account jurisdiction, not as a constant in code.
02 · Crypto CFD rename
FX_BTC_JPY is the current product code; legacy "FX BTC/JPY" Lightning FX deprecated March 2024
bitFlyer rebranded its margin-trading Lightning FX product to Crypto CFD effective March 2024 and standardised the product code on FX_BTC_JPY. The legacy Lightning FX endpoint was deprecated; signatures and headers stayed backward-compatible during the transition window, but integrations that still target the old code path return product-unavailable errors today. Strategies pre-2024 must migrate to the FX_BTC_JPY product_code under the Crypto CFD framing.
03 · Three-tier rate limits
Private 500 req / 5 min per IP; order placements capped per minute below 0.1 BTC; 300 order/cancel ops per 5 min
bitFlyer enforces several distinct rate-limit ceilings: 500 private requests per 5 minutes per IP plus key, 100 order placements per minute for orders smaller than 0.1 BTC, and 300 order/cancel operations per 5 minutes. Strategies that hit the small-order cap typically also hit the 5-minute window soon after. Re-pace placements against the lower of the limits, and treat WebSocket for state updates rather than polling REST aggressively. bitFlyer docs state the limits "may be changed depending on system load" with no advance-notice guarantee.
04 · Three-header auth
ACCESS-KEY, ACCESS-TIMESTAMP, ACCESS-SIGN are all required
bitFlyer private REST requests carry three headers: ACCESS-KEY (your API key), ACCESS-TIMESTAMP (Unix timestamp), and ACCESS-SIGN (HMAC-SHA256 of timestamp + HTTP method + path + body, signed with your secret, hex output). Strategies that omit any of the three return signature-error responses. The canonical body must match exactly what is sent, including whitespace; serialise JSON with stable key ordering before signing.
05 · WebSocket protocol
JSON-RPC 2.0 over lightning.bitflyer.com; private channels require per-message auth, not connection-level
bitFlyer Lightning WebSocket is JSON-RPC 2.0 over the lightning.bitflyer.com endpoint. Public channels (executions, board, ticker) require no authentication. Private channels (child orders, parent orders, executions on your account) require an auth message after connect carrying ACCESS-KEY, ACCESS-TIMESTAMP and ACCESS-SIGN as part of the JSON-RPC params. Strategies that authenticate only at HTTPS handshake and not in the JSON-RPC body see private subscriptions silently drop.
06 · Key scoping
One scoped key per strategy, never one master key shared across strategies
bitFlyer API keys carry per-permission scoping (read, trade, withdrawal). Strategies should never need withdrawal scope; isolate withdrawal-capable keys on a separate manually-managed credential outside the container runtime. Per-strategy keys with only the scopes that strategy needs contain the blast radius if a key leaks. IP whitelisting is available; pin where the runtime egress range is stable for your region.
Section 06 · Built for
Built for
TradingHost bitFlyer runtimes are best suited to:
- Developers building strategies in AI IDEs (Cursor, Claude Code)
- Systematic crypto traders
- Quant developers
- JP, US and EU bitFlyer account holders
- CCXT users
- Teams moving from VPS hosting to containerised deployment
Connecting GitHub and creating your first strategy is free.
Section 08 · FAQ
FAQ
No. TradingHost is independent and is not affiliated with bitFlyer.
No. Your strategy code connects to bitFlyer and sends instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.
No. bitFlyer API access is provided by bitFlyer. You are responsible for your bitFlyer account, API permissions, credentials and compliance with bitFlyer’s terms.
No. TradingHost is the cloud runtime where your strategy code runs. We do not provide signals, AI prediction models or pre-built bots. With TradingHost you write or generate the strategy yourself (often with Cursor or Claude Code), keep it in GitHub as your code, and use TradingHost to run it in production. 3Commas, Cryptohopper and similar products own the strategy logic; TradingHost runs your strategy.
AWS and DigitalOcean give you raw compute. You handle OS updates, container orchestration, log shipping, secret rotation, region failover and uptime monitoring yourself. TradingHost gives you a managed runtime purpose-built for trading strategies: GitHub-native deployment, MCP-driven control from AI IDEs, log and health surfaces out of the box. If you want to operate the infrastructure yourself, AWS works. If you want the runtime as a managed service, TradingHost is the shorter path.
Yes. TradingHost runs Python strategies; pick the framework runtime that matches your stack or deploy your own repo.
Yes. TradingHost supports any language that can run inside a container.
Yes. CCXT exposes bitFlyer through the unified `bitflyer` class, covering spot across the JP, US and EU jurisdictions. The JP Crypto CFD product (FX_BTC_JPY) is not a first-class CCXT primitive; for the margin product, target the native bitFlyer Lightning API. See the CCXT framework runtime for the full setup story.
No. The JP Crypto CFD product (FX_BTC_JPY, formerly Lightning FX) is licensed to bitFlyer Japan and available only to JP-licensed users. US and EU bitFlyer accounts see a different product_code map and cannot trade FX_BTC_JPY through the API regardless of strategy logic. Strategies that need this product must run on a JP-licensed bitFlyer account, and the runtime egress should be consistent with that account jurisdiction.
Yes, if your project is designed that way. You can run multiple strategy processes or services inside one runtime, or separate them into different runtimes for isolation and operational clarity. See the TradingHost runtime page for the multi-strategy model.
The fastest path is to fork a TradingHost framework runtime: CCXT for a ready-to-deploy spot project. Or connect your own GitHub strategy repo if you target the native Lightning API for JP Crypto CFD. Linking a GitHub repo and creating a strategy is free; runtime plans are listed on the pricing page.
In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your API key and secret. See platform secrets for the full handling model.
No. Strategies should never need withdrawal permissions. Use scoped permissions (read, trade) and IP whitelisting where appropriate.
Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. AI tools can inspect deployments, review logs, restart strategies and manage runtime workflows. MCP is a control and observability surface, not the trade execution path. See the MCP control surface for the full picture.
Both. The MCP control surface works equally well from CLI-based agents (Claude Code CLI, custom MCP clients, scripted MCP calls) and from inside an IDE. The GitHub-native deployment loop also works without any AI tooling: a regular git push to your main branch triggers a redeploy.
The runtime detects the crash and exposes the relevant logs and health information. Where supported, the affected strategy can be restarted without disrupting other strategies running in the same container. Your strategy code is still responsible for safe error handling, duplicate-order protection and risk controls. See observability for the logs and health surface.
bitFlyer's product_code map is jurisdiction-gated. The same Lightning API endpoint serves JP, US and EU users, but each jurisdiction sees a different subset of available products. A US or EU account hitting FX_BTC_JPY (the JP-only Crypto CFD product) sees product-not-available errors regardless of API key permissions. Strategies that pre-2024 targeted "Lightning FX" must also migrate to FX_BTC_JPY since the rename in March 2024. Pin the product_code list as configuration keyed on account jurisdiction. See the Operational notes section above for the full guidance.
TradingHost runs in the EU and US-East regions. Pick the region closest to the matching engine your strategy depends on. See the regions page for routing and proximity details.
No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.