Files
trade-frontend/doc/rpc-dlob-kanoniczna-architektura.md
2026-02-01 21:44:45 +01:00

3.2 KiB
Raw Permalink Blame History

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 lockin)

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).