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

Se a sua equipa depende de dados de mercado crypto — orderbooks, funding rates, feeds de preço — já sabe o que acontece quando os rate limits das exchanges entram em ação: 429 Too Many Requests, seguido de 451 Unavailable For Legal Reasons se tentar contornar restrições geográficas de forma ingénua. O pior? Perde-se sequência temporal, lacunas aparecem nos candles de 1s, e backtests ficam comprometidos.

Este guia distingue claramente dois mundos de dados — on-chain (RPC nodes, indexadores) e CEX (APIs de exchanges centrais, web scraping) — e explica quando, como e porquê usar proxies em cada caso. Para equipas de quant, DeFi analytics e serviços de market data, esta distinção não é académica: é o que separa um pipeline confiável de um pipeline com buracos.

Crypto Market Data Scraping: Dois Mundos Distintos

Antes de escolher ferramentas, é preciso entender a natureza fundamental dos dois tipos de dados:

Dimensão	On-Chain (RPC / Indexadores)	CEX (Exchange APIs / Web)
Fonte	Nodos blockchain, indexadores (Alchemy, Infura, QuickNode)	Binance, Coinbase, OKX, Bybit, etc.
Protocolo	JSON-RPC sobre HTTPS / WSS	REST + WebSocket públicos/privados
Rate Limits	Definidos pelo provider RPC (ex: 300 CU/s no Alchemy)	Por IP, por endpoint, com janelas de penalização
Geo-restrições	Raras (pode haver throttling regional)	Comuns — Binance bloqueia IPs dos EUA, OKX restringe certas jurisdições
Necessidade de Proxy	Baixa — aumentar throughput pode justificar	Alta — rate limits e geo-blocks tornam essencial
Garantia de sequência	Block height + log index = ordenação determinística	Timestamps da exchange; sem garantia global de sequência

A implicação direta: on-chain raramente precisa de proxies (mas pode beneficiar), enquanto CEX scraping quase sempre exige proxies residenciais para manter continuidade e contornar bloqueios.

Dados CEX: O Que Está a Raspar e Porquê

Feeds de Preço e Orderbook Snapshots

Para arbitragem e market-making, precisa de orderbooks L2 atualizados a cada 100ms ou menos. As exchanges expõem isso via WebSocket público, mas há limites de conexões por IP. Se monitoriza 50+ pares em 4 exchanges, esgota esses limites rapidamente.

Funding Rates e Liquidations

Dados de funding rates (8h em Binance, variável noutras) e eventos de liquidação são críticos para estratégias de basis trading e análise de sentimento de alavancagem. Estes endpoints REST são frequentemente rate-limited a 1200 req/min por IP na Binance — insuficiente se está a monitorizar múltiplos ativos com granularidade elevada.

Endpoints Públicos vs Privados

Endpoints públicos (orderbook, trades, ticker) não exigem autenticação mas são rate-limited por IP. Endpoints privados (saldo, ordens) exigem API keys e têm limits por conta — aqui, proxies não aumentam o limite, mas podem resolver problemas de geo-acesso.

Exchange API Proxies: Porquê Proxies Residenciais para CEX

Rate Limits Baseados em IP

A Binance, por exemplo, aplica um sistema de weight por endpoint. Um request a /api/v3/depth com limit=5000 consome 50 weights. O teto é 6000 weights/min por IP. Ao atingir o limite, recebe 429. Se persistir, a Binance pode escalar para 418 (ban temporário) ou 451 (bloqueio legal).

Com proxies residenciais rotativos, cada IP tem o seu próprio budget de weights. A matemática é simples: 10 IPs = 60.000 weights/min.

Geo-Restrições: O Problema Real

A Binance bloqueia IPs associados aos EUA (redirecionando para binance.us). A OKX restringe acesso de certas jurisdições. O Bybit limita funcionalidades para utilizadores do Reino Unido. Quando tenta aceder a endpoints públicos a partir de um IP bloqueado, recebe 451 — e isso não é um rate limit que se resolve esperando.

