Runtime nativo de IA para estratégias de trading na Binance
Desenvolva no Cursor, Claude Code ou em qualquer IDE de IA. Faça o deploy a partir do GitHub em um runtime gerenciado na nuvem 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
- Binance
- Tipo de plataforma
- Exchange de cripto
- Classe de ativos
- Cripto
- Produtos suportados
- Spot, futuros USD-M, futuros COIN-M, opções, margem cruzada e isolada
- Modelo de runtime
- Runtime de estratégia em container
- Origem do deploy
- GitHub
- Linguagens
- Qualquer linguagem que rode em container
- Integrações comuns
- Código de API nativo, CCXT, Freqtrade, 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, health checks, seleção de região, controle MCP
- Papel de Binance
- Conta na exchange, acesso à API, acesso ao mercado, ambiente de execução
- Afiliação
- A TradingHost é independente e não possui afiliação com a Binance
Seção 02 · O que Binance oferece
O que Binance oferece
A Binance oferece negociação de spot, futuros USD-M e COIN-M, opções e margem cruzada/isolada via APIs REST e WebSocket. As estratégias se autenticam com chaves de API assinadas com HMAC-SHA256 e escopos de permissão específicos. Tanto o mercado spot quanto o de futuros possuem testnets públicas separadas. Os detalhes dos endpoints mudam com o tempo. A estrutura geral é estável; os pesos exatos de limite de requisições (rate limits), faixas de taxas e listas de símbolos estão disponíveis na documentação da Binance.
Mercados e padrões de estratégia
- Estratégias de futuros perpétuos USD-M
- Futuros inversos COIN-M e contratos trimestrais
- Estratégias de opções de BTC e ETH
- Arbitragem de taxa de financiamento (funding rate) e basis trading em perpétuos
- Deploys multiestratégia isolados por subcontas
- Estratégias de spot e margem (cruzada ou isolada)
- Consumidores de WebSocket User Data Stream
- Deploys validados nas Testnets de Spot e Futuros
Superfície da API
- Superfícies de produtos
- Spot, futuros USD-M (perpétuos e de entrega), futuros COIN-M, opções, margem cruzada e isolada, além de hierarquias de subcontas. Cada um possui uma testnet pública para que a estratégia possa ser validada na mesma estrutura de API, sem expor capital real.
- Métodos de conexão
- REST para envio de ordens e consultas de conta. Streams de WebSocket para dados de mercado e profundidade (order book) em tempo real. WebSocket User Data Streams para eventos de conta, saldo e ordens. Uma API WebSocket para requisição/resposta opera em paralelo com a interface REST.
- Autenticação
- Chave de API e segredo por estratégia. Requisições privadas são assinadas com HMAC-SHA256. As permissões são limitadas por chave (leitura, trade spot, trade futuros, saques) com lista de IPs permitidos (IP whitelisting) opcional. As estratégias nunca devem precisar de permissão de saque.
Para detalhes específicos, consulte Binance
Endpoints específicos, pesos de limite de requisições, listas de símbolos, faixas de taxas e histórico de versões estão na documentação da Binance. Considere-os como a fonte oficial de verdade.
Seção 03 · Desenvolva com IA
Desenvolva sua estratégia para Binance 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 da Binance
Controle direto sobre comportamentos específicos da Binance, dados de conta e lógica de execução de ordens.
Freqtrade ou Hummingbot
Deploys baseados em frameworks, utilizando suas estruturas de estratégia e modelos de configuração.
Conector personalizado
Seu próprio motor de trading interno ou integração proprietária com a Binance.
Suporte de frameworks para produtos Binance
A cobertura varia de acordo com o framework. O CCXT abrange a maior parte da API da Binance; o Freqtrade e o Hummingbot cobrem spot e perpétuos USD-M; o acesso direto pela API nativa da Binance cobre tudo o que a exchange oferece, incluindo opções.
✓ 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 Binance fornece a exchange e o acesso à API. A TradingHost fornece o ambiente de produção onde sua estratégia conectada à Binance é 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 à Binance.
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 a TradingHost para o seu repositório de estratégia existente ou faça um fork de um runtime de framework da TradingHost (CCXT, Freqtrade 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 que sua estratégia precisa (chaves de API da Binance, etc.) e faça o deploy. A TradingHost constrói seu container 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 Binance
Problemas práticos que surgem ao rodar uma estratégia para a Binance em um runtime de nuvem baseado em containers — detalhes que não estão na documentação da Binance nem nos READMEs dos frameworks. Cada ponto abaixo foi citado ou parafraseado da própria documentação da Binance; as orientações de deploy vêm da nossa experiência rodando essas estratégias na TradingHost.
01 · Error -2015
"Invalid API-key, IP, or permissions for action"
A falha de autenticação mais comum na Binance. Significa que sua chave existe, mas o IP da requisição não está na lista de permissões da chave, ou a chave não tem permissão para o endpoint (por exemplo, uma chave spot acessando um endpoint de futuros, ou uma chave de leitura tentando enviar uma ordem). Na TradingHost, os IPs de saída (egress) dos containers são fixados por região. Adicione à lista de permissões a faixa de IPs de saída publicada para a região selecionada, em vez de um único IP, pois os containers podem ser reiniciados em outros nós.
02 · Escopo de saque
A permissão de saque exige lista de IPs permitidos
Binance: "Adding IP access restrictions is mandatory to enable withdrawal permission." Runtimes em nuvem não possuem IPs de saída únicos e estáticos, o que torna difícil operar chaves com escopo de saque a partir de containers. O padrão correto: não ative o escopo de saque nas chaves das estratégias. As estratégias não precisam disso. Mantenha os saques em uma chave separada, gerenciada manualmente em um host com IP fixo.
03 · Fallback somente leitura
Chaves novas geradas pelo sistema são apenas de leitura sem restrição de IP
A partir de 2023-01-30, a Binance determina: "the system-generated API Key's permission can only be set to [Enable Reading] if your IP is unrestricted." Se você gerar uma chave nova para uma estratégia da TradingHost sem configurar a whitelist, ela não poderá operar, apenas ler. Você deve incluir na whitelist a faixa de IPs de saída (egress range) do runtime para a sua região ou usar uma chave Ed25519 / RSA gerada por você mesmo, o que contorna esse controle de segurança padrão.
04 · Escopo de chaves
Uma chave com escopo por estratégia, não uma chave mestra compartilhada entre estratégias
A Binance oferece quatro tipos de segurança de endpoint: NONE (dados públicos de mercado), TRADE (ordens), USER_DATA (estado da conta) e USER_STREAM (assinatura do User Data Stream). A Binance determina: "you can have an API key with TRADE permission for trading, while using a separate API key with USER_DATA permission to monitor your order status." Chaves específicas por estratégia, contendo apenas os escopos necessários para aquela estratégia, limitam o raio de impacto em caso de vazamento de credenciais.
05 · recvWindow
Padrão de 5000 ms; desvio de relógio causa o erro -1021 INVALID_TIMESTAMP
A Binance determina: "If recvWindow is not sent, it defaults to 5000 milliseconds. Maximum recvWindow is 60000 milliseconds." E também: "It is recommended to use a small recvWindow of 5000 or less!" Containers com desvio de relógio maior que o recvWindow são rejeitados com o erro -1021. Os runtimes da TradingHost são sincronizados via NTP, portanto o padrão de 5000 funciona perfeitamente. Não aumente o recvWindow a menos que esteja enfrentando rejeições reais, e nunca use isso como substituto para corrigir a sincronização de horário.
06 · Divisão de Testnet
Spot Testnet e Futures Testnet são ambientes separados
testnet.binance.vision (spot) e testnet.binancefuture.com (futuros) emitem chaves separadas, mantêm saldos separados e atendem a endpoints separados. Uma falha de autenticação silenciosa comum é configurar uma estratégia de futuros com chaves da testnet spot, ou enviar código validado na testnet para produção sem trocar o conjunto de chaves. Mantenha os segredos de testnet e produção em entradas separadas no TradingHost Secrets; nunca reutilize chaves entre ambientes.
Seção 06 · Indicado para
Indicado para
Os runtimes da TradingHost para a Binance 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, Freqtrade 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 Binance.
Não. O código da sua estratégia se conecta à Binance 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 Binance é fornecido pela própria Binance. Você é responsável por sua conta da Binance, permissões de API, credenciais e conformidade com os termos da Binance.
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 bots prontos. Com a TradingHost, você mesmo escreve ou gera a estratégia (geralmente usando Cursor ou Claude Code), mantém o código no GitHub e usa a TradingHost para executá-lo em produção. Produtos como 3Commas, Cryptohopper e similares são donos da lógica da estratégia; a TradingHost 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 projetado especificamente para estratégias de trading: implantação nativa do GitHub, controle via MCP a partir de IDEs de IA, além de interfaces prontas para logs e status de saúde do sistema. Se você prefere 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; basta escolher o runtime de framework compatível com a sua stack ou implantar seu próprio repositório.
Sim. A TradingHost suporta qualquer linguagem que possa ser executada dentro de um container.
Sim. Estratégias da Binance baseadas em CCXT rodam na TradingHost. Consulte o runtime do framework CCXT para ver o processo completo de configuração.
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 maior 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 runtime de framework da TradingHost: CCXT, Freqtrade ou Hummingbot para ter 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 aprovado de gerenciamento de segredos. A TradingHost não precisa da custódia da sua chave de API e do seu segredo. 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. Use permissões com escopo limitado (leitura, trade spot, trade de futuros) e whitelist de IP sempre que aplicável.
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 operações. 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 sua branch principal 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 ainda é 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 saúde.
O erro -2015 "Invalid API-key, IP, or permissions for action" geralmente significa que o IP da requisição não está na whitelist da sua chave, ou que a chave não tem permissão para o endpoint (por exemplo, uma chave spot tentando acessar um endpoint de futuros). Na TradingHost, inclua na whitelist a faixa de IPs de saída (egress range) publicada para a região selecionada, em vez de um único IP, já que os containers podem ser realocados. Consulte a seção de Notas operacionais acima para obter a orientação completa.
O TradingHost é executado 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 ver detalhes de roteamento e proximidade.
Não. A TradingHost é focada em runtime de produção e implantação. O backtesting pertence à sua stack de pesquisa, framework ou AlgoBuilder.