Proxies para Dados de Mercado Cripto: CEX vs On-Chain

Por Que Dados de Mercado Cripto Exigem Proxies Diferentes

Se você faz parte de uma equipe de quant, constrói um serviço de dados de mercado ou opera infraestrutura DeFi, já sentiu o problema: as exchanges centralizadas (CEX) limitam, bloqueiam e geofiltram seus endpoints públicos, enquanto os dados on-chain seguem um modelo de acesso completamente diferente. Tratar ambos da mesma forma é um erro arquitetural caro.

Dados on-chain — transações, estados de contrato, eventos — fluem através de RPC nodes e indexadores. Proxies raramente são necessários aqui, mas podem ajudar com throughput e redundância geográfica. Dados CEX — orderbooks, funding rates, liquidations, price feeds — são servidos por APIs REST/WebSocket que impõem rate limits agressivos por IP, geoblocking e, em casos extremos, o status HTTP 451 (Unavailable for Legal Reasons).

Este guia separa claramente essas duas realidades e mostra como projetar uma infraestrutura de crypto market data scraping que seja robusta, de baixa latência e regulatoriamente consciente.

Dados On-Chain vs Dados de Exchange: Duas Naturezas Distintas

Dados on-chain (RPC / Indexadores)

Blocos, transações, logs de eventos, storage reads — tudo isso vem de nós RPC expostos por provedores como Alchemy, Infura, QuickNode ou seus próprios nós. O acesso é autenticado por API key, não por IP. Rate limits são por projeto, não por endereço. Resultado: proxies não são um requisito primário.

• Fontes típicas: Ethereum mainnet, L2s (Arbitrum, Optimism, Base), Solana via RPC
• Formato: JSON-RPC over HTTPS, ou WebSocket subscriptions (eth_subscribe)
• Autenticação: API key no header ou URL
• Rate limit: compute units por segundo, por projeto — não por IP

Dados de CEX (APIs públicas + Web)

Orderbooks, trades recentes, funding rates, taxas de liquidation, ticker de preço — servidos por REST e WebSocket. Muitos endpoints públicos impõem limites por IP (ex.: 1200 req/min no Binance para IP não-VIP). Geoblocking é comum: Binance bloqueia IPs dos EUA, OKX restringe certas jurisdições, Bybit tem políticas similares.

• Fontes típicas: Binance, Coinbase, OKX, Bybit, Kraken, Deribit
• Formato: REST JSON, WebSocket streams, FIX protocol (institucional)
• Autenticação: API key + HMAC signature (endpoints privados); sem autenticação (endpoints públicos)
• Rate limit: por IP para endpoints públicos — aqui é onde proxies importam

Por Que Proxies Residenciais Importam para CEX Scraping

Endpoints públicos de CEX são desenhados para usuários individuais, não para pipelines de dados em escala. Quando você faz scraping de orderbooks de 50 pares em 5 exchanges a cada 100ms, um único IP esgota o rate limit rapidamente.

O problema dos rate limits por IP

O Binance, por exemplo, permite ~1200 requests/minuto por IP em endpoints públicos. Isso parece muito, até você calcular: 50 pares × 6 snapshots/minuto × múltiplos endpoints = milhares de requests. O resultado é um 429 Too Many Requests que, se persistido, escala para 418 I'm a teapot (ban temporário) ou 451 Unavailable for Legal Reasons (geoblock).

Geoblocking e o status 451

A Binance bloqueia ativamente IPs dos EUA desde 2021, redirecionando para binance.us. Outras exchanges seguem padrões similares por pressão regulatória (SEC, CFTC, MiFID II na Europa). Se seu data center está em Virginia ou Frankfurt, você pode receber um 451 em vez dos dados que precisa.

Proxies residenciais resolvem ambos os problemas: rotação de IP para distribuir carga e geo-targeting para acessar exchanges a partir de jurisdições permitidas.

Regra prática: Para scraping de CEX, proxies residenciais e móveis são sua primeira linha de defesa. Datacenter proxies funcionam para throughput, mas não resolvem geoblocking.

Arquitetura: WebSocket-First, REST com Rotação de Proxy

WebSocket para dados em tempo real

Quando a exchange expõe um WebSocket público (Binance, OKX e Bybit o fazem), use-o. WebSocket mantém uma conexão persistente, eliminando overhead de HTTP e evitando rate limits por request. Para orderbooks em tempo real, trades streaming e mark prices, WS é superior em todos os aspectos.

