Conexão com APIs de Criptomoedas para Arbitragem: WebSockets, Limites de Taxa e Sync do Livro de Ordens

No criptoarbitragem, a diferença de preço entre dois exchanges geralmente dura entre algumas centenas de milésimos de segundo e alguns segundos. Sua estratégia pode ser inteligente, seu capital pode estar disponível e as taxas podem ser negociadas para serem mais baixas. Se a sua conexão com os exchanges for lenta, desatualizada ou tiver problemas com a limitação de velocidade, a diferença já estará eliminada antes que sua ordem seja finalizada. Para um bot que opera entre vários exchanges, A conexão API é a estratégia. O resto fica por cima disso.

Este guia aborda os aspectos de infraestrutura que a maioria dos tutoriais de arbitragem deixa de mencionar: como conectar-se adequadamente às APIs das exchanges de criptomoedas. Isso significa qual interface usar para o que, como manter um livro de ordens local que corresponda à do exchange, como manter dentro dos limites de taxa, como bloquear as chaves de API e como permanecer conectado 24 horas por dia, todos os dias. Foi escrito para operadores que executam ou planejam executar um bot de arbitragem em várias exchanges. Se você ainda estiver escolhendo uma estratégia, comece com o nosso Guia do robô de arbitragem de criptomoedas entre exchanges e volte aqui quando for a hora de conectar as coisas.

A anatomia de uma conexão de API de arbitragem

Uma configuração de intercâmbio entre exchanges não é uma única conexão, mas várias, cada uma com a sua própria função. Para cada troca em que você negocia, você normalmente mantém:

• Um fluxo de dados de mercado público (WebSocket), que transmite atualizações do livro de ordens e executa transações no momento em que elas ocorrem.
• Um canal de entrada de pedidos (REST ou uma API de pedidos WebSocket/FIX, onde a plataforma oferece uma opção de troca) para colocar e cancelar pedidos.
• Um fluxo de dados de usuário privado (WebSocket) que informa sobre preenchimentos, alterações no status da ordem e atualizações do saldo sem que você precise perguntar.
• Chamadas ocasionais ao REST para coisas que não precisam ser rápidas: instantâneos do livro de pedidos, informações sobre a troca (tamanho das ticks, lot size), níveis de taxas e saldos para reconciliação.

Os iniciantes cometem muitas vezes dois erros aqui. O primeiro é consultar preços no REST em vez de assinar um stream. O segundo é verificar o status da ordem consultando o REST em vez de ouvir o stream privado. Ambos consomem o seu orçamento de taxa-limite e adicionam centenas de milésimos de segundo de atraso que nunca mais se recuperam.

REST vs WebSocket vs FIX: qual interface para qual tarefa

A maioria das principais exchanges oferece APIs REST e fluxos WebSocket. Um grupo menor de grandes plataformas também oferece o FIX ou uma API dedicada de entrada de ordens com baixa latência, geralmente para planos de tarifas mais elevados ou contas institucionais. Cada uma é boa em coisas diferentes:

Interface	Melhor para	Fraqueza	Use-o no arbitragem para
REST	Tarefas de solicitação/resposta, instantâneos e dados de conta	Um único deslocamento por pedido; cada chamada custa o peso da tarifa limite.	Visuais instantâneos do livro de pedidos, informações de troca, saldos e entrada de pedidos quando não existe algo mais rápido
WebSocket público	Preços de streaming sem votação	Você deve gerenciar os números de sequência, reconexões e recadincamentos por conta própria.	Livros de ordens e transações em tempo real: a base de dados de entrada para todos os sinais
WebSocket privado	Atualizações push para seus próprios pedidos e saldos	Necessita de um key de acesso ou de login com autenticação digital e expira se você não mantiver a conexão ativa.	Fills e status da ordem; o gatilho para a cobertura da segunda etapa
API de ordem WebSocket	Fazer pedidos através de uma conexão aberta	Não em todas as exchanges; ainda está sujeita a limites de taxa	Efetuação de pedidos com menor latência: sem novo pedido HTTPS por pedido
CORRIGIR	Inserção e exclusão de cópias de entrada institucional	Disponibilidade limitada, onboarding e níveis mínimos	Volume sério em locais que o suportam

Uma regra simples: os dados são enviados por fluxos de dados, as decisões são tomadas localmente e os pedidos são enviados pelo canal mais rápido oferecido pela bolsa. O REST é para configuração e reconciliação, não para qualquer coisa no caminho principal. Se você vier do mercado de câmbio, os tradeoffs são muito semelhantes aos encontrados no Pontes entre o FIX API e o MT4: O protocolo define o limite de latência.

