O custo da latência no trading onchain

Os custos de latência aparecem como a diferença entre o estado da chain que um produto observou e o estado no qual sua ação é executada. Essa diferença cresce a cada milissegundo que o produto gasta lendo, decidindo, submetendo e aguardando confirmação.

Para uma visão de portfólio de longo prazo, essa diferença pode ser um incômodo. Para um market maker, um swap router, um liquidation engine, ou um trader tentando cancelar uma ordem desatualizada, ela pode consumir uma parcela significativa da vantagem da estratégia. RPC de baixa latência é essencial para experiências de trading bem-sucedidas porque ajuda esses produtos a agir sobre estados mais recentes.

Uma cotação pode ficar desatualizada antes que uma negociação seja executada

Uma cotação de swap captura as reservas do pool, a liquidez do order book, as condições de gas e o estado do mercado no momento em que a aplicação a solicita. Essas entradas continuam mudando enquanto o usuário confirma uma transação.

O caminho básico é simples:

1. Um app lê o estado da chain e do mercado.
2. Ele calcula uma cotação ou decisão de trading.
3. O usuário submete uma transação.
4. A rede propaga, sequencia e executa a transação.
5. O app recebe um receipt e atualiza sua visão.

Cada atraso torna a ação final menos atual. Uma leitura lenta usa dados de mercado mais antigos; uma submissão lenta dá ao mercado mais tempo para se mover; e uma confirmação lenta deixa os usuários vendo um status desatualizado.

A 0x precifica negociações entre fontes de liquidez. Sua equipe associa dados responsivos e precisos à qualidade da cotação, porque os preços podem mudar enquanto as requisições estão em trânsito, e ela gera essas cotações em menos de um segundo.

A Jupiter ilustra essa diferença de timing: seu caminho de landing direto visa 50–400 milissegundos, ou zero a um bloco do Solana, contra 400 milissegundos a 1,2 segundo, ou um a três blocos, para submissão RPC padrão. Menos blocos entre a cotação e a execução deixam menos oportunidades para o estado mudar.

Os quatro estágios em que a latência se acumula

Toda negociação passa por esses estágios. Um atraso em qualquer um deles torna o resultado final menos atual ou menos certo.

Esses estágios interagem entre si. Uma leitura de mercado desatualizada continua desatualizada mesmo quando o caminho de escrita é rápido. Durante um pico de volatilidade, as requisições mais lentas importam mais do que a média. Falhas também criam seu próprio risco: retries, telas desatualizadas e ações perdidas.

Produtos sensíveis à latência devem avaliar o tempo de resposta em p95 e p99 junto com a taxa de sucesso. Nossa metodologia de benchmark pública mede leituras EVM aquecidas, no nível de método, e reporta a latência de respostas bem-sucedidas separadamente das falhas. O Node API subjacente cobre as leituras e escritas que um produto usa para interagir com uma chain. Ele mede um caminho específico de um provedor, enquanto uma equipe de trading precisa testar suas próprias leituras, escritas, regiões e padrão de tráfego.

Como a latência se torna um custo econômico no trading onchain?

A latência se torna um custo econômico quando altera os resultados de execução, e a forma como isso acontece depende da carga de trabalho. Aqui estão os padrões que se repetem em sistemas de trading onchain.

Swaps: uma cotação desatualizada vira slippage ou um revert

O price impact e o slippage costumam ser tratados como a mesma coisa, mas descrevem custos diferentes. Nosso guia de infraestrutura DeFi mostra como esses custos aparecem em fluxos de cotação em produção. O price impact é a mudança previsível que uma negociação causa no preço de um pool, para um determinado tamanho. O slippage é a diferença adicional entre o resultado cotado e o resultado recebido na execução. Ele depende da latência, das transações concorrentes e da ordem de inclusão no bloco.

Essa distinção importa no design de produto. O price impact é visível no momento da cotação. O slippage cresce enquanto a transação está pendente. Uma proteção de output mínimo protege o usuário convertendo uma movimentação de preço excessiva em um revert. Transações com taxa mais baixa podem esperar mais enquanto o ambiente de preços muda; um output mínimo, input máximo ou deadline define a pior execução que um usuário aceitará.