O desafio: se a conexão WS cai e o IP está banido, a reconexão falha. Mantenha um pool de proxies residenciais com sticky sessions para reconexões rápidas.

REST fallback com rotação de proxy

Nem tudo está disponível via WebSocket. Funding rates históricos, snapshots de liquidation, e dados de taxa de withdraw são tipicamente REST-only. Aqui, a rotação de proxy por request (rotating residential) é ideal: cada request sai de um IP diferente, distribuindo o rate limit.

Exemplo com curl para snapshot de orderbook da Binance via proxy residencial ProxyHat:

# Orderbook snapshot - Binance BTC/USDT via residential proxy (IP não-EUA)
curl -x http://user-country-JP:PASSWORD@gate.proxyhat.com:8080 \
  "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100"

Exemplo em Python com requests e rotação automática:

import requests
from itertools import cycle

# Pool de proxies residenciais com geo-targeting
proxy_pool = cycle([
    "http://user-country-JP:PASSWORD@gate.proxyhat.com:8080",
    "http://user-country-SG:PASSWORD@gate.proxyhat.com:8080",
    "http://user-country-DE:PASSWORD@gate.proxyhat.com:8080",
])

def fetch_orderbook(symbol: str, limit: int = 100) -> dict:
    proxy = next(proxy_pool)
    proxies = {"http": proxy, "https": proxy}
    url = f"https://api.binance.com/api/v3/depth?symbol={symbol}&limit={limit}"
    resp = requests.get(url, proxies=proxies, timeout=10)
    resp.raise_for_status()
    return resp.json()

# Scraping de múltiplos pares com rotação
for pair in ["BTCUSDT", "ETHUSDT", "SOLUSDT"]:
    book = fetch_orderbook(pair)
    print(f"{pair}: bid={book['bids'][0][0]}, ask={book['asks'][0][0]}")

WebSocket com proxy em Node.js

const WebSocket = require('ws');
const { HttpsProxyAgent } = require('https-proxy-agent');

// Proxy residencial com sticky session para conexão WS persistente
const agent = new HttpsProxyAgent(
  'http://user-country-JP-session-ws1:PASSWORD@gate.proxyhat.com:8080'
);

const ws = new WebSocket(
  'wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms',
  { agent }
);

ws.on('message', (data) => {
  const book = JSON.parse(data);
  // Processa orderbook em tempo real
  console.log(`Bid: ${book.bids[0]}, Ask: ${book.asks[0]}`);
});

ws.on('error', (err) => {
  console.error('WS error:', err.message);
  // Reconectar com novo proxy sticky session
});

Funding rates com sessão persistente em Python

import requests

# Sessão com proxy sticky (mesmo IP por 10 min) para evitar rate limit spikes
session = requests.Session()
sticky_proxy = "http://user-country-SG-session-funding1:PASSWORD@gate.proxyhat.com:8080"
session.proxies = {"http": sticky_proxy, "https": sticky_proxy}

def fetch_funding_rates(symbol: str = "BTCUSDT") -> list:
    """Funding rates recentes — endpoint REST, rate limit por IP"""
    url = f"https://fapi.binance.com/fapi/v1/fundingRate?symbol={symbol}&limit=100"
    resp = session.get(url, timeout=10)
    resp.raise_for_status()
    return resp.json()

def fetch_liquidations(symbol: str = "BTCUSDT") -> list:
    """Snapshot de liquidations — dados sensíveis, proxy residencial recomendado"""
    url = f"https://fapi.binance.com/fapi/v1/allForceOrders?symbol={symbol}&limit=50"
    resp = session.get(url, timeout=10)
    resp.raise_for_status()
    return resp.json()

# Coleta e análise
funding = fetch_funding_rates()
print(f"Último funding rate: {funding[-1]['fundingRate']}")
print(f"Timestamp: {funding[-1]['fundingTime']}")

Considerações de Latência: Escolhendo o Proxy Certo por Região

Para dados de mercado em tempo real, latência importa. Um proxy residencial no Japão acessando a Binance (servidores primários em Tóquio) terá latência de ~5-15ms round-trip. O mesmo proxy acessando a Coinbase (servidores nos EUA) terá 150-200ms.