Manter um livro de pedidos local que seja realmente correto

É aqui que a maioria dos bots construídos por usuários domésticos falha silenciosamente. Uma exchange não envia o livro completo de ordens em cada atualização. Ela envia Mudanças: “O nível de preço 64.210,5 na parte de compra agora é de 0,82 BTC”. Você mantém o livro completo por conta própria. Se você perder uma única mudança, seu livro se distanciará da realidade. Seu bot então “enxerga” uma diferença que não existe e dispara ordens a preços que nunca existiram.

O padrão padrão, documentado em diferentes formas pelas maiores exchanges, é o seguinte:

1. Primeiro, inscreva-se no fluxo de diferenças e buffer as mensagens recebidas.
2. Obter uma instantânea REST de o livro de pedidos. Ele contém um identificador de sequência ou atualização.
3. Desative atualizações com buffer mais antigas que a snapshot, Depois disso, aplique o resto na ordem correta.
4. Verifique a continuidade de cada mensagem. O primeiro número de sequência de cada atualização deve seguir o último que você aplicou.
5. Em qualquer situação de falha, jogue o livro fora e recarregue o dispositivo. do passo 1. Nunca “reparar” um livro com uma lacuna conhecida.

Outras duas verificações de normalidade valem a pena acrescentar. Primeiro, uma temporizador de permanência: se um par de líquidos não enviou nada durante, digamos, dois segundos, considere o livro como não confiável, pois o fluxo pode estar meio morto sem ter sido fechado. Em segundo lugar, Verificação de livros cruzados: uma oferta mais alta do que a máxima oferecida em um determinado leilão quase sempre significa que seu livro está vendido abaixo do valor de mercado, não que você tenha encontrado dinheiro grátis. Alguns leilões também publicam um checksum dos preços mais altos. Se o seu tiver, compare com ele.

Limites de taxa: o orçamento por trás de cada pedido

Cada exchange limita o quanto você pode acessar sua API. Os detalhes variam, mas a maioria combina várias camadas:

• Solicite o peso por minuto, Os endpoints pesados, como uma instantânea do livro de pedidos detalhado, têm um peso maior do que os de menor porte.
• Limites de número de pedidos por segundo e por dia, geralmente contados por conta, em vez de por IP.
• Limites do WebSocket: mensagens por segundo que você pode enviar, conexões por IP e fluxos por conexão.

Passar do limite não é apenas uma mensagem de erro. Violações repetidas podem resultar em suspensões temporárias de IP, que geralmente começam com minutos e podem ser mais longas para usuários recorrentes. Isso pode fazer com que seu bot fique offline enquanto você estiver em uma posição ativa. Portanto, considere os limites como uma orçamento Você planeja com antecedência, não constrói uma parede apenas por bater nela.

Regras práticas que mantêm você dentro do orçamento:

• Leia os cabeçalhos de limite. Muitas exchanges retornam o peso utilizado em cada cabeçalho de resposta. Observe isso e reduza a velocidade antes de atingir o limite, em vez de depois.
• Mantenha uma reserva para cancelamentos. O pior momento para limitar a taxa é quando você precisa cancelar uma ordem antiga ou proteger uma posição aberta. Guarde pelo menos 20-30% do orçamento para isso.
• Use o fluxo privado para informar o status. Nunca faça uma pergunta repetida como “Está o meu pedido a ser processado?” em loop.
• Não exceda os limites com rotação de IPs ou com contas adicionais. Isto geralmente viola os termos de uso do exchange e pode resultar na suspensão de todas as contas envolvidas. Solicitar ao exchange limites mais elevados ou um nível superior é o caminho legítimo.

Autenticação, sincronização de relógio e segurança da chave de API

Os endpoints privados geralmente são assinados com HMAC (alguns exchanges também suportam chaves Ed25519 ou RSA). A assinatura inclui um timestamp e o exchange rejeita pedidos cujo timestamp esteja fora de um intervalo curto, geralmente de alguns segundos. Isso faz com que sincronização de relógios parte de sua infraestrutura de trading: execute o NTP ou o chrony no seu servidor e observe o desvio do relógio. Um relógio que flutua produz uma série de rejeições com o “timestamp fora do recvWindow”, exatamente quando o mercado está mais ativo e seu servidor está sob pressão.

As chaves API são as chaves do seu capital, portanto, proteja-as:

