Dlaczego crypto market data scraping wymaga innej architektury
Zespoły quant, twórcy strategii DeFi i dostawcy usług market-data stoją przed fundamentalnym dylematem: skąd czerpać dane i jak zapewnić ich integralność przy rosnących ograniczeniach giełdowych. Centralizowane giełdy (CEX) — Binance, Coinbase, OKX, Bybit — narzucają rygorystyczne limity rate-limit, blokady geograficzne i eskalację od 429 Too Many Requests do 451 Unavailable For Legal Reasons. Jednocześnie dane on-chain dostępne przez węzły RPC (Alchemy, Infura, QuickNode) podlegają zupełnie innym ograniczeniom.
Rozróżnienie między tymi dwoma źródłami danych jest krytyczne dla architektury. Zastosowanie proxy tam, gdzie nie jest potrzebne, dodaje niepotrzebną latencję. Pominięcie proxy tam, gdzie jest niezbędne, kończy się banem IP i przerwaniem strumienia danych.
On-chain vs CEX: dwie różne domeny danych
Zanim przejdziemy do implementacji, musimy jasno zdefiniować, czym różnią się te dwa światy i dlaczego wymagają odmiennego podejścia do proxy.
Dane on-chain — świat RPC i indexerów
Dane on-chain obejmują stany kont, salda, transakcje, logi smart kontraktów, zdarzenia DEX (swapy, pule płynności). Dostęp do nich uzyskujesz przez:
- Węzły RPC — Alchemy, Infura, QuickNode, Ankr. Udostępniają JSON-RPC endpointy do czytania stanu blockchainu.
- Indexery — The Graph, Envio, Subsquid. Indeksują zdarzenia on-chain i udostępniają je przez GraphQL.
- Własne węzły — pełne archive nodes dla Ethereum, Solana, etc.
Dla danych on-chain residential proxies zazwyczaj nie są potrzebne. Dostawcy RPC sami zarządzają infrastrukturą, rate-limitingiem i redundancją. Jedynym scenariuszem, w którym proxy może pomóc, jest zwiększenie throughput przez dywersyfikację IP przy intensywnym odpytywaniu publicznych endpointów RPC, lub ominięcie regionalnych bottlenecków.
Dane CEX — świat REST, WebSocket i geo-restrykcji
Dane z centralizowanych giełd obejmują:
- Price feeds — aktualne ceny, 24h tickery, kandle OHLCV.
- Orderbook snapshots — głębokość rynku, bid/ask, spread.
- Funding rates — stawki finansowania perpów, kluczowe dla strategii basis trade.
- Liquidations — zdarzenia likwidacji, dane z orderbooków liquidacji.
- Trade history — historyczne transakcje, tick-by-tick.
To właśnie przy CEX scraping residential proxies stają się krytyczne — z powodów rate-limit, geo-restrykcji i eskalacji błędów, które omówimy szczegółowo.
| Aspekt | Dane on-chain (RPC) | Dane CEX (API + web) |
|---|---|---|
| Rate-limit | Wewnętrzny dostawcy RPC (compute units) | IP-based, per-endpoint, agresywny |
| Geo-restrykcje | Rzadko | Częste (Binance US, OKX restricted jurisdictions) |
| Format danych | JSON-RPC, subscriptions | REST, WebSocket, FIX (rzadko) |
| Potrzeba proxy | Zazwyczaj nie | Tak — residential/mobile |
| Integrność danych | Finality blockchainu, timestamps bloków | Exchange timestamps, sekwencja WS messages |
Dlaczego residential proxies są niezbędne dla CEX scraping
IP-based rate limiting na publicznych endpointach
Większość CEX stosuje IP-based rate limiting na publicznych endpointach API. Binance — 1200 req/min dla większości endpointów, 10 req/min dla orderbook depth. Coinbase — 10 req/s public, 30 req/s authenticated. OKX — 20 req/s na IP. Bybit — 120 req/min na IP dla public market data.
Przy architekturze wieloparowej, zbierającej dane z dziesiątek par jednocześnie, te limity wyczerpują się błyskawicznie. Rotacja IP przez residential proxy pozwala dystrybuować żądania po wielu adresach, zachowując limity per-IP bez throttlingu.
Geo-restrykcje: od 403 do 451
Binance blokuje adresy IP z USA — zwraca 451 Unavailable For Legal Reasons. Coinbase ogranicza niektóre funkcje dla IP z restricted jurisdictions. OKX i Bybit mają podobne polityki.
Eskalacja jest przewidywalna: najpierw 429 Too Many Requests (przekroczony rate limit), potem 403 Forbidden (IP oflagowane), wreszcie 451 (geo-ban prawny). Residential proxy z odpowiednim geo-targetingiem omija te ograniczenia, bo giełda widzi IP z dozwolonego jurisdiction.
Kluczowa zasada: residential proxy nie jest po to, by łamać prawo — jest po to, by uzyskać dostęp do publicznie dostępnych danych rynkowych z jurisdiction, w których giełda je udostępnia. Jeśli Twoja lokalizacja prawna nie pozwala na dostęp do danych z danej giełdy, nie używaj proxy do ominięcia tej restrykcji.
Integrność danych i timestamps
W finansach crypto timestamps są krytyczne. Exchange timestamps vs lokalne timestamps vs block timestamps — każde źródło ma inną semantykę czasową. Przy architekturze z proxy musisz:
- Zapisywać exchange timestamp z odpowiedzi API (nie polegać na lokalnym zegarze).
- Monitorować latencję proxy — opóźnienie może zaburzyć sekwencję eventów.
- Gwarantować sequence integrity — WebSocket messages muszą być przetwarzane w kolejności odbioru.
On-chain: kiedy proxy mogą pomóc, a kiedy są zbędne
Jak wspomnieliśmy, dane on-chain zazwyczaj nie wymagają proxy. Dostawcy RPC (Alchemy, Infura, QuickNode) zarządzają infrastrukturą i oferują tier-based rate limiting oparty na compute units, nie na IP.
Są jednak scenariusze, w których proxy on-chain mogą być przydatne:
- Publiczne RPC endpointy — darmowe endpointy (np. public Ethereum RPC) mają bardzo niskie limity. Rotacja IP przez proxy zwiększa throughput.
- Geo-dystrybucja — niektóre regiony mają wyższą latencję do konkretnych węzłów RPC. Proxy w regionie blisko węzła obniża latencję.
- Redundancja — jeśli jeden dostawca RPC ma outage, proxy pozwala przełączyć się na inny endpoint bez zmiany kodu.
Architektura: WebSocket-first z REST fallback i rotacją proxy
Najlepsza architektura dla crypto market data scraping łączy WebSocket dla danych real-time z REST jako fallback i źródłem danych historycznych. Proxy wchodzi w grę głównie w warstwie REST.
Warstwa WebSocket — real-time bez proxy
Większość CEX udostępnia publiczne WebSocket endpointy dla streamowania danych: Binance (wss://stream.binance.com:9443), OKX (wss://ws.okx.com:8443), Bybit (wss://stream.bybit.com/v5/public/spot). Połączenia WS są long-lived — nie potrzebujesz rotacji IP, bo jedno połączenie utrzymuje stream bez rate-limitingu.
Wyzwania WS: reconnection, ping/pong, sequence gaps. Musisz monitorować lastUpdateId (Binance) lub seqNum (OKX), aby wykrywać luki i re-synchronizować z REST.
Warstwa REST — snapshoty i historia z rotacją proxy
REST jest potrzebny dla: snapshotów orderbook, historycznych kandli, funding rates, danych o likwidacjach. Tutaj rate-limiting IP-based uderza najmocniej. Rotacja residential proxy pozwala dystrybuować żądania.
Implementacja w Pythonie
Poniższy przykład pokazuje architekturę REST z rotacją proxy przez ProxyHat dla pobierania orderbook snapshots z Binance:
import requests
import time
from itertools import cycle
# ProxyHat residential proxy z geo-targetingiem
# Binance wymaga IP spoza USA — używamy EU
PROXY_URL = "http://user-country-DE:PASSWORD@gate.proxyhat.com:8080"
proxies = {
"http": PROXY_URL,
"https": PROXY_URL,
}
def fetch_binance_orderbook(symbol: str, limit: int = 100) -> dict:
"""Pobierz orderbook snapshot przez residential proxy."""
url = "https://api.binance.com/api/v3/depth"
params = {"symbol": symbol, "limit": limit}
for attempt in range(3):
try:
resp = requests.get(
url, params=params, proxies=proxies, timeout=10
)
resp.raise_for_status()
data = resp.json()
# Zapisz exchange timestamp dla integrności danych
data["_fetched_at"] = time.time()
data["_proxy_country"] = "DE"
return data
except requests.exceptions.HTTPError as e:
if resp.status_code == 429:
wait = int(resp.headers.get("Retry-After", 60))
print(f"Rate limited. Waiting {wait}s...")
time.sleep(wait)
elif resp.status_code == 451:
print("Geo-blocked. Switching proxy country...")
# Przełącz na inne geo — np. JP dla SEA exchanges
break
else:
raise
return {}
# Pobieranie dla wielu par z zachowaniem limitów
pairs = ["BTCUSDT", "ETHUSDT", "SOLUSDT", "DOGEUSDT"]
for pair in pairs:
book = fetch_binance_orderbook(pair)
print(f"{pair}: bid={book['bids'][0]} ask={book['asks'][0]}")
time.sleep(0.5) # Szacunek dla rate limitNode.js: WebSocket + REST z proxy
Dla architektury WebSocket-first z REST fallback w Node.js:
const WebSocket = require('ws');
const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');
// ProxyHat — geo-targeted dla Binance (EU)
const proxyAgent = new HttpsProxyAgent(
'http://user-country-DE:PASSWORD@gate.proxyhat.com:8080'
);
// 1. WebSocket stream — real-time, bez proxy
const ws = new WebSocket('wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms');
let lastUpdateId = null;
ws.on('message', (data) => {
const parsed = JSON.parse(data);
lastUpdateId = parsed.lastUpdateId;
console.log(`WS depth: bid=${parsed.bids[0]} ask=${parsed.asks[0]}`);
});
ws.on('error', (err) => {
console.error('WS error, falling back to REST:', err.message);
fetchRestSnapshot();
});
// 2. REST fallback — z residential proxy
async function fetchRestSnapshot() {
try {
const resp = await axios.get(
'https://api.binance.com/api/v3/depth',
{
params: { symbol: 'BTCUSDT', limit: 20 },
httpsAgent: proxyAgent,
timeout: 10000,
}
);
console.log(`REST snapshot: lastUpdateId=${resp.data.lastUpdateId}`);
return resp.data;
} catch (err) {
if (err.response?.status === 429) {
const retryAfter = err.response.headers['retry-after'] || 60;
console.log(`Rate limited. Retry after ${retryAfter}s`);
}
if (err.response?.status === 451) {
console.error('Geo-blocked — switch proxy jurisdiction');
}
throw err;
}
}
// 3. Re-synchronizacja: porównaj WS lastUpdateId z REST
async function resync() {
const restData = await fetchRestSnapshot();
if (restData.lastUpdateId > lastUpdateId) {
console.log('Gap detected — REST snapshot is ahead. Re-syncing...');
lastUpdateId = restData.lastUpdateId;
}
}Kwestie latencji: wybór regionu proxy ma znaczenie
W tradingu krypto latencja jest walutą. 50ms opóźnienia może oznaczać missed fill lub stary funding rate. Wybór regionu proxy musi uwzględniać lokalizację serwerów giełdy.
Lokalizacje serwerów CEX
- Binance — głównie AWS Tokyo (ap-northeast-1) i AWS Singapore. Niektóre endpointy EU (aws-eu-west-1).
- Coinbase — AWS US-East (us-east-1), głównie Virginia.
- OKX — AWS Hong Kong / Singapore.
- Bybit — AWS Singapore, z secondary w EU.
Strategia geo-proxy
| Giełda | Region serwera | Optymalny region proxy | ProxyHat geo-flag |
|---|---|---|---|
| Binance | Tokyo / Singapore | JP, SG, HK | country-JP, country-SG |
| Coinbase | US-East (Virginia) | US | country-US |
| OKX | HK / Singapore | HK, SG, JP | country-HK, country-SG |
| Bybit | Singapore | SG, JP, HK | country-SG |
Uwaga: Coinbase jest US-based i nie blokuje IP z USA — wręcz przeciwnie, jest najbardziej przyjazny dla IP z USA. Dla Coinbase używaj country-US.
Dla Binance, który blokuje US IP, używaj EU lub SEA proxy. EU (np. DE, NL) jest bezpiecznym wyborem z niską latencją do endpointów EU Binance. JP i SG dają najniższą latencję do endpointów azjatyckich.
Sticky sessions vs per-request rotation
Dla WebSocket — używaj sticky sessions (ProxyHat: user-session-SESSION_ID), bo jedno długie połączenie WS nie wymaga rotacji IP. Dla REST — per-request rotation jest lepsza, bo dystrybuuje żądania po wielu IP.
# Sticky session dla WebSocket (long-lived)
# http://user-country-JP-session-ws-btc-001:PASSWORD@gate.proxyhat.com:8080
# Per-request rotation dla REST (nowe IP każde żądanie)
# http://user-country-DE:PASSWORD@gate.proxyhat.com:8080Funding rates i liquidations: dane krytyczne dla strategii quant
Funding rates i dane o likwidacjach są szczególnie wrażliwe na jakość danych i timeliness:
- Funding rates — aktualizowane co 8h (Binance) lub co 1h (OKX). REST endpoint z proxy rotation zapewnia dostęp bez rate-limitingu.
- Liquidations — Binance udostępnia WebSocket stream forced liquidations (
@forceOrder), ale historyczne dane wymagają REST z agresywnym rate-limitingiem.
curl: funding rates przez ProxyHat
# Binance funding rate — EU proxy, omija US geo-block
curl -x http://user-country-DE:PASSWORD@gate.proxyhat.com:8080 \
"https://fapi.binance.com/fapi/v1/fundingRate?symbol=BTCUSDT&limit=100"
# OKX funding rate — HK proxy dla najniższej latencji
curl -x http://user-country-HK:PASSWORD@gate.proxyhat.com:8080 \
"https://www.okx.com/api/v5/public/funding-rate-all"
# Bybit liquidation — SG proxy
curl -x http://user-country-SG:PASSWORD@gate.proxyhat.com:8080 \
"https://api.bybit.com/v5/market/liquidation?category=linear&symbol=BTCUSDT"Aspekty regulacyjne: TOS, geo-restrykcje i prawo lokalne
To najważniejsza sekcja tego przewodnika. Używanie proxy do dostępu do danych giełdowych niesie ryzyka regulacyjne, które musisz zrozumieć.
Terms of Service giełd
Większość CEX w swoich TOS zabrania:
- Scrapowania danych w sposób, który obciąża infrastrukturę giełdy.
- Używania VPN/proxy do ominięcia geo-restrykcji w jurysdykcjach, gdzie giełda nie jest zarejestrowana.
- Redystrybucji danych rynkowych bez licencji (market data licensing).
Praktycznie jednak, giełdy tolerują umiarkowane scraping publicznych danych — ich własne API jest zaprojektowane do tego celu. Kluczowe jest nie przekraczanie rate limitów i nie obciążanie infrastruktury. Proxy pomaga właśnie w tym: dystrybuje load, zamiast go koncentrować.
SEC, MiFID II i licencje market-data
Jeśli redystrybuujesz dane rynkowe (np. jako SaaS market-data service), musisz rozważyć:
- SEC (USA) — dane z Coinbase i innych US-regulated exchanges mogą podlegać wymogom licencjonowania market-data.
- MiFID II (UE) — podobne wymogi dla danych z regulated venues w Europie.
- Exchange-specific licenses — Binance, OKX, Bybit mają własne programy licencjonowania danych.
Używanie proxy do ominięcia geo-restrykcji giełdy nie jest tym samym co łamanie lokalnego prawa. Jeśli jesteś podmiotem z UE i chcesz dostęp do publicznych danych Binance (które są dostępne w UE), proxy z EU IP jest legalne. Jeśli jesteś podmiotem z USA i używasz proxy do ominięcia blokady Binance na US IP — to może naruszać zarówno TOS Binance, jak i regulacje US (CFTC, SEC).
Najlepsze praktyki compliance
- Używaj proxy z jurysdykcji, w której giełda legalnie operuje i w której Ty masz prawo dostępu.
- Nie redystrybuuj danych bez właściwych licencji market-data.
- Zapisuj audit trail — timestamps, proxy IP, exchange response headers — dla compliance.
- Szanuj robots.txt i rate-limits — proxy nie jest po to, by je łamać, ale by dystrybuować load.
On-chain data: RPC providers i kiedy proxy pomagają
Dla kompletności — krótki przegląd podejścia on-chain:
- Alchemy / Infura / QuickNode — oferują tiered plans z compute units. Rate-limit oparty na CUs, nie na IP. Proxy zazwyczaj niepotrzebne.
- Publiczne RPC — Chainlist, Ankr public endpoints. Agresywny rate-limit per-IP. Proxy z rotacją może zwiększyć throughput.
- Własne węzły — pełna kontrola, brak rate-limit. Zero potrzeby proxy.
Scenariusz, w którym proxy on-chain ma sens: intensywne backfilling historycznych danych (np. wszystkie logi Uniswap V3 od bloku 12345678) przez publiczny RPC. Rotacja IP pozwala ominąć per-IP limit bez płacenia za premium tier.
Kluczowe wnioski
- On-chain ≠ CEX — dane on-chain (RPC) rzadko potrzebują proxy; dane CEX (REST API) ich wymagają.
- WebSocket-first — dla real-time danych używaj WS bez proxy; REST z proxy jako fallback i źródło historycznych danych.
- Geo-targeting ma znaczenie — Binance blokuje US IP, używaj EU/SEA proxy. Coinbase potrzebuje US IP.
- Latencja = waluta — wybieraj region proxy blisko serwerów giełdy (JP/SG dla Binance/OKX, US dla Coinbase).
- Compliance first — nie używaj proxy do ominięcia geo-restrykcji w sposób naruszający lokalne prawo. Używaj z jurysdykcji, gdzie dostęp jest legalny.
- Integrność danych — zawsze zapisuj exchange timestamps, monitoruj sequence gaps, audituj proxy latencję.
ProxyHat oferuje residential proxies z geo-targetingiem w ponad 190 krajach — idealne dla architektur crypto market data scraping, które wymagają dystrybucji IP i niskiej latencji. Sprawdź dostępne lokalizacje i plany cenowe, aby dopasować infrastrukturę do potrzeb Twojego zespołu quant.