Exchange	Região dos Servidores	Proxy Recomendado	Latência Típica
Binance	Japão / APAC	JP, SG, HK	5-20ms
OKX	Hong Kong / APAC	HK, SG, JP	5-20ms
Bybit	Singapura	SG, JP, HK	5-15ms
Coinbase	EUA (AWS us-east-1)	US, CA	5-30ms
Kraken	EUA / UE	US, DE, NL	10-40ms
Deribit	EUA / UE	NL, DE, US	10-40ms

Estratégia de latência

• Para arbitragem e market-making: use datacenter proxies de baixa latência na mesma região do exchange. Proxies residenciais adicionam 20-50ms, o que pode ser inaceitável para estratégias sub-milissegundo.
• Para analytics e scraping em batch: proxies residenciais são preferíveis — a latência extra é irrelevante e a rotação de IP é crítica.
• Para compliance com geoblocking: proxies residenciais com geo-targeting são obrigatórios. Datacenter IPs de regiões bloqueadas não resolvem o problema.

Com ProxyHat, você pode geo-targetar por país e cidade:

# Proxy residencial em Tóquio para Binance JP
http://user-country-JP-city-tokyo:PASSWORD@gate.proxyhat.com:8080

# Proxy residencial em Frankfurt para Kraken EU
http://user-country-DE-city-frankfurt:PASSWORD@gate.proxyhat.com:8080

# Proxy SOCKS5 de baixa latência para arbitragem
socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080

Dados On-Chain: RPC Providers e O Papel Secundário dos Proxies

Para dados on-chain, a arquitetura é fundamentalmente diferente. Você não precisa de proxies para contornar rate limits — precisa de provedores RPC com throughput suficiente.

Provedores RPC e seus modelos

Provedor	Compute Units (gratuito)	Rate Limit Model	Ideal Para
Alchemy	300M CU/mês	Por API key	DApps, analytics geral
Infura	100K req/dia	Por projeto	Infra Ethereum básica
QuickNode	Sob demanda	Por plano	Multi-chain, alta velocidade
RpcEndpoint (próprio)	Ilimitado	Hardware-bound	Controle total, sem dependência

Quando proxies fazem sentido para on-chain:

• Redundância geográfica: se seu provedor RPC primário cai, um proxy em outra região pode rotear para um provedor secundário.
• Throughput em múltiplos projetos: se você tem 10 API keys de diferentes projetos, proxies permitem distribuir requests sem que um único IP seja gargalo.
• Acesso a redes regionais: alguns nós de validação em redes locais podem ser mais rápidos quando acessados de IPs na mesma região.

Mas, na maioria dos casos, use um RPC provider diretamente. Proxies são overhead desnecessário para dados on-chain.

Integridade de Dados: Timestamps, Sequência e Garantias

Para equipes de quant e serviços de dados de mercado, integridade de dados não é opcional — é o produto. Aqui estão as considerações críticas:

Timestamps e ordenação

• Timestamps de exchanges (T no Binance, timestamp no OKX) são gerados pelo servidor. Use-os como fonte de verdade, não o timestamp local de recebimento.
• Para dados on-chain, o blockNumber e logIndex garantem ordenação. Não confie em timestamps de blocos para ordenação fina — eles podem ter variações.
• Registre sempre ambos: exchange_timestamp e local_received_timestamp. A diferença é sua medida de latência.

Garantias de sequência

• WebSocket: streams são ordenados por definição, mas reconexões podem causar gaps. Implemente lastUpdateId tracking para detectar gaps no orderbook.
• REST polling: sem garantia de sequência. Se você polla a cada 100ms, pode perder trades intermediários. Para sequência completa, use WebSocket.
• On-chain: blocos são imutáveis e ordenados. Use eth_getLogs com range de blocos para garantir completude.

Insight crítico: Se seu pipeline mistura dados de múltiplas exchanges e on-chain, normalize todos os timestamps para UTC milissegundos e mantenha um ID de sequência global. Sem isso, a reconstrução de séries temporais é impossível.

Conformidade Regulatória: SEC, MiFID II e Termos de Uso

Este é o aspecto mais sensível do crypto market data scraping. Ignorar conformidade pode resultar em consequências legais reais.

Termos de uso das exchanges

• Binance: O ToS proíbe scraping automatizado de dados públicos sem autorização. Na prática, milhões de bots operam — mas a Binance pode banir contas e IPs a qualquer momento.
• Coinbase: O ToS é mais permissivo para dados de mercado público via API, mas proíbe reverse engineering e scraping do site.
• OKX / Bybit: Políticas similares — APIs públicas são para uso individual, não para redistribuição comercial.