O resultado percebido pelo usuário é um preço pior, uma negociação perdida, ou um caminho de execução mais restrito que reduz a exposição a um mercado em mudança. Leituras e submissões mais rápidas reduzem parte dessa janela de exposição.

Market making e gestão de ordens: um cancel atrasado pode virar fluxo tóxico

Market makers atualizam continuamente suas cotações à medida que os preços se movem. Se o sistema descobre uma movimentação tarde, ou envia um cancel tarde, uma ordem em espera pode ser preenchida depois de já ter se tornado não lucrativa. Traders que enviam uma ordem imediata enfrentam o risco oposto: quando ela chega ao mercado, a liquidez disponível pode já ter desaparecido.

Liquidations e arbitragem: tempo é parte da oportunidade

Liquidation engines e sistemas de arbitragem competem para observar uma mudança de estado e agir antes que a oportunidade se encerre. A corrida relevante pode envolver um novo preço de oracle, um health factor alterado, um desequilíbrio de pool ou uma movimentação de preço entre venues. Perder essa corrida pode significar receita perdida. Tentativas falhas repetidas também podem consumir fees e blockspace.

O design da chain muda a natureza dessa corrida. Em sistemas que sequenciam por ordem de chegada, um caminho de menor latência pode ser diretamente relevante para a ordenação. Em sistemas que usam priority fees, tanto as fees quanto o timing importam. Em sistemas com order flow privado ou bundles, visibilidade e execução atômica introduzem outros trade-offs. A infraestrutura opera dentro dessas regras de mercado. Seu papel é evitar adicionar atraso desnecessário antes que uma estratégia entre nelas.

Wallets e interfaces de trading: o atraso vira um problema de confiança

A latência afeta mais do que o preço de preenchimento. Uma wallet ou app de trading pode emitir muitas chamadas antes que o usuário veja uma tela útil: saldos, allowances, cotações de rota, estimativas de gas, receipts e histórico de transações. Se essas chamadas retornam lentamente ou falham de forma intermitente, os usuários veem preços mudando, status atrasado, ou uma interface que parece travada.

Isso é especialmente prejudicial durante a volatilidade. A mesma atualização lenta de saldo que é apenas um incômodo em um mercado calmo pode atrasar um hedge, uma decisão de cancelamento, ou a confirmação de um depósito quando um usuário está tentando gerenciar risco.

Por que a latência de cauda importa mais do que uma média

Distribuições de latência têm caudas. Quando um endpoint fica mais lento sob carga, o produto experimenta o caminho lento justamente durante picos de tráfego, volatilidade ou contenção da chain.

É por isso que uma avaliação de provedor deve responder a quatro perguntas:

• Quais métodos estão no caminho crítico? Avalie a leitura do último bloco, eth_call, eth_getLogs, a busca de receipt e o broadcast de transação separadamente; cada um tem um comportamento diferente.
• A partir de quais regiões os usuários e serviços se conectam? A geografia muda o caminho de rede.
• Quão lentas são as chamadas bem-sucedidas em p95 e p99? Esses valores revelam as requisições que uma média esconde.
• Com que frequência as requisições falham ou expiram? Um timeout é um evento de confiabilidade que pode disparar retries, UI desatualizada ou ação perdida.

Um benchmark deve deixar essas condições explícitas e medir o caminho de produto que um comprador realmente executa. Nossa metodologia de benchmark fixa a origem da requisição, o método, o payload, o timeout, as regras de sucesso e o estado da conexão para cada comparação no nível de método, para ajudar builders a tomar decisões de infraestrutura.

O que o RPC de baixa latência pode e não pode resolver

Uma camada de RPC mais rápida pode retornar o estado atual mais cedo, submeter uma transação assinada mais cedo, e manter uma interface de trading responsiva. A qualidade do preenchimento ainda depende da movimentação de mercado, da liquidez, das fees, da seleção de rota, da proteção de transação e da política de sequenciamento da chain. O benchmark de leitura de um provedor mede desempenho de leitura; desempenho de swap de ponta a ponta, inclusão de transação, comportamento de WebSocket e PnL de estratégia exigem testes separados.

Esse escopo mantém as afirmações sobre infraestrutura honestas e ajuda equipes a escolher medições que correspondam à sua carga de trabalho. O objetivo é remover atraso evitável dos caminhos onde a economia de um produto é mais sensível ao tempo.

