trade-frontend/doc/drift-data-bez-solana-rpc.md

Drift / Solana: czy mamy dostęp do danych bez Solana RPC?

Pytanie ma dwa znaczenia — rozdzielmy je jasno:

1. bez własnego (bare metal) RPC — czyli nie utrzymujemy swojego solana-validator --rpc, ale korzystamy z dostawcy RPC albo zewnętrznych serwisów,
2. bez żadnego RPC w ogóle — czyli nikt w naszym systemie nie pyta Solany o stan on‑chain.

TL;DR:

• Bez własnego RPC: tak, da się na start (hosted RPC +/lub serwisy zewnętrzne).
• Bez żadnego RPC: tylko częściowo (dane “rynkowe” można brać z zewnętrznego DLOB), ale stan konta/pozycji/fille/funding i tak pochodzi z chaina, więc ktoś musi mieć RPC.

---

Co z Twojego “speca” da się mieć bez własnego RPC?

Poniżej mapowanie kategorii danych (z Twojego opisu A–F) na źródła:

B) Prices / microstructure (oracle/mark/BBO, “close now”)

Da się bez własnego RPC:

• Tak. W naszym stacku te dane mogą pochodzić z pipeline DLOB (dlob_*_latest) i ticków (drift_ticks), które są już w DB i dostępne przez Hasurę / trade-api.

Da się bez żadnego RPC w naszej infra (czyli “my nie łączymy się do RPC”):

• Częściowo tak, jeśli polegamy na zewnętrznym źródle L2/BBO (np. https://dlob.drift.trade) — ale to źródło i tak jest zasilane przez czyjeś RPC.

A) Position snapshot (pozycja: base, entry, side)

Bez własnego RPC:

• Tak, jeśli mamy jakikolwiek komponent (executor/collector) korzystający z hosted RPC (Helius/QuickNode/itp.) i zapisujący snapshot pozycji do DB.

Bez żadnego RPC:

• Praktycznie nie (pozycja jest stanem konta on‑chain). Wyjątek: jeśli Twój executor/bot sam utrzymuje lokalny stan i zapisuje go do DB — ale po restarcie i tak potrzebujesz reconcile z chaina (czyli RPC).

C) Account risk (margin/liquidation/health)

Bez własnego RPC:

• Tak, jeśli collector liczy to na backendzie z danych Drift (przez hosted RPC) i zapisuje do TS (contract_metrics_ts / analogicznie).

Bez żadnego RPC:

• Nie, bo margin/liq zależy od stanu konta i parametrów rynku on‑chain.

D) Fills / trades (realized PnL + fees + slippage)

Bez własnego RPC:

• Tak, jeśli:
  • executor składa zlecenia i loguje fille do bot_events (to już mamy jako koncept), albo
  • collector subskrybuje eventy transakcji / kont przez hosted RPC i zapisuje fille do DB.

Bez żadnego RPC:

• Tylko jeśli fille są już zapisane w DB (np. przez bota). Na bieżąco — ktoś musi je wyciągać z chaina.

E) Funding / payments

Bez własnego RPC:

• Tak, ale ktoś musi pobierać funding rate / funding payment (hosted RPC lub inny feed) i zapisywać do DB.

Bez żadnego RPC:

• Jak wyżej: tylko z historii zapisanej w DB; na żywo potrzebujesz źródła z chaina.

F) Order lifecycle costs (cancel/replace/tx)

Bez własnego RPC:

• Tak, jeśli executor:
  • loguje akcje (create/cancel/replace) i ich koszty (tx_fee_usd, priority fee) do bot_events, albo
  • collector wyciąga metryki tx z RPC i mapuje do orderów.

Bez żadnego RPC:

• Tylko retrospektywnie (jeśli już w DB).

---

Co to znaczy praktycznie dla architektury “backend liczy, UI tylko wyświetla”?

UI/Visualizer może działać bez bezpośredniego kontaktu z RPC (łączy się do trade-api + Hasura).

Natomiast backend “compute” (k3s) ma dwie opcje zasilania:

1. Hosted RPC (na start)

   • pro: szybciej, taniej, mniej ops,
   • con: limit subskrypcji/WS, możliwe rwania, vendor lock‑in.

2. Własny RPC + Geyser/Yellowstone (docelowo)

   • pro: kontrola, stabilność na większej skali, streaming “pro”,
   • con: koszt i ops (dyski/IO, tuning, monitoring).

W obu przypadkach “backend liczy” działa tak samo — różni się tylko źródło surowych danych.

---

Co już mamy w DB “bez RPC w UI”

Z obecnego pipeline (VPS/k3s) mamy “rynkowe” dane pod BBO/slippage:

• dlob_l2_latest, dlob_stats_latest, dlob_slippage_latest, dlob_depth_bps_latest (+ TS przez *_ts)
• drift_ticks (ticki/ceny)

To wystarcza do:

• estymat wejścia/wyjścia (“close now”),
• wykresów spread/slippage/depth,
• części SIM (model slippage/fee) bez znajomości pełnego stanu konta.

Do pełnego contract_metrics_ts (PnL + risk) brakuje nam jeszcze stałego feedu:

• pozycji konta + margin/liq,
• filli i funding (albo z chaina, albo z logów executora).

Zobacz też

• “Kanoniczna” architektura w pełni self-hosted (RPC + DLOB): doc/rpc-dlob-kanoniczna-architektura.md
• Runbook: bare metal RPC + Geyser/Yellowstone gRPC: doc/solana-rpc-geyser-setup.md
• Mapa dokumentów o RPC/DLOB/metrykach: doc/solana-rpc.md