Proxy dla danych rynkowych krypto: architektura, wymogi regulacyjne i niska latencja

Dlaczego crypto market data scraping wymaga innej architektury

Zespoły quant i serwisy analityczne operują na dwóch zupełnie różnych typach danych: on-chain (blockchain-native) i exchange (CEX API + web). Błąd polegający na traktowaniu ich tak samo — ten sam klient, ta sama rotacja IP, te same założenia o latencji — kosztuje milisekundy na orderbooku i naraża na bany IP na publicznych endpointach.

W tym przewodniku rozdzielamy te dwa światy wyraźnie. Pokazujemy, gdzie residential proxy jest krytyczne, gdzie wystarczy RPC provider, i jak zbudować architekturę, która jest jednocześnie szybka, niezawodna i zgodna z regulacjami.

Dwa światy danych: on-chain vs exchange

Zanim przejdziemy do implementacji, musimy zrozumieć fundamentalną różnicę między tymi dwoma źródłami danych — ponieważ determinuje ona całą architekturę pobierania.

Dane on-chain: RPC nodes i indexery

Dane on-chain pochodzą bezpośrednio z blockchaina — transakcje, zdarzenia smart kontraktów, stany kont. Dostęp uzyskujesz przez RPC endpointy (Alchemy, Infura, QuickNode) lub dedykowane indexery (The Graph, Envio). Te dane są publiczne i niemożliwe do ocenzurowania — każdy węzeł utrzymuje pełną kopię historii.

Kluczowa konsekwencja: proxy residential zazwyczaj nie jest potrzebne do pobierania danych on-chain. RPC provider sam zarządza rate-limitami i autoryzacją. Wyjątkiem są sytuacje, gdy potrzebujesz wyższej przepustowości niż oferuje Twój plan, lub gdy geo-routing może poprawić latencję do konkretnego węzła.

Dane exchange: CEX APIs i web scraping

Dane z giełd centralizowanych — price feeds, orderbooki, funding rates, liquidacje — pochodzą z REST API i WebSocketów giełd (Binance, Coinbase, OKX, Bybit). Te dane są kontrolowane przez giełdę, która może ograniczać dostęp na podstawie IP, lokalizacji i wzorca ruchu.

Tutaj residential i mobile proxy stają się niezbędne. Giełdy aktywnie blokują ruch wyglądający na automatyczny — i to jest główny problem, który rozwiązujemy w tym artykule.

Aspekt	Dane on-chain (RPC)	Dane exchange (CEX)
Źródło	Blockchain node / indexer	REST API / WebSocket / HTML
Potrzeba proxy	Rzadko (tylko throughput)	Często (rate-limits, geo)
Rate-limiting	Plan RPC providera	IP-based, per-endpoint
Geo-blokady	Brak	Częste (np. Binance US)
Integralność danych	Kryptograficzna (hash bloku)	Wymaga timestamp + weryfikacji
Latencja krytyczna	Medium (finality)	Wysoka (arbitraż, liquidacje)

Dlaczego residential proxy jest krytyczne dla CEX scraping

Giełdy krypto stosują wielowarstwowe mechanizmy obronne. Zrozumienie ich jest kluczowe, bo każda warstwa wymaga innej strategii omijania.

IP-based rate-limits na publicznych endpointach

Większość giełd limituje liczbę żądań na IP. Binance REST API pozwala na 1200 żądań/minutę na wagę — ale waga zależy od endpointu. Orderbook snapshot waży 5, ale historia transakcji może ważyć 20. Szybko osiągasz limit, zwłaszcza przy zbiorczym pobieraniu danych historycznych.

Co gorsza, giełdy często nie resetują liczników po 429. Eskalacja wygląda typowo tak:

• 429 Too Many Requests — tymczasowy ban, zwykle 1-10 minut
• 418 I'm a teapot — Binance specyficzny, oznacza auto-ban na rosnący czas
• 451 Unavailable For Legal Reasons — geo-blokada, nie przejdzie bez odpowiedniego IP

Geo-restrykcje i ich omijanie

