3.2 KiB
Kanoniczna architektura Drift: własny Solana RPC + własny DLOB
Poniżej jest krótka i konkretna notatka: co da się wyciągnąć z własnego Solana RPC oraz po co jest własny DLOB w kontekście Drift (perp) i metryk pod trading/SIM.
1) Własny Solana RPC — co z niego wyciągniesz
Z własnego RPC (full node, a do backfillu najlepiej archival) możesz pobrać wszystkie dane kontowe i ryzyko.
Dane pozycji i konta (RPC)
- pozycja (long/short, size, entry)
- unrealized PnL
- realized PnL (z konta użytkownika / fills)
- margin, free collateral
- liquidation price
- health / margin ratio
- funding (naliczony + historyczny)
Źródło: konta programu Drift (User, PerpMarket, SpotMarket). Technicznie: subskrypcje kont + (jeśli potrzebne) getProgramAccounts.
Fills / transakcje / fees (RPC)
- fill price
- fee (maker/taker)
- reduce / add
- tx fee + priority fee
Źródła:
- logi transakcji,
- eventy Drift,
- historia transakcji walleta.
Uwaga: backfill 7d+ jest ciężki bez archival RPC, ale nadal wykonalny (koszt/IO/limity).
Ceny (RPC)
- oracle price
- mark price (ze stanu rynku)
W praktyce wystarczy RPC + subskrypcje kont.
2) Własny DLOB — po co i co daje
DLOB jest off-chain, ale jest budowany z on-chain zleceń limit.
Co daje DLOB (i to jest kluczowe do “close now” i slippage):
- best bid / best ask (BBO)
- mid price
- spread
- realistyczny slippage
- sensowne “close now cost” (na podstawie top-of-book / L2)
Bez DLOB zwykle zostaje heurystyka na mark/oracle + założony spread/slippage.
Jak to zrobić praktycznie
Najprostsza opcja to uruchomienie serwisu DLOB (publisher/server) z Drift SDK, który:
- subskrybuje RPC/WS,
- buduje orderbook,
- wystawia API (BBO/depth itp.),
- a worker liczy metryki (spread/depth/slippage) i zapisuje je do DB.
W tym repo mamy opis aktualnego pipeline DLOB w doc/dlob-services.md oraz plan “RPC + Geyser/Yellowstone” w doc/solana-rpc-geyser-setup.md.
3) Mapowanie: metryki → źródło danych
| Metryka | RPC | DLOB |
|---|---|---|
| unrealized PnL | ✅ | ❌ |
| realized / net PnL | ✅ | ❌ |
| fees / funding / tx | ✅ | ❌ |
| margin / liq / health | ✅ | ❌ |
| time in trade | ✅ | ❌ |
| best bid / ask | ❌ | ✅ |
| spread / mid | ❌ | ✅ |
| close now cost | ⚠️ heurystyka | ✅ |
| expected slippage | ⚠️ | ✅ |
4) 100% self-hosted (bez vendor lock‑in)
Da się zrobić w pełni self-hosted (bez Heliusa/cudzych API).
Prosty diagram:
[ Solana RPC (+ WS) ]
↓
[ Drift SDK / subscriptions ]
↓
[ DLOB (publisher/server) ]
↓
[ Worker (metrics TS) ]
↓
[ API / Monitor / SIM ]
↓
[ UI (tylko rysuje) ]
5) Jedyny realny haczyk (operacyjnie)
getProgramAccounts+ websockety wymagają solidnego RPC.- Tanie/limtowane RPC często:
- blokują/limitują GPA,
- ucinają payload,
- dropią WS.
Własny RPC = stabilność i przewidywalność na większej skali.
6) TL;DR
- Tak: wyciągniesz wszystko z własnego RPC + własnego DLOB.
- RPC = pozycja, PnL, ryzyko, funding.
- DLOB = bid/ask, spread, slippage, close-now.
- To pasuje idealnie pod scalping + SIM (backend liczy, UI tylko wyświetla).