Proxies residenciais com geo-targeting resolvem isto de forma limpa: um IP residencial alemão acede à Binance global sem restrições.

Porquê Residenciais e Não Datacenter

Exchanges detectam e penalizam IPs de datacenter mais agressivamente. Um IP residencial tem fingerprint de tráfego orgânico — browser, device, localização residencial. Para scraping de endpoints públicos, isso traduz-se em menos 429s e bans mais raros.

Binance Proxy: Implementação Prática

Vamos ver como raspar orderbooks da Binance com rotação de proxies via ProxyHat. O padrão é simples: rotatividade por request para maximizar o budget de weights.

import requests
import time
import itertools

PROXY_USER = "user-country-DE"  # IP residencial alemão
PROXY_PASS = "your_password"
PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@gate.proxyhat.com:8080"
proxies = {"http": PROXY_URL, "https": PROXY_URL}

def fetch_binance_orderbook(symbol: str, limit: int = 100):
    """Fetch Binance orderbook via REST with residential proxy."""
    url = "https://api.binance.com/api/v3/depth"
    params = {"symbol": symbol, "limit": limit}
    resp = requests.get(url, params=params, proxies=proxies, timeout=10)

    if resp.status_code == 429:
        retry_after = int(resp.headers.get("Retry-After", 5))
        print(f"Rate limited. Retrying in {retry_after}s...")
        time.sleep(retry_after)
        return fetch_binance_orderbook(symbol, limit)

    resp.raise_for_status()
    return resp.json()

# Monitor 10 pairs with 1s granularity
pairs = ["BTCUSDT", "ETHUSDT", "SOLUSDT", "BNBUSDT", "XRPUSDT",
         "ADAUSDT", "DOGEUSDT", "AVAXUSDT", "DOTUSDT", "MATICUSDT"]

while True:
    for pair in pairs:
        ob = fetch_binance_orderbook(pair, limit=100)
        ts = time.time_ns()
        # Store with nanosecond timestamp for sequence integrity
        print(f"[{ts}] {pair}: bid={ob['bids'][0][0]}, ask={ob['asks'][0][0]}")
    time.sleep(1)

Nota: usamos country-DE no username para garantir um IP alemão — fora do alcance dos geo-blocks da Binance para EUA. O timestamp em nanosegundos preserva a integridade sequencial dos dados.

Dados On-Chain: RPC Providers e Quando Proxies Ajudam

Para dados on-chain, o caminho padrão é usar um RPC provider (Alchemy, Infura, QuickNode) ou correr o seu próprio nodo. Proxies raramente são necessários porque:

• Os rate limits são por API key, não por IP.
• Não existem geo-restrições significativas em endpoints RPC.
• Os providers oferecem throughput elevado nos planos pagos (ex: QuickNode oferece até 500M credits/mês).

Quando Proxies Fazem Sentido para On-Chain

• Throughput extra em planos gratuitos: O plano gratuito do Alchemy dá 300 compute units/segundo. Se precisa de mais e não quer pagar, múltiplas contas + proxies residenciais podem distribuir a carga — embora viole o ToS do provider.
• Geo-otimização de latência: Nodos RPC em regions específicas respondem mais rápido. Um proxy na mesma region do nodo reduz round-trip time.
• Scraping de block explorers: Etherscan, BscScan impõem rate limits agressivos por IP. Proxies residenciais são essenciais para extração em escala.

# On-chain: Direct RPC call — proxy usually unnecessary
import json
import requests

ALCHEMY_URL = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"

payload = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getLogs",
    "params": [{
        "fromBlock": "0x12A1B2C",
        "toBlock": "0x12A1B2D",
        "address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",  # DAI
        "topics": [
            "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"  # Transfer
        ]
    }]
}

resp = requests.post(ALCHEMY_URL, json=payload, timeout=30)
logs = resp.json()["result"]
print(f"Found {len(logs)} DAI transfers in block range")

Se estivesse a raspar Etherscan em vez de usar RPC, o proxy seria obrigatório — Etherscan limita a 5 req/s no plano gratuito.

