116 lines
3.2 KiB
Markdown
116 lines
3.2 KiB
Markdown
# 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).
|
||
|