Trading de criptomoedas de baixa latência: localização dos servidores das exchanges, latência real de API e onde hospedar seu bot Sábado, 7 de Novembro de 2026 – Posted in: Arbitrage Software, cryptoarbitrage software

O que baixa latência significa no trading de criptomoedas

Resposta curta: trading de criptomoedas de baixa latência significa encurtar o tempo entre uma mudança de preço em uma exchange e a chegada da sua ordem ao motor de matching dessa exchange. A maior parte desse tempo é distância física: as principais exchanges executam seus motores em regiões de nuvem específicas, principalmente Tóquio, Singapura e Hong Kong, e um bot hospedado em outro continente fica de 150 a 250 milissegundos atrás de um bot hospedado ao lado do motor. A segunda maior parte é overhead evitável: conexões frias, polling via REST, um relógio mal sincronizado e código lento.

No forex, a latência é uma história sobre alguns data centers bem conhecidos em Londres, Nova York e Tóquio, e sobre as pontes de liquidez das corretoras. Nas criptomoedas o cenário é diferente. Não existe um campus compartilhado de exchanges: cada exchange escolhe sua própria região de nuvem, a maioria roda em infraestrutura de nuvem pública e suas APIs normalmente ficam atrás de redes de distribuição de conteúdo (CDNs) que fazem a exchange parecer próxima quando não está. Isso torna a medição ao mesmo tempo mais fácil (você pode alugar um servidor na mesma região de nuvem pelo preço de um jantar) e mais enganosa (os testes óbvios medem a coisa errada).

O quanto a latência importa depende da estratégia:

Se sua vantagem vem de diferenças estruturais lentas, como a arbitragem de taxa de financiamento ou transferências limitadas por taxas de saque e tempos de confirmação da rede, você não precisa de nada deste guia além de um servidor estável. Se você opera diferenças de preço entre livros de ofertas, é a diferença entre ser executado e correr atrás do preço.

O orçamento de latência: para onde vão os milissegundos

"Latência" não é um único número. Uma ordem que reage a um movimento do mercado passa por uma cadeia de etapas, e cada etapa adiciona tempo. Pensar em termos de orçamento mostra quais partes você pode mudar e quais não pode.

O padrão é claro: os dois itens que você controla e que são medidos em dezenas ou centenas de milissegundos são onde está o seu servidor e se suas conexões estão aquecidas. Todo o resto pertence à exchange ou é pequeno quando o software é bem escrito. Por isso o restante deste guia foca em localização e medição.

Onde as exchanges de criptomoedas executam seus motores de matching

As exchanges raramente publicam a localização exata de seus motores de matching, mas a maioria roda em nuvem pública, e a região pode ser deduzida a partir de medições de latência feitas de muitas regiões de nuvem. Medições independentes publicadas por terceiros em 2026 concordam sobre a maioria das grandes plataformas. A tabela resume as regiões relatadas publicamente. Use-a como ponto de partida para seus próprios testes, não como garantia: as exchanges migram (a BitMEX, por exemplo, teria transferido seu motor de Dublin para Tóquio em 2025).

Daí seguem duas conclusões práticas. Primeiro, Tóquio é o mais próximo que o mercado cripto tem de um centro de trading central: um servidor lá fica a poucos milissegundos da Binance e de várias outras grandes plataformas, a cerca de 25 ms (ida) de Hong Kong e a cerca de 35 ms (ida) de Singapura. Segundo, qualquer estratégia que combine uma exchange asiática com a Coinbase ou uma plataforma europeia tem um piso físico de 70 a 120 ms (ida) entre os dois motores, não importa o que você faça com seu próprio servidor.

Hospedar um servidor em determinado país não muda quais exchanges você tem permissão para usar. Siga os termos de serviço de cada exchange e as regras da sua própria jurisdição; nunca use servidores ou VPNs para contornar restrições geográficas.

A armadilha da CDN: por que o ping engana