Binance blokuje IP z USA. OKX ogranicza dostęp z niektórych jurysdykcji. Coinbase ma osobny produkt dla użytkowników amerykańskich. Dla zespołu quant w Warszawie, który potrzebuje danych ze wszystkich giełd, residential proxy z odpowiednim geo-targetingiem jest jedyną opcją.

Uwaga regulacyjna: Omijanie geo-blokad giełdy może naruszać jej regulamin, ale samo korzystanie z proxy nie jest nielegalne. Problemem jest m.in. naruszenie lokalnych praw papierów wartościowych (SEC w USA, MiFID II w UE). Omawiamy to szczegółowo w sekcji regulacyjnej poniżej.

Wzorzec ruchu i fingerprinting

Zaawansowane giełdy analizują nie tylko liczbę żądań, ale też wzorzec: nagłówki, kolejność, interwały. Datacenter IP z regularnymi interwałami = oczywisty bot. Residential proxy z naturalną rotacją i jitter znacznie zmniejsza ryzyko detekcji.

Architektura: WebSocket-first z REST fallback

Najczęstszy błąd początkujących zespołów quant: scrapowanie REST API tam, gdzie giełda udostępnia publiczny WebSocket. WebSockety dają dane w czasie rzeczywistym z minimalną latencją i nie wymagają rotacji IP tak agresywnej jak REST.

Strategia dwuwarstwowa

1. Warstwa real-time: WebSocket dla orderbook updates, trades, funding rates. Jedno połączenie WS utrzymuje strumień — rotacja IP potrzebna tylko przy reconnect.
2. Warstwa historyczna: REST API z proxy rotation dla backfillu danych historycznych, snapshotów orderbook, historia liquidacji.

Przykładowa implementacja w Pythonie — REST fallback z rotacją proxy:

import requests
import time
from itertools import cycle

# ProxyHat residential proxy z geo-targetingiem
PROXIES = cycle([
    {"http": "http://user-country-US:PASSWORD@gate.proxyhat.com:8080",
     "https": "http://user-country-US:PASSWORD@gate.proxyhat.com:8080"},
    {"http": "http://user-country-SG:PASSWORD@gate.proxyhat.com:8080",
     "https": "http://user-country-SG:PASSWORD@gate.proxyhat.com:8080"},
])

def fetch_binance_orderbook(symbol="BTCUSDT", limit=100):
    url = f"https://api.binance.com/api/v3/depth"
    params = {"symbol": symbol, "limit": limit}
    proxy = next(PROXIES)
    
    for attempt in range(3):
        try:
            resp = requests.get(url, params=params, proxies=proxy, timeout=10)
            resp.raise_for_status()
            data = resp.json()
            # Zachowaj timestamp dla integralności danych
            data["fetch_timestamp_ms"] = int(time.time() * 1000)
            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(f"Geo-blocked on attempt {attempt}. Rotating IP.")
                proxy = next(PROXIES)
            else:
                raise
    return None

WebSocket dla danych real-time

Dla orderbook streaming, WebSocket jest standardem. Oto przykład nasłuchiwania na Binance:

import asyncio
import json
import websockets

async def stream_binance_trades(symbol="btcusdt"):
    url = f"wss://stream.binance.com:9443/ws/{symbol}@trade"
    
    # Uwaga: WebSocket nie przechodzi przez HTTP proxy w standardowy sposób.
    # Dla geo-targeting, uruchom klienta na serwerze w docelowej lokalizacji
    # lub użyj SOCKS5 proxy:
    proxy = "socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080"
    
    async with websockets.connect(
        url,
        proxy=proxy,
        ping_interval=20,
        ping_timeout=10
    ) as ws:
        async for message in ws:
            trade = json.loads(message)
            # Timestamp z giełdy + lokalny dla integralności
            trade["local_recv_ms"] = int(time.time() * 1000)
            yield trade

asyncio.run(stream_binance_trades())

Dane on-chain: kiedy proxy ma sens

Jak wspomnieliśmy, dane on-chain zazwyczaj nie wymagają proxy. RPC provider (Alchemy, Infura, QuickNode) zarządza dostępem przez API keys i plany taryfowe. Ale są scenariusze, gdzie proxy pomaga:

Przepustowość i geo-routing

Niektórzy providerzy limitują requesty per IP per plan. Jeśli potrzebujesz 10x więcej niż pozwala Twój plan, residential proxy z rotacją może rozłożyć load na wiele IP. Dodatkowo, geo-routing do węzłów bliżej RPC endpointu może zmniejszyć latencję o 20-50ms — krytyczne przy MEV i arbitrażu.

Redundancja RPC

Jeśli główny RPC provider ma outage, możesz przełączyć się na publiczne RPC z proxy rotation. Nie jest to zalecane jako primary architecture, ale jako fallback:

# curl — fallback do publicznego RPC przez ProxyHat
curl -x http://user-country-DE:PASSWORD@gate.proxyhat.com:8080 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  https://rpc.ankr.com/eth

Indexery: The Graph i alternatywy

Dla złożonych zapytań on-chain (np. historia liquidacji DeFi), indexery jak The Graph są wydajniejsze niż bezpośrednie RPC. Też używają API keys i nie wymagają proxy — ale ich publiczne endpointy mogą mieć agresywne rate-limity, gdzie residential proxy pomoże przy masowym pobieraniu danych historycznych.

Latencja: wybór lokalizacji proxy ma znaczenie

W tradingu krypto milisekundy decydują o zysku lub stracie. Wybór lokalizacji proxy jest tak samo ważny jak wybór samego proxy.

Mapowanie giełda → lokalizacja proxy

• Binance (global): Serwery głównie w Singapurze i Tokio. Użyj proxy w SEA — user-country-SG lub user-country-JP.
• Coinbase: Serwery w USA. Użyj proxy US — user-country-US.
• OKX: Serwery w Hongkongu i Singapurze. Użyj proxy SEA.
• Bybit: Serwery w Singapurze. Użyj proxy SEA.
• Kraken: Serwery w USA i UE. Użyj proxy user-country-US lub user-country-DE.

Kluczowa zasada: proxy powinno być blisko serwerów giełdy, nie blisko Ciebie. Jeśli scrapujesz Binance z Warszawy przez proxy w Polsce, Twój ruch idzie PL → proxy PL → serwer SG. Lepiej: PL → proxy SG → serwer SG.

Sticky sessions dla WebSocket

WebSocket wymaga trwałego połączenia. Rotacja IP w trakcie sesji = disconnect. Dlatego używaj sticky sessions z ProxyHat:

# Sticky session — IP się nie zmienia przez sesję
proxy_url = "http://user-session-myws1234-country-SG:PASSWORD@gate.proxyhat.com:8080"

# W Node.js z biblioteką ws:
import WebSocket from 'ws';
import { SocksProxyAgent } from 'socks-proxy-agent';

const agent = new SocksProxyAgent(
  'socks5://user-session-myws1234-country-SG:PASSWORD@gate.proxyhat.com:1080'
);

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

ws.on('message', (data) => {
  const msg = JSON.parse(data);
  console.log(`Bid: ${msg.bids[0]}, Ask: ${msg.asks[0]}`);
});

Integralność danych: timestamps, sekwencje, weryfikacja

W finansach integralność danych jest nienegocjowalna. Każdy rekord musi mieć:

• Exchange timestamp — czas giełdy, zwracany w odpowiedzi API.
• Local receive timestamp — czas przyjęcia na Twoim serwerze. Różnica (latencja) jest metryką jakości.
• Sequence number — dla orderbook updates. Jeśli luka w sekwencji, musisz zrekonstruować orderbook od zera (full snapshot).

Garantowanie sekwencji

Binance WebSocket wysyła u (last update ID) i U (first update ID). Jeśli U poprzedniego update ≠ u następnego + 1, masz lukę. Algorytm:

1. Pobierz REST snapshot z lastUpdateId.
2. Nasłuchuj WS. Odrzuć wszystkie update gdzie U ≤ lastUpdateId.
3. Pierwszy przetworzony update musi mieć U = lastUpdateId + 1.
4. Każdy kolejny: prevU + 1 = U. Jeśli nie — full resync.

