# 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`