Runtime nativo de IA para estratégias de trading na Bitget
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
- Bitget
- Tipo de plataforma
- Exchange de cripto (focada em copy trading)
- Classe de ativos
- Cripto (spot, perpétuos USDT-M e coin-M, margem, copy trading)
- Produtos suportados
- Spot, futuros perpétuos USDT-M, futuros perpétuos coin-M, perpétuos USDC-M, margem isolada e cruzada, copy trading sobre perpétuos. Trading demonstrativo (demo) disponível na API de produção.
- Modelo de runtime
- Runtime de estratégia em container
- Origem do deploy
- GitHub
- Linguagens
- Qualquer linguagem compatível com containers
- Integrações comuns
- REST e WebSocket nativos da Bitget V2, CCXT, Hummingbot, 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, monitoramento de integridade, seleção de região, controle MCP
- Papel de Bitget
- Conta na exchange, acesso à API, acesso ao mercado, ambiente de execução
- Afiliação
- O TradingHost é independente e não possui afiliação com a Bitget.
Seção 02 · O que Bitget oferece
O que Bitget oferece
A Bitget oferece spot, futuros perpétuos USDT-M, coin-M e USDC-M, margem cruzada e isolada, além de uma camada de copy trading sobre perpétuos via APIs REST e WebSocket. As estratégias se autenticam com requisições assinadas por HMAC-SHA256 usando três cabeçalhos na API V2. As especificações dos endpoints mudam com o tempo, mas a estrutura geral é estável; limites de taxa (rate limits), faixas de taxas e listas de símbolos atualizadas devem ser consultados diretamente na documentação da Bitget.
Mercados e padrões de estratégia
- Estratégias de futuros perpétuos USDT-M
- Estratégias de perpétuos coin-M e USDC-M
- Fluxos de copy trading entre contas mestre (parent) e seguidoras (follower)
- Trading de taxa de financiamento (funding rate) e base em perpétuos
- Estratégias de spot e margem (cruzada ou isolada)
- Deploys multi-estratégia isolados por subcontas
- Streams de ordens e posições via canais privados de WebSocket
- Deploys validados em conta demo diretamente na API de produção
Superfície da API
- Superfícies de produtos
- Spot, futuros perpétuos USDT-M, perpétuos coin-M, perpétuos USDC-M, margem isolada e cruzada, além de hierarquias de copy trading (mestre/seguidor). O trading demo expõe a mesma interface V2 para validação na API de produção sem expor capital real.
- Métodos de conexão
- REST para envio de ordens e consultas de conta. Canais públicos de WebSocket para dados de mercado e atualizações do livro de ofertas. Canais privados de WebSocket para eventos de conta, saldo, posições e ordens. A Bitget V2 é a geração atual da API; endpoints legados da V1 continuam documentados, mas novas integrações devem focar na V2.
- Autenticação
- Chave de API, segredo e frase secreta (passphrase) por estratégia. Requisições privadas exigem três cabeçalhos: ACCESS-KEY, ACCESS-TIMESTAMP e ACCESS-SIGN. A assinatura é um HMAC-SHA256 codificado em base64 da concatenação de timestamp + método + requestPath + corpo da requisição. A Bitget rejeita requisições fora de uma janela de tolerância de 30 segundos.
Para detalhes específicos, consulte Bitget
Endpoints específicos, pesos de limite de taxa, listas de símbolos, faixas de taxas e histórico de versões estão disponíveis na documentação da Bitget. Utilize-os como a fonte oficial de informações.
Seção 03 · Desenvolva com IA
Desenvolva sua estratégia para Bitget 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 Bitget V2
Controle direto sobre comportamentos específicos da Bitget, hierarquias de copy trading e lógica de execução de ordens.
Hummingbot
Deploys baseados em framework utilizando 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 a Bitget.
Suporte de frameworks para produtos Bitget
A cobertura varia de acordo com o framework. O CCXT atende spot e perpétuos da Bitget; o Hummingbot oferece um conector bitget_perpetual dedicado além de spot. Hierarquias de copy trading são exclusivas da API nativa atualmente; nenhum framework as abstrai como primitiva nativa. A API nativa Bitget V2 cobre todos os recursos oferecidos pela Bitget, incluindo copy trading.
✓ 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 Bitget fornece a exchange e o acesso à API. A TradingHost fornece o ambiente de produção onde sua estratégia conectada à Bitget é 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 à Bitget.
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 existente da sua estratégia ou faça um fork de um runtime de framework do TradingHost (CCXT ou Hummingbot) para obter uma base funcional.
- PASSO 03
Implante em um contêiner da TradingHost
Escolha uma região (EU ou US-East), forneça as variáveis de ambiente de que sua estratégia precisa (chave de API, segredo e passphrase da Bitget, etc.) e faça o deploy. O TradingHost compila seu container a partir do repositório e executa sua estratégia em uma infraestrutura gerenciada de Kubernetes. Sem necessidade de instalação local do Docker.
- 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 Bitget
Problemas práticos que surgem ao executar uma estratégia da Bitget em um runtime de nuvem baseado em containers — detalhes que não estão na documentação da Bitget nem nos READMEs dos frameworks. Cada ponto abaixo foi extraído ou adaptado da própria documentação da Bitget; as orientações de deploy são baseadas na execução real dessas estratégias no TradingHost.
01 · Autenticação com três cabeçalhos
ACCESS-KEY, ACCESS-TIMESTAMP e ACCESS-SIGN são obrigatórios
As requisições privadas da Bitget V2 exigem três cabeçalhos: ACCESS-KEY (sua chave de API), ACCESS-TIMESTAMP (timestamp Unix atual em milissegundos) e ACCESS-SIGN (HMAC-SHA256 codificado em base64 de timestamp + método + requestPath + corpo da requisição, assinado com sua chave secreta). Um quarto cabeçalho, ACCESS-PASSPHRASE, é obrigatório em todas as requisições assinadas. Estratégias que omitirem qualquer um dos quatro retornarão erros de assinatura inválida (error 40009). A passphrase é definida na criação da chave e não pode ser recuperada posteriormente; se perdida, será necessário gerar uma nova chave.
02 · Janela de 30 segundos
ACCESS-TIMESTAMP fora da janela de tolerância de 30 segundos será rejeitado
A Bitget rejeita qualquer requisição assinada cujo ACCESS-TIMESTAMP tenha uma diferença superior a 30 segundos em relação ao horário do servidor da Bitget. Containers com desvio de relógio (clock drift) maior que 30 segundos terão suas requisições assinadas recusadas pelo servidor, independentemente da validade da assinatura. Os runtimes da TradingHost são sincronizados via NTP, o que torna a tolerância de 30 segundos confortável. No entanto, se um container apresentar desvio (por exemplo, após uma longa partição de rede), seu relógio precisará ser sincronizado novamente antes de conseguir assinar requisições com sucesso.
03 · Da V1 para a V2
A V2 é a geração atual da API; os endpoints da V1 continuam documentados, mas não devem ser usados em novas integrações
A Bitget lançou a API V2 para consolidar os endpoints de spot, USDT-M, coin-M e copy trading sob um único esquema de assinatura e caminho base. Os endpoints da V1 continuam na documentação para compatibilidade retroativa, mas o feed de notas de lançamento acompanha as descontinuações em relação à V2. Novas estratégias devem apontar diretamente para os endpoints da V2 para evitar que a integração herde um prazo de descontinuação. Fixe a versão da API no seu cliente para que uma futura transição para a V3 seja uma migração explícita, e não uma falha silenciosa.
04 · Hierarquia de copy trading
Subcontas principais (parent) e seguidoras herdam o stpGroupId; as estratégias precisam identificar em qual lado estão rodando
As posições de copy trading da Bitget herdam o stpGroupId entre a conta do trader (principal) e seus seguidores. Uma estratégia rodando em uma conta principal que abre uma posição aciona ordens copiadas em todas as contas seguidoras vinculadas, ponderadas pela configuração de cada seguidor. Estratégias que não devem ser copiadas precisam rodar em uma conta que não seja de trader ou optar explicitamente por não participar no nível da posição. O impacto de uma conta principal de copy trading mal configurada é grande; o isolamento de subcontas e a definição de escopo de permissão por chave são os padrões corretos de contenção de danos.
05 · Escopo de chaves
Uma chave com escopo definido por estratégia, nunca uma chave mestra compartilhada entre estratégias
As chaves de API da Bitget possuem escopo por permissão (leitura, trade spot, trade de futuros, saques). As estratégias nunca devem precisar de permissão de saque; isole chaves com essa permissão em uma credencial separada e gerenciada manualmente fora do container runtime. Chaves exclusivas por estratégia, contendo apenas as permissões necessárias, limitam o impacto em caso de vazamento. A Bitget também suporta lista de permissões de IP (IP whitelisting) por chave; configure-a se a faixa de IP de saída do runtime for conhecida e estável na região selecionada.
06 · Divisão de conta demo
A conta demo compartilha a interface da V2, mas emite chaves e saldos separados
A Bitget disponibiliza a conta demo na mesma interface de endpoints da V2 de produção; a estrutura das requisições é idêntica, mas o conjunto de chaves, saldos e posições são isolados da produção. Uma falha silenciosa comum é enviar código validado em ambiente demo para produção sem alterar as chaves, ou vice-versa. Mantenha as credenciais de demo e produção em entradas separadas no TradingHost Secrets; nunca reutilize a mesma credencial entre ambientes.
Seção 06 · Indicado para
Indicado para
Os runtimes da TradingHost para a Bitget são ideais para:
- Desenvolvedores criando estratégias em IDEs de IA (Cursor, Claude Code)
- Traders sistemáticos de cripto
- Desenvolvedores quantitativos
- Usuários de CCXT e Hummingbot
- 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 possui afiliação com a Bitget.
Não. O código da sua estratégia se conecta à Bitget e envia instruções de acordo com 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 Bitget é fornecido pela própria Bitget. Você é responsável por sua conta na Bitget, permissões de API, credenciais e conformidade com os termos da corretora.
Não. A TradingHost é o cloud runtime onde o código da sua estratégia é executado. Não fornecemos sinais, modelos de previsão de IA ou bots prontos. Com a TradingHost, você escreve ou gera a estratégia por conta própria (geralmente usando Cursor ou Claude Code), mantém o código no seu GitHub e usa a TradingHost para executá-lo em produção. Produtos como o 3Commas e o Cryptohopper controlam a lógica da estratégia; a TradingHost apenas executa a sua estratégia.
A AWS e a DigitalOcean fornecem computação bruta. Você precisa gerenciar atualizações de sistema operacional, orquestração de containers, envio de logs, rotação de segredos, failover de região e monitoramento de uptime por conta própria. A TradingHost oferece um runtime gerenciado e desenvolvido especificamente para estratégias de trading: implantação nativa via GitHub, controle baseado em MCP a partir de IDEs de IA, além de interfaces nativas de logs e status de saúde (health). Se você prefere operar a infraestrutura por conta própria, a AWS atende bem. 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 framework runtime compatível com sua stack ou faça o deploy do seu próprio repositório.
Sim. A TradingHost suporta qualquer linguagem de programação que possa ser executada dentro de um container.
Sim. A CCXT expõe as interfaces de spot e perpétuos da Bitget por meio da classe unificada `bitget`. Como os endpoints de copy trading não são primitivas nativas da CCXT, esses fluxos devem ser executados diretamente na API V2 nativa da Bitget. Consulte o framework runtime da CCXT para ver o guia completo de configuração.
A TradingHost é neutra em relação às corretoras no nível do runtime: qualquer código capaz de se autenticar na Bitget pode rodar dentro de um container, incluindo estratégias hospedadas em uma conta principal de copy trading da Bitget. O ponto de atenção no desenvolvimento do seu código é que qualquer posição aberta pela sua estratégia acionará ordens copiadas em todas as contas seguidoras vinculadas, ponderadas pela configuração de cada uma. Execute estratégias elegíveis para cópia em uma subconta separada de suas estratégias privadas e isole as chaves de API por estratégia para limitar o impacto de eventuais falhas.
Sim, caso seu projeto seja estruturado dessa forma. Você pode executar múltiplos processos ou serviços de estratégia dentro de um único runtime, ou separá-los em runtimes diferentes para garantir isolamento e clareza operacional. Consulte a página de runtimes da TradingHost para entender o modelo multiestratégia.
O caminho mais rápido é fazer um fork de um framework runtime da TradingHost: CCXT ou Hummingbot para obter um projeto pronto para implantação. Ou conecte seu próprio repositório de estratégia do GitHub. 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 de repositório do GitHub, segredos de ambiente ou pelo seu próprio processo homologado de gerenciamento de segredos. A TradingHost não precisa da custódia de sua chave de API, segredo ou senha (passphrase). Consulte a seção de segredos da plataforma para entender o modelo completo de tratamento.
Não. As estratégias nunca devem precisar de permissões de saque. Utilize permissões com escopo definido (leitura, trade spot, trade de futuros) e lista de permissões de IP (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 detalhes completos.
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 simples git push para a sua branch principal (main) aciona uma nova implantação.
O runtime detecta a falha e expõe os logs e as informações de saúde relevantes. 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 sendo responsável pelo tratamento seguro de erros, proteção contra ordens duplicadas e controles de risco. Consulte a seção de observabilidade para conhecer a interface de logs e status de saúde.
O erro 40009 da Bitget significa que a assinatura enviada pela sua estratégia não corresponde ao HMAC-SHA256 esperado de timestamp + method + requestPath + body, assinado com a sua chave secreta. As causas comuns são a ausência ou incorreção do cabeçalho ACCESS-PASSPHRASE, o ACCESS-TIMESTAMP fora da janela de tolerância de 30 segundos, a assinatura com a chave errada (teste vs. produção) ou a assinatura de um corpo de requisição canônico incorreto (espaços extras, reordenação de chaves). Use um SDK consolidado ou faça testes unitários do fluxo de assinatura comparando com a referência de assinatura da Bitget. Consulte a seção de Notas operacionais acima para obter as orientações completas.
O TradingHost é executado nas regiões EU e US-East. Escolha a região mais próxima do matching engine de que sua estratégia depende. Consulte a página de regiões para obter detalhes de roteamento e proximidade.
Não. A TradingHost é focada em execução (runtime) e implantação em produção. O backtesting deve ser feito na sua própria estrutura de pesquisa, framework ou no AlgoBuilder.