O erro mais comum é medir a latência com ping ou pelo tempo para abrir uma conexão TCP com o nome de host da API. Quase todas as grandes exchanges colocam seus endpoints públicos REST e WebSocket atrás de uma CDN ou de um balanceador de carga em nuvem com pontos de presença no mundo todo. Quando você se conecta a api.binance.com a partir da Europa ou da América do Norte, o servidor que responde ao seu handshake TCP é um nó de borda em uma cidade próxima, não o motor de matching em Tóquio. O handshake leva alguns milissegundos; depois a borda encaminha sua requisição pelo backbone do provedor até a origem real, e é aí que o tempo se perde.

Assim, um ping de 5 ms para o nome de host de uma exchange pode coexistir com um tempo real de requisição de 150 ms. Os únicos números que significam algo são os que incluem a viagem até a origem: o tempo até o primeiro byte de uma resposta real da API em uma conexão já aberta, o atraso entre o timestamp do evento da própria exchange e o seu horário de recebimento no WebSocket, e o tempo entre o envio de uma ordem e o recebimento da sua confirmação.

Medido pela BJF Trading Group em 7 de novembro de 2026 a partir de um servidor web em Montreal (Leaseweb), endpoints públicos de horário, duas execuções de uma requisição fria mais 20 aquecidas por exchange.

O que medimos a partir de um servidor em Montreal

Para mostrar o efeito com números reais em vez de promessas de fornecedores, executamos uma pequena sonda a partir do servidor web que hospeda este site, em Montreal. Para oito exchanges, ela abriu uma conexão, enviou uma requisição (fria) e depois mais 20 requisições pela mesma conexão keep-alive (aquecidas), a quatro requisições por segundo, e repetiu toda a execução duas vezes. O endpoint foi a chamada pública de horário do servidor de cada exchange, que quase não faz processamento, então o resultado fica próximo do tempo puro de transporte mais gateway.

Este pequeno teste traz quatro lições:

• O tempo de conexão não significa nada atrás de uma CDN. A OKX respondeu ao handshake TCP em 3 a 4 ms, mas toda requisição real levou cerca de 170 ms, porque o trabalho acontece em Hong Kong.
• O ranking segue a geografia. A Coinbase (costa leste dos EUA) é a mais rápida a partir de Montreal, a Kraken (Europa) vem em segundo, e as exchanges asiáticas se concentram entre 150 e 225 ms. A partir de Tóquio, a ordem seria inversa.
• Conexões frias são caras. Sem uma borda por perto, cada ciclo do handshake atravessa o Pacífico: a primeira requisição para a Gate.io levou cerca de 0.7 segundo, as seguintes cerca de 0.18 segundo. Um bot que abre uma nova conexão quando vê um sinal já perdeu.
• As caudas importam. A mediana da Bybit foi de 225 ms, mas uma em cada dez requisições levou mais de 400 ms. Uma perna de arbitragem é tão rápida quanto seus casos lentos, então sempre olhe para o p90 e o p99, não só para a mediana.

Esses números descrevem um servidor web em uma tarde, não uma configuração de trading, e incluem o processamento no gateway de cada exchange. Não são um ranking de exchanges. O objetivo é mostrar o tamanho dos efeitos: geografia e gerenciamento de conexões respondem por mais de 90% do atraso que um bot distante sofre.

Passo a passo: como medir corretamente a latência das exchanges

Você consegue reproduzir uma medição significativa a partir de qualquer servidor em uma hora. O método abaixo é o que recomendamos antes de escolher uma região de hospedagem ou após qualquer mudança na sua infraestrutura.

Para o passo 2, o simples curl é suficiente para começar. Repetir a URL faz o curl reutilizar uma conexão; a primeira linha é a requisição fria, as demais são aquecidas:

curl -s –rate 4/s -w "%{num_connects} %{time_connect} %{time_starttransfer}\n" -o /dev/null URL -o /dev/null URL -o /dev/null URL