Arquitetura: WebSocket-First com Fallback REST

Para dados em tempo real de CEXs, a regra é clara: WebSocket primeiro, REST como fallback. As exchanges expõem streams WebSocket públicos para orderbooks, trades e tickers — sem rate limits por IP na mesma medida que REST.

Padrão de Arquitetura

1. Camada WebSocket: Conecte aos streams públicos da exchange (ex: wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms). Use proxies SOCKS5 se precisar de geo-acesso ou se a exchange limitar conexões WS por IP.
2. Camada REST de Resync: Periodicamente, faça um snapshot REST do orderbook completo para corrigir drift. Aqui, proxies residenciais com rotação previnem rate limits.
3. Camada de Histórico: Para dados históricos (funding rates passados, liquidações), REST com rotação de proxies é a única opção viável em escala.

const WebSocket = require('ws');
const { SocksProxyAgent } = require('socks-proxy-agent');

// SOCKS5 proxy for WebSocket — useful when exchange limits WS connections per IP
const proxyAgent = new SocksProxyAgent(
  'socks5://user-country-SG:your_password@gate.proxyhat.com:1080'
);

// Singapore proxy — low latency to Binance SEA servers
const ws = new WebSocket(
  'wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms',
  { agent: proxyAgent }
);

ws.on('open', () => {
  console.log('WS connected via SG proxy');
});

ws.on('message', (data) => {
  const depth = JSON.parse(data);
  const ts = Date.now();
  // Process with millisecond timestamp
  console.log(`[${ts}] best_bid=${depth.bids[0]}, best_ask=${depth.asks[0]}`);
});

ws.on('error', (err) => {
  console.error('WS error:', err.message);
});

ws.on('close', () => {
  console.log('WS closed — reconnecting in 3s');
  setTimeout(() => {
    // Reconnect with new proxy session for fresh IP
    console.log('Reconnecting...');
  }, 3000);
});

A escolha de Singapore (country-SG) não é acidental — minimiza a latência para os servidores SEA da Binance. Veremos isto em detalhe na próxima secção.

Sticky Sessions para WebSocket

Conexões WebSocket são long-lived. Se o IP do proxy muda a meio, a conexão morre. Use sessões sticky (session flag no username do ProxyHat) para manter o mesmo IP durante a vida da conexão:

# Sticky session proxy — same IP for the entire WS connection lifecycle
curl -x "http://user-session-ws-btc-depth-country-SG:your_password@gate.proxyhat.com:8080" \
  "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100"

O flag session-ws-btc-depth garante que todos os requests com essa etiqueta usam o mesmo IP residencial — essencial para manter conexões WS estáveis e evitar reconnects desnecessários.

Considerações de Latência: Proxy Placement por Exchange

Em trading quant, latência é dinheiro. Um proxy mal posicionado adiciona 50-200ms de round-trip time — inaceitável para estratégias de alta frequência. A regra: escolha a localização do proxy em função da região dos servidores da exchange.

Exchange	Região dos Servidores	Proxy Recomendado	Latência Típica
Binance	SEA (Singapura, Tóquio)	Singapura (country-SG) ou Japão (country-JP)	5-30ms
Coinbase	US (Virginia, Oregon)	US East (country-US)	10-40ms
OKX	SEA (Hong Kong, Singapura)	Hong Kong (country-HK) ou SG	5-25ms
Bybit	SEA (Singapura)	Singapura (country-SG)	5-30ms
Kraken	US (various), EU (Amesterdão)	US East ou NL (country-NL)	10-50ms

Para arbitragem cross-exchange (ex: Binance vs Coinbase), precisa de duas conexões proxy — uma em SEA e outra em US East — e um servidor de orquestração posicionado estrategicamente (Londres ou Singapura são bons compromissos).

Princípio: A latência total = latência proxy→exchange + latência seu servidor→proxy. Minimize ambos. Um proxy residencial na mesma cidade dos servidores da exchange pode adicionar apenas 2-5ms.

Integridade de Dados e Timestamps