• Só negociação, retirada de fundos não disponível. Um bot de arbitragem nunca precisa de permissão para levantamento nos seus chaves de negociação. Movimente fundos entre exchanges manualmente ou por meio de um processo separado e estritamente controlado.
• Listagem de IPs na permissão. Conecte todas as chaves ao IP estático do seu servidor. Uma chave vazada que funcione apenas a partir do seu VPS é muito menos perigosa.
• Um chaveiro por bot, por exchange, idealmente por sub-conta. Se algo der errado, você pode revogar uma chave sem interromper tudo.
• Segredos fora do código e registros. Use variáveis de ambiente ou um gerenciador de secrets e certifique-se de que os logs de erros nunca imprimam a chave ou a assinatura inteiras.
• Rotar de acordo com um horário e imediatamente após qualquer mudança de pessoal ou suspeita de vazamento de informações.

Latência: onde os milésimos de segundo realmente se acumulam

Para duas trocas, o tempo total de reação é aproximadamente: entrega de dados de mercado da primeira troca + processamento do seu pedido + viagem para a segunda troca + processamento da ordem. Em uma conexão de internet doméstica, uma viagem de ida e volta por todo o continente pode facilmente ser de 150 a 250 ms. Em um VPS na mesma região de nuvem onde o mecanismo de matching da primeira troca funciona, a parte de rede pode cair para alguns milésimos de segundo.

É por isso que a localização do servidor é mais importante do que truques de código. Muitas grandes exchanges de criptomoedas executam seus mecanismos de correspondência em grandes regiões de nuvem (Tokio é uma das mais comuns), e algumas publicam a região de hospedagem. Outras podem ser encontradas através de testes de ping de centros de dados candidatos. Escolha uma localização próxima: ambos os locais dos seus principais pares. Se eles estiverem em diferentes continentes, você terá de pagar a diferença em uma das duas maneiras, e sua estratégia deve permitir isso. Guia de configuração de VPS de baixa latência abrange a medição da latência e a escolha de um data center em detalhes. O mesmo método funciona para os locais de negociação de criptomoedas.

No seu próprio processo, os principais ganhos vêm da análise de mensagens sem grandes encargos, da atualização apenas dos níveis de preço que mudaram e da manutenção dos chaves e conexões de assinatura de ordens. Um truque como o TCP_NODELAY vale a pena ter. Um livro correto e um caminho de rede curto valem muito mais.

Manter a conexão 24/7

O Crypto nunca fecha, mas as conexões sim. Prepare-se para esses eventos normais, não para exceções raras:

• Desconexões programadas. Algumas exchanges fecham todas as conexões WebSocket após um período de tempo fixo, geralmente 24 horas. Abra uma nova conexão antes que a antiga expire e faça a transição suavemente.
• Batimentos cardíacos. Responder aos frames de ping e enviar seus próprios ping quando a troca deles solicitar. As chaves de escuta de stream privado geralmente precisam de uma chamada de keep-alive de vez em quando.
• Vários períodos de manutenção e atualizações do API. Assine os anúncios de APIs de cada exchange. Os endpoints ficam obsoletos, as ponderações mudam e novas versões substituem as antigas.
• Interrupções parciais. Uma troca pode continuar a efetuar transações enquanto a entrada da ordem falha. Se a ordem ficar sem movimento, não assuma que foi rejeitada. Verifique o fluxo privado ou faça uma consulta de status antes de tentar novamente, pois isso pode resultar em uma posição dupla.

O design mais seguro é um máquina de estados do kill-switch. Qualquer fluxo perdido, livro antigo ou relógio desatualizado faz com que o bot passe para a posição “sem novas posições”. Ele nivelará ou protegerá qualquer posição aberta, e depois reconstruirá de forma limpa.

Normalizar várias trocas em uma única visão

Cada exchange descreve o mesmo mercado de forma diferente. Um escreve BTCUSDT, outro BTC-USDT, e outro ainda XBT/USDT. Os tamanhos de ticks, valores mínimos de negociação, lotes e planos de taxas também diferem. Antes que seu bot possa comparar preços entre as diferentes exchanges, ele precisa de uma camada de normalização que:

• mapa os símbolos de cada exchange para um ID interno do instrumento;
• redimensiona os preços para o tamanho de tick de cada local e as quantidades para o seu lote, na direção que o mantém conservador;
• verifica os tamanhos mínimos da encomenda, para que a segunda etapa de um arbitragem nunca seja rejeitada por ser demasiado pequena;
• aplica-se o seu as taxas reais de comprador/vendedor por local. A diferença que importa é a diferença após os encargos, conforme explicado na nossa análise. Os principais tipos de arbitragem de criptomoedas.