Para os passos 4 e 5 você precisa de algumas linhas de código na linguagem que seu bot usa, porque a medição deve passar pela mesma biblioteca cliente, pelo mesmo parser JSON e pelas mesmas configurações de conexão do trading real. Um número produzido por outra ferramenta fala sobre aquela ferramenta.

Dados de mercado via WebSocket e sincronização do relógio

Para qualquer coisa sensível ao tempo, os dados de mercado devem vir de streams WebSocket, não de polling via REST. Um loop de polling que solicita o livro de ofertas a cada 200 ms adiciona em média 100 ms de espera antes mesmo de ver uma mudança, além do tempo da requisição, e consome o limite de requisições de que você precisa para as ordens. Um stream WebSocket envia cada atualização assim que a exchange a publica. Os detalhes de streams, livros de ofertas locais e verificação de sequência estão no nosso guia sobre como conectar às APIs de exchanges de criptomoedas para arbitragem; aqui o foco é o tempo.

Medindo o atraso do feed

A maioria das mensagens WebSocket das exchanges traz um timestamp definido pela exchange: um horário de evento, de trade ou de mensagem, geralmente em milissegundos. Subtraia-o do seu horário local de recebimento e você obtém o atraso do feed, que inclui o atraso interno de publicação da exchange e a viagem pela rede. Registre-o por stream, não apenas como média: snapshots de profundidade, atualizações incrementais do livro e streams de trades podem se comportar de forma diferente, e streams agregados que publicam a cada 100 ms mostrarão um padrão em dente de serra.

Por que o relógio importa

Medições de ida só são tão boas quanto a concordância entre o seu relógio e o da exchange. Se o relógio do seu servidor estiver 15 ms atrasado, todo atraso do feed parecerá 15 ms melhor do que realmente é. Em um servidor na nuvem, execute o chrony com o serviço de horário do provedor e verifique chronyc tracking: um offset de cerca de um milissegundo é uma base sólida para comparar regiões. Muitas exchanges também oferecem um endpoint de horário do servidor; compará-lo com seu relógio, descontando metade do ciclo medido, fornece uma verificação aproximada. Endpoints de ordens que aceitam uma janela de recebimento (idade máxima permitida do timestamp da requisição) também rejeitarão ordens quando seu relógio se desviar, outro motivo para mantê-lo sincronizado.

Meça o caminho da ordem separadamente

O atraso do feed mostra quão antiga é sua visão do mercado. O ciclo da ordem mostra quanto tempo leva para agir com base nela. Os dois costumam ser diferentes: as requisições de ordens passam por autenticação, controle de limites de requisições e verificações de risco que um stream de dados de mercado não tem. Algumas exchanges, entre elas a Binance, oferecem um endpoint de teste de ordens que valida uma ordem assinada sem enviá-la ao motor de matching; ele mede a parte de rede e gateway. Onde a exchange oferecer envio de ordens via sessão WebSocket ou FIX, meça isso também, porque uma sessão persistente evita o overhead por requisição.

Como escolher uma região de hospedagem para arbitragem entre duas exchanges

Para uma única exchange, a resposta é simples: alugue um servidor na mesma região de nuvem do motor dela. A arbitragem entre duas exchanges é um problema de geometria, porque os motores estão em lugares diferentes e você só pode ficar ao lado de um deles.

Considere uma arbitragem de hedge entre a Binance (Tóquio) e a Bybit (Singapura). O ciclo entre as duas regiões é de cerca de 70 ms, ou seja, aproximadamente 35 ms de ida. Veja as principais opções:

Os tempos de ida e volta são valores típicos aproximados entre regiões de nuvem pública; verifique os números atuais entre regiões do seu provedor e meça a partir dos seus próprios servidores.

A observação principal é que a informação sempre precisa atravessar a distância entre as duas exchanges. Se o preço se move na Binance e a cotação desatualizada está na Bybit, um servidor em Tóquio vê o movimento na hora e sua ordem viaja 35 ms até Singapura; um servidor em Singapura recebe o movimento com 35 ms de atraso e sua ordem chega na hora. O total é o mesmo. O que muda é qual parte da cadeia espera e, portanto, qual decisão deve orientar a escolha:

• Hospede ao lado da plataforma onde a ordem precisa vencer. Se seu lucro depende de pegar uma cotação antes de outros traders em uma exchange, compita onde essa fila é decidida. Lá, a informação de todos sobre a outra exchange chega na mesma velocidade, mas sua ordem não precisa viajar.
• Coloque o hedge no livro mais profundo. A perna que chega mais tarde à sua exchange deve ser a menos sensível a alguns milissegundos: o livro mais líquido, onde é improvável que o preço do hedge se mova muito.
• Saiba rapidamente o status de execução. Estar ao lado da exchange onde execuções parciais são comuns permite dimensionar o hedge com informações precisas, o que reduz o risco sem hedge.
• Divida apenas quando compensar. Dois processos, um por região, podem manter cada um seu livro de ofertas local e reagir localmente, mas precisam se coordenar pelo mesmo link de 70 ms. Isso adiciona complexidade e modos de falha e vale a pena principalmente em configurações profissionais.

Para estratégias entre três ou mais plataformas asiáticas, Tóquio costuma ser o centro prático por causa do número de grandes exchanges lá. Para pares que incluem uma plataforma americana ou europeia, a perna intercontinental domina e a estratégia precisa tolerar de 70 a 120 ms de ida, o que descarta a competição pura por velocidade e favorece diferenças maiores e mais duradouras.

Como a latência se transforma em dinheiro

Uma diferença de preço entre dois livros de ofertas não é um prêmio fixo. Outros traders também a veem, os market makers atualizam suas cotações e a diferença desaparece em um tempo que depende do ativo e da plataforma. Uma forma simples de pensar nisso é assumir que cada oportunidade sobrevive por um tempo aleatório com uma vida média e perguntar qual a probabilidade de ela ainda estar lá quando sua ordem chegar.

Neste modelo, a probabilidade de uma diferença ainda estar lá após um tempo de reação de L milissegundos é exp(−L / τ), onde τ é a vida média da diferença. Os resultados para três tempos de reação, que correspondem aproximadamente a um servidor na mesma região (5 ms), em uma região vizinha (40 ms) e em outro continente (150 ms):

Agora atribua dinheiro a isso. Suponha que uma estratégia encontre 200 sinais por dia com vantagem líquida de 0.10% em um trade de 5,000 USDT, ou 5 USDT por sinal capturado, e que um sinal perdido custe em média 1.5 USDT, porque uma perna foi executada e precisa ser desfeita. Para diferenças com vida de 200 ms:

Os números são hipotéticos, mas a conclusão é robusta: mover um bot de outro continente para a região certa pode multiplicar o resultado da mesma estratégia, enquanto mover de uma região vizinha para a mesma região traz uma melhoria menor, mas ainda significativa. Isso também mostra o limite: para diferenças que duram um segundo ou mais, a latência quase não importa, e taxas, slippage e inventário decidem o resultado. Antes de gastar com infraestrutura, verifique quanto tempo as diferenças que você opera realmente duram; o scanner gratuito de arbitragem de criptomoedas permite acompanhar ao vivo diferenças reais de preço entre exchanges.

Colocation, VPS e o que é realista para traders independentes

No forex e no mercado de ações, colocation significa alugar espaço em rack no mesmo data center da bolsa ou dos servidores da corretora, e os principais hubs são bem conhecidos (veja nosso guia sobre VPS para arbitragem forex e hubs de colocation). Nas criptomoedas, o equivalente para a maioria dos traders é simplesmente um servidor virtual na mesma região de nuvem da exchange. Como o próprio motor roda nessa nuvem, um servidor na mesma região já fica a um ou dois milissegundos dele, por um custo de dezenas de dólares por mês.