To jest krytyczne dla quant teams. Błędny orderbook = błędne sygnały = straty.

Aspekt regulacyjny: TOS, geo-restrykcje, prawo lokalne

Omijanie geo-blokad giełdy to nie tylko kwestia techniczna. Jest tu kilka warstw regulacyjnych, które musisz rozważyć.

Regulaminy giełd (TOS)

Większość giełd w regulaminie zabrania:

• Scrapowania danych bez zezwolenia API.
• Omijania geo-restrykcji.
• Używania automatycznych systemów obciążających infrastrukturę.

Praktyka: giełdy rzadko ścigają za scrapowanie danych rynkowych (to nie dane osobowe), ale mogą zbanować konto i IP. Jeśli zależy Ci na ciągłości dostępu, rozważ oficjalne API z odpowiednim planem.

SEC, MiFID II i licencje na dane rynkowe

W USA, dane rynkowe z regulowanych giełd mogą podlegać licencjom (SIP, CTA). W UE, MiFID II wymaga, aby dostawcy danych rynkowych mieli odpowiednie licencje. Dla krypto, sytuacja jest szara — ale jeśli oferujesz dane jako usługa, konsultuj się z prawnikiem.

GDPR i dane osobowe

Dane rynkowe (ceny, wolumeny, orderbooki) nie są danymi osobowymi. Ale jeśli scrapujesz profile użytkowników, komentarze, czy dane KYC — GDPR ma zastosowanie. Nie rob tego bez podstawy prawnej.

Złota zasada: scrapuj dane rynkowe (publiczne), nie dane użytkowników (prywatne). I zawsze konsultuj się z radcą prawnym, jeśli udostępniasz dane komercyjnie.

Funding rates, liquidacje i inne trudne endpointy

Nie wszystkie dane są równe. Niektóre endpointy są szczególnie agresywnie rate-limitowane lub wymagają autoryzacji.

Funding rates

Funding rates są kluczowe dla strategii perpetual arbitrage. Binance pozwala na pobranie historycznych funding rates przez /fapi/v1/fundingRate, ale limit wagi to 30 per request. Przy 100+ parach i 90-dniowej historii, szybko osiągasz limity.

Rozwiązanie: residential proxy rotation z interwałami 200-300ms między requestami. Nie burstuj — rozłóż load równomiernie.

Liquidacje

Dane o liquidacjach są dostępne przez WS (@forceOrder na Binance) i REST. Są bardzo popularne wśród quant teams i mocno rate-limitowane. Użyj sticky session WS + REST fallback z rotacją.

Key Takeaways

• Dwa światy, dwie architektury: on-chain = RPC provider (proxy rzadko potrzebne), exchange = residential proxy (często niezbędne).
• WebSocket-first: dla real-time danych używaj WS ze sticky session. REST z rotacją proxy tylko do backfillu i snapshotów.
• Geo-targeting = latencja: proxy blisko serwerów giełdy, nie blisko Ciebie. SG dla Binance/OKX, US dla Coinbase.
• Integralność danych: zawsze zapisuj exchange timestamp + local receive timestamp. Weryfikuj sekwencje orderbook updates.
• Regulacje: scrapuj dane publiczne, nie prywatne. Konsultuj TOS i prawo lokalne, zwłaszcza przy komercyjnym redystrybuowaniu.
• Rate-limit strategia: nie burstuj, rozłóż load. 429 → czekaj. 451 → rotuj IP. 418 → stop i re-evaluate.

Podsumowanie i następne kroki

Crypto market data scraping wymaga precyzyjnej architektury. Residential proxy jest niezbędne dla danych z CEX — geo-restrykcje i rate-limity są realne i kosztowne. Dla danych on-chain, RPC provider wystarczy w 95% przypadków.

Zacznij od WebSocket dla real-time danych, dodaj REST z ProxyHat rotation dla historycznych, i zawsze weryfikuj integralność danych przez timestamps i sekwencje. Sprawdź plany ProxyHat i dostępne lokalizacje, aby dopasować proxy do swoich potrzeb.

Więcej o strategiach scrapowania znajdziesz w naszym przewodniku web scraping strategie i na stronie use cases.