Carregue esses dados de referência do endpoint de informações de cada exchange no início da inicialização e atualize-os a cada algumas horas. Os preços, os tamanhos de ticks e os limites variam com mais frequência do que você imagina.

Passo a passo: conectar um novo exchange ao seu setup de arbitragem

1. Crie uma conta secundária dedicada e uma chave API com apenas permissão para negociação, retirada de fundos desativada e a sua IP do servidor listada na lista de permissões.
2. Medir a latência de seu candidato VPS para os endpoints REST e WebSocket do exchange, e coloque o servidor próximo ao motor de correspondência.
3. Sincronizar o relógio (NTP/chrony) e confirme que o desvio permanece dentro da janela de assinatura do sistema de troca.
4. Carregar informações da troca: símbolos, tamanhos de ticks, lotes, valores mínimos e sua faixa de taxas. Mapeie-os na sua camada de normalização.
5. Construa o seu livro de pedidos local Com o método snapshot + diff, com detecção de gap, temporizador de inatividade e verificação de livros cruzados.
6. Conectar o fluxo de dados de utilizador privado para cargas e saldos, com manutenção de status ativo e reconexão automática.
7. Defina o seu orçamento para limite de tarifas, com uma quota reservada para cancelamentos e hedges, e acompanha o peso dos cabeçalhos.
8. Teste com tamanho mínimo, Compare a sua carteira local com a interface de troca e, só então, aumente o tamanho da posição.

Se você preferir não construir e manter tudo isso sozinho, uma plataforma pronta já gerencia as sessões de troca, os livros e a rotulagem de pedidos. Guia para adicionar uma sessão de troca de criptomoedas exibe como isso funciona na HFT Arbitrage Platform, onde você insere a chave de API e a plataforma se encarrega do resto.

Perguntas frequentes

Preciso de WebSockets para o criptoarbitragem ou é suficiente o REST?

Para qualquer arbitragem que dependa da velocidade, você precisa de WebSockets para dados de mercado. Verificar preços através do REST é mais lento, gasta todo o seu orçamento para limite de taxa e deixa de acompanhar as mudanças entre as pesquisas. O REST ainda é útil para snapshots, dados de conta e, em alguns exchanges, para entrada de ordens.

Que permissões de API um bot de arbitragem deve ter?

Leia e negocie apenas. Desative as retiradas em todas as teclas que o bot utiliza, vincule a tecla ao endereço IP do seu servidor e use uma chave separada, idealmente uma conta secundária separada, para cada bot e para cada troca.

Por que meu bot vê oportunidades de arbitragem que não são reais?

Normalmente, isso acontece porque o livro de ordens local não está sincronizado: uma atualização perdida, um fluxo que ficou silencioso ou uma snapshot aplicada na ordem errada. Adicione a detecção de gap de sequência, um temporizador de estabilidade e uma verificação de livro cruzado e restaure a sincronização sempre que um deles detectar uma falha. Além disso, confirme se a taxa de spread ainda está válida após os seus custos reais.

O que acontece se eu ultrapassar o limite de taxa de API de um exchange?

Primeiro você recebe solicitações rejeitadas, geralmente com um erro HTTP 429 ou um código semelhante. Se você continuar excedendo o limite, muitas exchanges escalam para banimentos temporários de IPs. Isso é perigoso quando você tem uma posição aberta para cobertura, portanto mantenha um estoque de recursos para cancelamentos e coberturas.

Onde devo colocar meu servidor para arbitragem de câmbio de criptomoedas?

Quanto mais próximo possível dos mecanismos de correspondência dos exchanges com os quais você negocia, geralmente na mesma região de nuvem. Medir o ping a partir de locais candidatos em vez de adivinhar. Quando os dois locais estiverem distantes, coloque o servidor próximo ao local onde a velocidade é mais importante para sua estratégia.

É permitido usar várias chaves API ou IPs para obter mais solicitações?

As exchanges definem limites de taxa de propósito e, para burlá-los, geralmente utilizam IPs ou contas adicionais, o que geralmente viola os termos de uso e pode resultar em banimento da conta. Se você precisar de mais capacidade de processamento, pergunte à exchange sobre limites mais elevados, níveis VIP ou APIs institucionais.

Sobre o autor