Dentro de uma região, a zona de disponibilidade pode fazer uma diferença adicional de uma fração de milissegundo. Isso só importa quando você compete com market makers profissionais nos pares mais líquidos, e vale a pena testar apenas depois de resolver os itens maiores: região, conexões aquecidas, dados via WebSocket e seu próprio código. Os princípios gerais de quão rápido um servidor precisa ser, e por que baixa latência importa mais do que especificações altas, estão em quão rápido seu VPS precisa ser para arbitragem.

Latência dentro do seu próprio software

Com o servidor no lugar certo, os atrasos restantes são em grande parte autoinfligidos. Os culpados habituais, na ordem em que os vemos:

• Abrir conexões sob demanda. Mantenha as conexões REST vivas com um pool de conexões, envie periodicamente uma requisição leve para que conexões ociosas não sejam fechadas e reconecte os WebSockets proativamente antes do tempo máximo de sessão da exchange.
• Polling em vez de streaming. Use dados de mercado via WebSocket e, quando disponível, envio de ordens via WebSocket ou FIX.
• Trabalho pesado no caminho crítico. Gravar logs em disco, analisar grandes mensagens JSON campo a campo ou recalcular todo o livro de ofertas a cada atualização adicionam milissegundos. Faça o mínimo antes de enviar a ordem e adie o resto.
• Penalidades por limite de requisições. Um bot que excede o limite de peso das requisições é rejeitado ou banido temporariamente, o que equivale a latência infinita. Distribua o orçamento de requisições por exchange e reduza o ritmo antes do limite, não depois.
• Coleta de lixo e disputa de CPU. Em um VPS compartilhado pequeno, outros inquilinos e pausas de limpeza de memória podem adicionar dezenas de milissegundos em momentos aleatórios. Isso aparece no p99, não nas médias.
• Envio sequencial das pernas. Se as duas pernas de um hedge são independentes, envie-as em paralelo em vez de esperar a primeira confirmação.

O software VIP Crypto Arbitrage da BJF Trading Group se conecta a exchanges centralizadas de spot e futuros por meio de suas APIs nativas e roda em um servidor de sua escolha, então os princípios de localização deste guia se aplicam diretamente a ele. Para a lógica das estratégias guiadas por latência, veja nosso guia de arbitragem de latência e, para o panorama geral das estratégias entre exchanges, a visão geral da arbitragem de criptomoedas.

Riscos e limitações

• Latência não é uma vantagem por si só. Ser rápido só ajuda se a estratégia for lucrativa depois de taxas, slippage e custos de inventário. Um bot rápido com vantagem negativa perde dinheiro mais rápido.
• As localizações mudam. As exchanges migram motores e trocam de provedor de CDN. Uma região que era a certa no ano passado pode não ser hoje; meça novamente com regularidade.
• As medições são locais. Nossos números de Montreal, e qualquer tabela publicada, descrevem um lugar e um momento. Somente medições do seu próprio servidor, pelo seu próprio software, são válidas para suas decisões.
• Os atrasos do lado da exchange dominam sob estresse. Em mercados violentos, os gateways enfileiram requisições e as confirmações ficam mais lentas para todos. Sua estratégia precisa tolerar isso, por exemplo limitando o tamanho da posição quando os tempos de confirmação aumentam.
• A corrida armamentista não tem fim. Nos pares mais líquidos, empresas profissionais investem em velocidade muito mais do que um trader independente consegue. Procure diferenças que durem o suficiente para a sua configuração em vez de competir pelas mais curtas.
• Conformidade. A localização do servidor não muda sua situação legal. Use apenas exchanges e produtos disponíveis para você e respeite os termos das APIs e os limites de requisições.

Perguntas frequentes

Este artigo é educativo e não constitui aconselhamento financeiro. Os números de latência da tabela de Montreal foram medidos pela BJF Trading Group em 7 de novembro de 2026 a partir de um servidor e não são um ranking de exchanges; as informações sobre regiões se baseiam em medições de terceiros relatadas publicamente e podem mudar. Os números e gráficos marcados como ilustrativos ou aproximados são modelos e valores típicos, não medições de nenhuma exchange ou trader específico.