Considerações legais por jurisdição

• SEC (EUA): Acessar Binance.com de IPs dos EUA viola os termos de um acordo com o Departamento de Justiça. Não é apenas um ToS violation — pode constituir violação de sanctions ou securities law.
• MiFID II (UE): Exige que fontes de dados de mercado para negociação sejam licenciadas. Se você redistribui dados de CEX como parte de um serviço, pode precisar de uma licença de data provider.
• Licenças de dados de mercado: Dados de CEX não são regulados como dados de mercado tradicionais (NYSE, LSE), mas a regulamentação está evoluindo. Verifique sempre com consultoria jurídica.

Boas práticas de conformidade

• Nunca use proxies para contornar geoblocking que viola sanctions ou securities law. Use proxies para acessar dados de jurisdições onde seu acesso é legal.
• Se você redistribui dados de mercado, declare a fonte e verifique se os termos da exchange permitem redistribuição.
• Para uso interno (quant, analytics), o risco é primariamente de banimento de conta/IP, não de ação legal — mas consulte um advogado.
• Respeite robots.txt e rate limits publicados. Se uma exchange oferece uma API paga com mais throughput, considere-a antes de escalar scraping.

Arquitetura de Referência: Pipeline Completo

Para equipes que precisam de dados CEX e on-chain simultaneamente, aqui está uma arquitetura de referência:

Camada de ingestão

• WebSocket connections: Binance WS (orderbook + trades), OKX WS (mark price + funding), Bybit WS (liquidations). Conexões persistentes com sticky residential proxies.
• REST polling: Snapshots periódicos com rotating residential proxies para funding rates históricos, taxas de withdraw, dados de open interest.
• On-chain RPC: Conexão direta a provedores RPC (Alchemy/QuickNode) via HTTPS. Sem proxy necessário, mas com failover entre múltiplos provedores.

Camada de processamento

• Normalização de timestamps para UTC milliseconds.
• Deduplicação por tradeId (CEX) ou txHash + logIndex (on-chain).
• Sequence gap detection via lastUpdateId (Binance) ou blockNumber (on-chain).

Camada de armazenamento

• Time-series database (TimescaleDB, QuestDB, ou ClickHouse) para dados de mercado.
• Event-sourced store para on-chain data.
• Particionamento por exchange + symbol + date para queries eficientes.

Comparação: Proxies para CEX vs On-Chain

Aspecto	CEX Scraping	On-Chain (RPC)
Autenticação	Por IP (endpoints públicos)	Por API key
Rate limit	Por IP — precisa de rotação	Por projeto — rotação não ajuda
Geoblocking	Sim (Binance US, etc.)	Não
Proxy necessário?	Sim — residencial para geo + rotação	Raramente — apenas redundância
Latência crítica?	Sim para HFT; moderada para analytics	Não (block time é o gargalo)
Tipo de proxy ideal	Residencial rotativo + sticky	Datacenter (se necessário)
Risco regulatório	Alto (ToS, sanctions, MiFID II)	Baixo (dados públicos on-chain)

Key Takeaways

• Dados CEX e on-chain são fundamentalmente diferentes. CEX exige proxies para contornar rate limits por IP e geoblocking. On-chain usa autenticação por API key — proxies raramente são necessários.
• WebSocket-first para tempo real. Use WS para orderbooks e trades, REST com proxy rotation para dados históricos e endpoints não-streaming.
• Geo-targeting é essencial. Use proxies residenciais na mesma região dos servidores do exchange para minimizar latência e evitar geoblocking.
• Integridade de dados não é opcional. Registre timestamps de exchange e local, rastreie sequence IDs, e implemente gap detection.
• Conformidade regulatória é real. Não use proxies para violar sanctions ou securities law. Consulte advogados antes de redistribuir dados de mercado.
• Sticky sessions para WS, rotating para REST. Essa é a combinação que maximiza confiabilidade e throughput.

Para começar a construir seu pipeline de exchange API proxies com proxies residenciais otimizados para dados de mercado, explore as opções de pricing do ProxyHat ou veja locações disponíveis para geo-targeting preciso. Para casos de uso específicos de scraping, confira nosso guia de web scraping com proxies.