Construímos nosso trabalho de RPC de baixa latência em torno desse objetivo. O Alchemy Edge Proxy remove overhead fixo do caminho de requisição na ingestão e reduziu o p99 na APAC de 150 milissegundos para 20 milissegundos em nossa medição de migração. O roteamento do Cortex seleciona um nó saudável por requisição, em vez de tratar a proximidade como a resposta completa. O Cortex também sustenta as operações de capacidade e frota que mantêm o caminho de requisição responsivo sob carga. Nosso trabalho de infraestrutura de baixa latência abrange o edge, o roteamento, a capacidade, as operações de nós e a medição. Cada camada é ajustada para oferecer um serviço confiável de baixa latência.

Como avaliar seu próprio caminho de execução

Comece pelo fluxo onde o atraso cria o maior custo, seja para o usuário ou para a economia da estratégia.

1. Mapeie o caminho da leitura de estado até o resultado visível para o usuário, incluindo cálculo de rota, assinatura, submissão, inclusão e atualização de status.
2. Teste os métodos e payloads que seu produto realmente usa, a partir das regiões onde seus serviços e usuários operam. Comece pelo RPC API e pelas chains suportadas das quais seu produto depende. Execute o mesmo teste durante períodos normais e durante períodos de alta volatilidade ou alto tráfego.
3. Registre p50, p95, p99, taxa de sucesso, taxa de timeout e tempo de cotação até resultado. Mantenha a latência de leitura, submissão e inclusão separadas.
4. Conecte essas medições a resultados: desvio entre cotação e preenchimento, reverts, preenchimentos perdidos, sucesso de cancelamento, contatos de suporte e abandono de usuários.

Isso cria um modelo de custo para sua estratégia, seus ativos e seus usuários — e mostra onde um caminho mais rápido muda os resultados de execução.

Perguntas frequentes

Como a latência do RPC afeta o desempenho de trading?

A latência amplia a diferença entre o estado que um app de trading observou e o estado em que sua transação é executada. Leituras lentas fazem uma cotação ficar desatualizada antes de ser assinada, submissões lentas dão ao mercado mais tempo para se mover, e confirmações lentas deixam os usuários agindo sobre uma tela desatualizada. O resultado são preenchimentos piores, negociações perdidas ou reverts.

Uma latência de RPC menor garante um preenchimento melhor da negociação?

Uma latência de RPC menor reduz o atraso evitável antes e durante a submissão. A qualidade do preenchimento também depende da movimentação de mercado, da liquidez, das fees, do order flow privado, da seleção de rota, do sequenciamento da chain e da proteção de transação.

Por que o p95 é mais útil do que a latência média de RPC para apps de trading?

Uma média pode esconder as requisições lentas que se concentram durante carga ou volatilidade. O p95 mostra que 95% das respostas bem-sucedidas foram pelo menos tão rápidas quanto esse valor, nas condições medidas. Leia-o junto com a taxa de sucesso, já que falhas e timeouts precisam de sua própria medição de confiabilidade.

Como fazer benchmark de um provedor de RPC para um app de trading?

Teste os métodos e payloads que seu produto realmente usa, a partir das regiões onde seus usuários e serviços operam. Use nossa metodologia de benchmark como ponto de partida reproduzível. Registre p50, p95, p99, taxa de sucesso e taxa de timeout, e mantenha a latência de leitura, submissão e inclusão separadas. Repita o teste durante janelas de alta volatilidade e alto tráfego, bem como em condições de mercado calmo.

Price impact é o mesmo que slippage?

Não. O price impact é o efeito previsível do tamanho de uma negociação sobre o pool no momento atual. O slippage é a diferença, no momento da execução, entre o resultado cotado e o que o usuário recebe. A documentação da Raydium traz uma definição técnica clara de cada um.

Equipes de trading devem fazer benchmark de leituras, escritas e fluxos completos separadamente?

Sim. Um teste de leitura no nível de método pode comparar o comportamento de um provedor em uma requisição específica. Um teste de fluxo de trading completo é necessário para entender, em conjunto, a atualidade da cotação, a tomada de decisão, a submissão, a inclusão e a confirmação. Mantenha as conclusões separadas.