Runtime nativo para IA para estratégias de trading no bitFlyer
Desenvolva no Cursor, Claude Code ou em qualquer IDE de IA. Faça o deploy a partir do GitHub em um runtime de nuvem gerenciado com controle MCP de primeira classe, logs e seleção de região.
Seção 01 · Visão rápida
Visão rápida
- Plataforma
- bitFlyer
- Tipo de plataforma
- Exchange de cripto (licenciada em JP, US, EU)
- Classe de ativos
- Cripto (spot, JP Crypto CFD)
- Produtos suportados
- Negociação spot em pares de BTC, ETH e JPY. Apenas JP: produto Crypto CFD FX_BTC_JPY (antigo Lightning FX). A disponibilidade dos produtos varia por jurisdição; contas dos EUA e da UE veem um subconjunto da lista de product_code do JP.
- Modelo de runtime
- Runtime de estratégia conteinerizado
- Origem do deploy
- GitHub
- Linguagens
- Qualquer linguagem que execute em um contêiner
- Integrações comuns
- API nativa do bitFlyer Lightning (REST e WebSocket), CCXT, conectores personalizados
- Integração com fluxo de IA
- Superfície de controle MCP para Cursor, Claude Code, GitHub Copilot e agentes de CLI
- Papel da TradingHost
- Runtime, deploy, logs, health checks, seleção de região, controle MCP
- Papel de bitFlyer
- Conta na exchange, acesso à API, acesso ao mercado, local de execução
- Afiliação
- O TradingHost é independente e não tem afiliação com o bitFlyer.
Seção 02 · O que bitFlyer oferece
O que bitFlyer oferece
O bitFlyer oferece negociação spot de BTC, ETH e outros pares em três jurisdições (JP, EUA, UE), além de um produto Crypto CFD exclusivo para o JP (FX_BTC_JPY). Todas as jurisdições compartilham o mesmo endpoint da Lightning API em api.bitflyer.com, mas possuem diferentes mapeamentos de product_code e disponibilidade de produtos. As estratégias se autenticam por meio de requisições com três cabeçalhos assinados com HMAC-SHA256. Detalhes específicos dos endpoints podem mudar com o tempo. A estrutura geral é estável; os limites de taxa (rate limits), faixas de taxas de corretagem (fee tiers) e listas de produtos exatos devem ser consultados diretamente na documentação do bitFlyer.
Mercados e padrões de estratégia
- Estratégias spot cotadas em JPY (BTC_JPY, ETH_JPY)
- Estratégias spot cotadas em USD (contas dos EUA)
- Estratégias spot cotadas em EUR (contas da UE)
- Estratégias de Crypto CFD no JP via FX_BTC_JPY
- Trading de taxa de financiamento (funding rate) no Crypto CFD do JP
- Arbitragem de preços entre jurisdições usando a mesma estrutura de conta
- Assinaturas de dados de mercado em tempo real via WebSocket
- Deploys de múltiplas estratégias isoladas por subcontas
Superfície da API
- Superfícies de produtos
- Negociação spot em BTC, ETH e outros pares listados. Exclusivo para o JP: Crypto CFD (FX_BTC_JPY, antigo Lightning FX), liquidado em JPY. A disponibilidade dos produtos é restrita por jurisdição; o mesmo endpoint da Lightning API atende às três jurisdições, mas o mapeamento de product_code varia conforme a conta.
- Métodos de conexão
- REST em https://api.bitflyer.com/v1/ para envio de ordens, dados de mercado e consultas de conta. WebSocket via JSON-RPC 2.0 no endpoint lightning.bitflyer.com para dados de mercado em tempo real e canais privados. Canais públicos de WebSocket não exigem autenticação; canais privados exigem.
- Autenticação
- Chave de API e segredo (secret) por estratégia. Requisições REST privadas contêm os cabeçalhos ACCESS-KEY, ACCESS-TIMESTAMP e ACCESS-SIGN. A assinatura é um HMAC-SHA256 sobre timestamp + método HTTP + path + body, com saída em hexadecimal. As permissões são limitadas por chave (leitura, negociação, saque). As estratégias nunca devem precisar de permissão de saque.
Para detalhes específicos, consulte bitFlyer
Endpoints específicos, pesos de limite de taxa (rate limits), listas de product_code, faixas de taxas (fee tiers) e histórico de versões estão na documentação do bitFlyer. Considere-os como a única fonte da verdade.
Seção 03 · Desenvolva com IA
Desenvolva sua estratégia para bitFlyer com IA
Escolha um método de integração, faça um fork de um starter de framework da TradingHost e desenvolva sua estratégia em uma AI IDE. Cursor, Claude Code, GitHub Copilot e agentes de IA baseados em CLI funcionam com o mesmo fluxo de deploy nativo do GitHub.
API nativa do bitFlyer Lightning
Controle direto sobre comportamentos específicos do bitFlyer, mapeamentos de product_code e lógica de execução de ordens.
Hummingbot
Deploys baseados em framework usando a estrutura de estratégia e o modelo de configuração do Hummingbot.
Conector personalizado
Seu próprio motor de trading interno ou integração proprietária com o bitFlyer.
Suporte de frameworks para produtos bitFlyer
O suporte de frameworks para o bitFlyer é mais limitado do que para plataformas Tier-1. O CCXT expõe o mercado spot do bitFlyer por meio da classe unificada bitflyer; o produto JP Crypto CFD não é tratado como uma primitiva nativa do CCXT. O Hummingbot e o Freqtrade não listam o bitFlyer entre suas exchanges oficialmente suportadas. O acesso nativo à Lightning API do bitFlyer alcança tudo o que a exchange oferece em cada jurisdição.
✓ suporte confirmado de acordo com a documentação oficial do framework. "não" indica que não há suporte documentado oficialmente.
A TradingHost não impõe nenhum framework. Ela executa o seu projeto.
Desenvolva com IA
Os starters de framework acima combinam perfeitamente com AI IDEs. A interface de controle MCP da TradingHost fecha o ciclo: as ferramentas de IA podem inspecionar deploys, analisar logs e gerenciar o runtime junto com você, sem nunca interferir no caminho de execução das ordens.
Seção 04 · Execute na TradingHost
Execute seu código na TradingHost
A bitFlyer fornece a exchange e o acesso à API. A TradingHost fornece o ambiente de produção onde sua estratégia conectada à bitFlyer é executada.
Em vez de executar o código da estratégia em um notebook, computador desktop, VPS genérico ou servidor configurado manualmente, você faz o deploy a partir do GitHub em um runtime de container gerenciado pela TradingHost.
Você
- Seu repositório contém seu código.
- Seu deploy define como ele é executado.
- Sua estratégia se conecta à bitFlyer.
TradingHost
- Mantém o runtime online.
- Exibe logs e health checks.
- Seleção de região.
- Superfície de deploy controlada.
Fluxo de deploy
- PASSO 01
Conecte o GitHub
Autorize a TradingHost a acessar sua conta do GitHub.
- PASSO 02
Vincule um repositório ou comece a partir de um framework
Aponte o TradingHost para o repositório da sua estratégia existente ou faça um fork de um runtime de framework do TradingHost (CCXT) para obter uma base funcional.
- PASSO 03
Implante em um contêiner da TradingHost
Escolha uma região (EU ou US-East), informe as variáveis de ambiente que sua estratégia exige (chave de API e segredo da bitFlyer, o product_code específico da jurisdição, etc.) e faça o deploy. A TradingHost compila seu contêiner a partir do repositório e executa sua estratégia em uma infraestrutura gerenciada de Kubernetes. Não é necessário instalar o Docker localmente.
- PASSO 04
Monitore logs e integridade
Acompanhe logs em tempo real, a integridade e o estado do runtime diretamente pelo painel da TradingHost. Essa mesma interface pode ser acessada via MCP a partir de qualquer AI IDE — assim, o Cursor, o Claude Code ou um agente de CLI podem ler o estado do deploy e gerenciar o runtime junto com você.
- PASSO 05
Atualize e faça o redeploy
Faça push das alterações para a branch principal do seu GitHub e a TradingHost realiza o redeploy de forma automática.
Seção 05 · Notas operacionais
Notas operacionais para bitFlyer
Problemas práticos que surgem ao rodar uma estratégia do bitFlyer em um runtime de nuvem conteinerizado, detalhes que não estão na documentação oficial nem nos READMEs dos frameworks. Cada ponto abaixo foi citado ou parafraseado da própria documentação do bitFlyer, e as orientações de deploy vêm da experiência prática de rodar essas estratégias no TradingHost.
01 · Endpoint compartilhado
Jurisdições JP, EUA e UE compartilham o api.bitflyer.com, mas possuem mapeamentos de product_code diferentes
Todas as três jurisdições do bitFlyer (Japão, EUA, UE) usam o mesmo endpoint da Lightning API em https://api.bitflyer.com/v1/. O parâmetro product_code é o diferencial: uma conta do JP vê a lista completa, incluindo FX_BTC_JPY (Crypto CFD); uma conta dos EUA vê um subconjunto licenciado para os EUA; uma conta da UE vê um subconjunto licenciado para a UE. Estratégias que definem um product_code exclusivo do JP diretamente no código para uma conta de fora do JP retornarão erros de produto não disponível no envio da ordem. Defina a lista de product_code como uma configuração baseada na jurisdição da conta, e não como uma constante no código.
02 · Renomeação do Crypto CFD
FX_BTC_JPY é o product_code atual; o antigo "FX BTC/JPY" Lightning FX foi descontinuado em março de 2024
A bitFlyer renomeou seu produto de trading de margem Lightning FX para Crypto CFD a partir de março de 2024 e padronizou o código do produto como FX_BTC_JPY. O endpoint legado do Lightning FX foi descontinuado; as assinaturas e cabeçalhos permaneceram retrocompatíveis durante a janela de transição, mas as integrações que ainda apontam para o caminho de código antigo hoje retornam erros de produto indisponível. Estratégias anteriores a 2024 devem migrar para o product_code FX_BTC_JPY sob a estrutura do Crypto CFD.
03 · Limites de taxa em três níveis
Privado: 500 req / 5 min por IP; envio de ordens limitado por minuto abaixo de 0.1 BTC; 300 operações de ordem/cancelamento por 5 min
A bitFlyer aplica vários limites de taxa distintos: 500 requisições privadas por 5 minutos por IP mais chave, 100 envios de ordens por minuto para ordens menores que 0.1 BTC e 300 operações de ordem/cancelamento por 5 minutos. Estratégias que atingem o limite de ordens pequenas geralmente também atingem a janela de 5 minutos logo em seguida. Ajuste o ritmo dos envios com base no menor dos limites e use WebSocket para atualizações de estado em vez de fazer polling agressivo via REST. A documentação da bitFlyer afirma que os limites "may be changed depending on system load" sem garantia de aviso prévio.
04 · Autenticação com três cabeçalhos
ACCESS-KEY, ACCESS-TIMESTAMP e ACCESS-SIGN são obrigatórios
As requisições REST privadas da bitFlyer contêm três cabeçalhos: ACCESS-KEY (sua chave de API), ACCESS-TIMESTAMP (timestamp Unix) e ACCESS-SIGN (HMAC-SHA256 do timestamp + método HTTP + caminho + corpo, assinado com seu segredo, saída em hex). Estratégias que omitem qualquer um dos três retornam respostas de erro de assinatura. O corpo canônico deve corresponder exatamente ao que é enviado, incluindo espaços em branco; serialize o JSON com ordenação de chaves estável antes de assinar.
05 · Protocolo WebSocket
JSON-RPC 2.0 via lightning.bitflyer.com; canais privados exigem autenticação por mensagem, não no nível da conexão
O WebSocket do bitFlyer Lightning é JSON-RPC 2.0 sobre o endpoint lightning.bitflyer.com. Canais públicos (execuções, livro de ofertas, ticker) não exigem autenticação. Canais privados (ordens filhas, ordens mães, execuções na sua conta) exigem uma mensagem de autenticação após a conexão contendo ACCESS-KEY, ACCESS-TIMESTAMP e ACCESS-SIGN como parte dos parâmetros JSON-RPC. Estratégias que se autenticam apenas no handshake HTTPS e não no corpo do JSON-RPC veem as inscrições privadas caírem silenciosamente.
06 · Escopo de chaves
Uma chave com escopo limitado por estratégia, nunca uma chave mestra compartilhada entre estratégias
As chaves de API da bitFlyer possuem escopo por permissão (leitura, negociação, saque). As estratégias nunca devem precisar de escopo de saque; isole as chaves com permissão de saque em uma credencial separada e gerenciada manualmente fora do runtime do container. Chaves por estratégia, contendo apenas os escopos necessários para aquela estratégia, limitam o raio de impacto em caso de vazamento. A liberação de IPs (IP whitelisting) está disponível; fixe-a onde a faixa de saída do runtime for estável para a sua região.
Seção 06 · Indicado para
Indicado para
Os runtimes da TradingHost para a bitFlyer são ideais para:
- Desenvolvedores criando estratégias em IDEs de IA (Cursor, Claude Code)
- Traders sistemáticos de cripto
- Desenvolvedores quantitativos
- Titulares de contas bitFlyer no Japão, EUA e UE
- Usuários do CCXT
- Equipes migrando de hospedagem VPS para implantação em containers
Conectar o GitHub e criar sua primeira estratégia é grátis.
Seção 08 · Perguntas frequentes
Perguntas frequentes
Não. A TradingHost é independente e não é afiliada à bitFlyer.
Não. O código da sua estratégia se conecta à bitFlyer e envia instruções de acordo com a sua própria lógica, permissões de conta e método de integração. A TradingHost fornece o runtime onde esse código é executado.
Não. O acesso à API da bitFlyer é fornecido pela própria bitFlyer. Você é responsável por sua conta bitFlyer, permissões de API, credenciais e conformidade com os termos da bitFlyer.
Não. A TradingHost é o runtime em nuvem onde o código da sua estratégia é executado. Nós não fornecemos sinais, modelos de previsão de IA ou robôs prontos. Com a TradingHost, você mesmo escreve ou gera a estratégia (geralmente com o Cursor ou Claude Code), mantém o código no GitHub e usa a TradingHost para executá-lo em produção. O 3Commas, o Cryptohopper e produtos semelhantes detêm a lógica da estratégia; a TradingHost executa a sua estratégia.
A AWS e a DigitalOcean fornecem computação bruta. Você mesmo precisa lidar com atualizações de sistema operacional, orquestração de containers, envio de logs, rotação de segredos, failover de região e monitoramento de uptime. A TradingHost oferece um runtime gerenciado criado especificamente para estratégias de trading: implantação nativa do GitHub, controle via MCP a partir de IDEs de IA, além de interfaces de log e integridade integradas. Se você quer operar a infraestrutura por conta própria, a AWS atende. Se prefere o runtime como um serviço gerenciado, a TradingHost é o caminho mais curto.
Sim. A TradingHost executa estratégias em Python; escolha o runtime de framework que corresponda à sua stack ou implante seu próprio repositório.
Sim. A TradingHost suporta qualquer linguagem que possa ser executada dentro de um container.
Sim. O CCXT expõe a bitFlyer por meio da classe unificada `bitflyer`, cobrindo o mercado à vista (spot) nas jurisdições do Japão, EUA e UE. O produto Crypto CFD do Japão (FX_BTC_JPY) não é uma primitiva nativa do CCXT; para o produto de margem, utilize a API nativa do bitFlyer Lightning. Consulte o runtime do framework CCXT para ver os detalhes completos de configuração.
Não. O produto Crypto CFD do Japão (FX_BTC_JPY, antigo Lightning FX) é licenciado para a bitFlyer Japan e está disponível apenas para usuários licenciados no Japão. As contas bitFlyer dos EUA e da UE veem um mapa de product_code diferente e não podem negociar FX_BTC_JPY pela API, independentemente da lógica da estratégia. Estratégias que precisam desse produto devem ser executadas em uma conta bitFlyer licenciada no Japão, e a saída do runtime deve ser consistente com a jurisdição dessa conta.
Sim, se o seu projeto for projetado dessa forma. Você pode executar múltiplos processos ou serviços de estratégia dentro de um único runtime, ou separá-los em diferentes runtimes para fins de isolamento e clareza operacional. Consulte a página de runtime da TradingHost para conhecer o modelo multiestratégia.
O caminho mais rápido é fazer um fork de um runtime de framework da TradingHost: CCXT para um projeto spot pronto para implantação. Ou conecte seu próprio repositório de estratégia do GitHub se o seu foco for a API nativa do Lightning para o Crypto CFD do Japão. Vincular um repositório do GitHub e criar uma estratégia é gratuito; os planos de runtime estão listados na página de preços.
No seu fluxo de trabalho de segredos controlado pelo GitHub. A TradingHost lê essas chaves em tempo de execução por meio de segredos do repositório do GitHub, segredos de ambiente ou do seu próprio processo aprovado de gerenciamento de segredos. A TradingHost não precisa da custódia da sua chave de API e segredo. Consulte a seção de segredos da plataforma para conhecer o modelo completo de tratamento.
Não. As estratégias nunca devem precisar de permissões de saque. Use permissões com escopo limitado (leitura, negociação) e liberação de IPs (IP whitelisting) quando apropriado.
Sim. A TradingHost suporta controle baseado em MCP para IDEs de IA, incluindo Cursor, Claude Code, GitHub Copilot e agentes de IA baseados em CLI. As ferramentas de IA podem inspecionar implantações, revisar logs, reiniciar estratégias e gerenciar fluxos de trabalho de runtime. O MCP é uma interface de controle e observabilidade, não o caminho de execução de ordens. Consulte a interface de controle MCP para obter uma visão completa.
Ambos. A interface de controle MCP funciona igualmente bem a partir de agentes baseados em CLI (Claude Code CLI, clientes MCP personalizados, chamadas MCP via script) e de dentro de uma IDE. O ciclo de implantação nativo do GitHub também funciona sem qualquer ferramenta de IA: um git push comum para a sua branch principal aciona uma nova implantação.
O runtime detecta a falha e expõe os logs relevantes e as informações de integridade. Onde houver suporte, a estratégia afetada pode ser reiniciada sem interromper outras estratégias em execução no mesmo container. O código da sua estratégia continua responsável pelo tratamento seguro de erros, proteção contra ordens duplicadas e controles de risco. Consulte a seção de observabilidade para acessar os logs e a interface de integridade.
O mapeamento de product_code da bitFlyer é restrito por jurisdição. O mesmo endpoint da Lightning API atende a usuários do JP, EUA e UE, mas cada jurisdição visualiza um subconjunto diferente de produtos disponíveis. Uma conta dos EUA ou da UE que tente acessar FX_BTC_JPY (o produto de Crypto CFD exclusivo do JP) receberá erros de product-not-available, independentemente das permissões da chave de API. Estratégias anteriores a 2024 que tinham como alvo o "Lightning FX" também devem migrar para FX_BTC_JPY devido à renomeação em março de 2024. Defina a lista de product_code como uma configuração vinculada à jurisdição da conta. Consulte a seção de Notas operacionais acima para obter as orientações completas.
A TradingHost opera nas regiões EU e US-East. Escolha a região mais próxima do matching engine do qual sua estratégia depende. Consulte a página de regiões para obter detalhes de roteamento e proximidade.
Não. O TradingHost é focado em runtime de produção e implantação. O backtesting faz parte da sua stack de pesquisa, framework ou do AlgoBuilder.