Para dados financeiros, integridade sequencial não é opcional — é regulatória. Considere:

• Timestamps de receção: Registe sempre o momento em que recebeu o dado (não apenas o timestamp da exchange). Isto permite reconstruir a sequência real de eventos e medir a latência do pipeline.
• Sequence numbers: A Binance inclui lastUpdateId nos snapshots de depth. Use-o para detetar gaps e trigger resyncs.
• Deduplicação: Com múltiplos proxies, pode receber o mesmo trade de IPs diferentes. Deduplicação por trade ID é obrigatória.
• Ordenação por exchange timestamp: Nunca ordene dados de múltiplas exchanges pelo seu timestamp local — use o exchange timestamp e considere clock skew.

Considerações Regulatórias e TOS

Este é o terreno onde boas intenções e más interpretações se encontram. Vamos ser diretos:

ToS das Exchanges

A maioria das exchanges proíbe scraping automatizado nos seus Termos de Serviço. A Binance, por exemplo, reserva-se o direito de limitar ou bloquear acesso a bots. Na prática, exchanges toleram scraping de endpoints públicos em volumes razoáveis — mas a linha é nebulosa.

Geo-Restrições e a Lei

Usar proxies para contornar geo-blocks (ex: aceder à Binance global a partir dos EUA) pode violar:

• Regulamentos locais: SEC nos EUA, MiFID II na UE, SFC em Hong Kong. Aceder a serviços financeiros não-regulados a partir de uma jurisdição regulada é um risco legal real.
• ToS da exchange: Resulta em ban da conta e potenciais ações legais.
• Market data licenses: Dados de mercado de exchanges reguladas (CME, NASDAQ) exigem licenças de redistribuição — proxies não contornam isso.

Melhores Práticas

• Use proxies para resiliência, não para evasão legal: Rotação de IPs para manter throughput dentro dos limits é defensável. Contornar geo-blocks para aceder a serviços proibidos na sua jurisdição não é.
• Documente a proveniência dos dados: Para compliance (MiFID II, SEC), precisa de saber exactamente de onde veio cada dato e quando.
• Respeite robots.txt: Mesmo que não tenha peso legal em todas as jurisdições, demonstra boa-fé.
• Consulte um advogado: Se opera um serviço de market data que redistribui dados de exchanges, a questão não é técnica — é legal.

Key Takeaways

• On-chain e CEX são mundos diferentes: RPC providers (Alchemy, Infura, QuickNode) raramente precisam de proxies; CEX scraping quase sempre precisa.
• Proxies residenciais são essenciais para CEX: Rate limits por IP e geo-restrições tornam proxies residenciais a ferramenta certa — datacenter proxies são mais facilmente detetados e penalizados.
• WebSocket-first, REST como fallback: Use streams WS para dados em tempo real (com sticky sessions); REST com rotação para snapshots e dados históricos.
• Latência importa: Escolha a região do proxy em função dos servidores da exchange — SG para Binance/OKX/Bybit, US East para Coinbase/Kraken.
• Integridade de dados é não-negociável: Timestamps de receção, sequence numbers, deduplicação e ordenação consistente são obrigatórios para qualquer pipeline sério.
• Compliance primeiro: Use proxies para resiliência e throughput, não para evasão legal. Consulte regulamentos locais (SEC, MiFID II) e os ToS de cada exchange.

Conclusão e Próximos Passos

Construir um pipeline de dados de mercado crypto robusto não é apenas uma questão de fazer requests — é garantir que os dados chegam completos, ordenados e dentro dos limites técnicos e legais. Proxies residenciais são a ferramenta que transforma scraping frágil em infraestrutura resiliente, especialmente para dados CEX.

Se está a começar ou a escalar o seu pipeline, teste a abordagem WebSocket-first com um proxy ProxyHat na região da sua exchange-alvo. Comece pequeno — um par, uma exchange, um proxy — e escale a partir daí. Visite os planos ProxyHat para encontrar o tier adequado ao seu volume, ou explore o nosso caso de uso de web scraping para mais detalhes de implementação.