trade-frontend/doc/trading-readiness.md

Trading readiness (staging → live) — checklista i brakujące elementy

Ten dokument odpowiada na pytanie: czy obecny warsztat jest “już dobry do trade” i co musi być dopięte, zanim przejdziemy z obserwacji do live tradingu.

W skrócie:

• Fundament jest dobry do prototypowania i stagingu.
• Do “pro trading” brakuje kilku krytycznych elementów bezpieczeństwa, audytu i historii danych.

---

1) Co już mamy (mocne strony)

• k3s + GitOps/snapshoty: każdy deploy to snapshot, rollback jednym ruchem (doc/workflow.md).
• DLOB pipeline: orderbook → statsy (spread/depth/slippage) pod UI/strategie (doc/dlob-basics.md, doc/dlob-services.md).
• Ingest ticków do DB: dane rynkowe w Postgres/Timescale + candles przez funkcję (doc/workflow-api-ingest.md).
• UI/Visualizer: warstwy i panele do obserwacji rynku (doc/stats.md).
• Model plane separation: Vast ma robić inference bez sekretów (docelowo) (doc/drift-perp-contract.md + doc/vast-gpu-runbook.md).
• Plan pod własny RPC + streaming: bare metal RPC + Geyser/Yellowstone gRPC (doc/solana-rpc-geyser-setup.md).
• Wyjaśnienie “czy da się bez RPC”: co możemy policzyć z DB i DLOB, a co wymaga feedu on‑chain (doc/drift-data-bez-solana-rpc.md).

To jest wystarczające do:

• obserwacji live,
• strojenia UI,
• budowy i testów pipeline’u danych,
• “paper trading” / dry-run w executorze.

---

2) Co jest krytycznie brakujące do live tradingu

Poniższe punkty są “must‑have” zanim bot zacznie realnie składać zlecenia na Drift.

2.1 Kontrakty bota + audyt (DB)

Wymagane tabele i log:

• bot_contracts (stan kontraktu / desired-state)
• bot_events (decision, order_sent, order_ack, fill, cancel, exit, error, panic)
• mapowanie: decision_id -> client_order_id -> drift_order_id -> tx_sig

Cel:

• da się odtworzyć “co poszło na chain”,
• UI pokazuje stan kontraktów (live + historia),
• łatwe debugowanie i strojenie.

2.2 Reconcile po restarcie (must-have)

Executor po starcie zawsze:

• czyta bot_contracts (desired),
• pobiera observed state z Drift (pozycje + open ordery),
• porównuje i wykonuje minimalne akcje korekcyjne.

Bez tego ryzykujesz:

• “ghost orders”,
• utrzymanie pozycji mimo utraty kontekstu.

2.3 Kill-switch + guardian poza klastrem (must-have)

Kill-switch w executorze to za mało, bo klaster/VPS może paść.

Wzorzec:

• osobny mały serwis bot-guardian poza głównym VPS/k3s,
• jeśli heartbeat executora jest stary → guardian robi cancel_all + reduce_only close.

2.4 Hard risk caps niezależne od modelu

Nawet jeśli Vast zwraca pełny trade_intent, executor musi egzekwować:

• max_position_usd, max_leverage (pośrednio), max_orders_per_min,
• max_slippage_bps, max_spread_bps, freshness_max_ms,
• circuit breakers (np. feed down, RPC lag, drawdown).

Model może proponować parametry, ale nie może omijać twardych limitów.

2.5 Historia danych (TS), retencja i downsample

*_latest jest świetne do live, ale do strojenia potrzebujesz TS:

• DLOB: dlob_stats_ts, dlob_depth_bps_ts, dlob_slippage_ts (min. 7 dni)
• kontrakty: bot_events_ts / log z timestampem

Docelowo:

• trzymać gęste 7 dni,
• trzymać dłużej downsample (np. 1m/5m) pod analizy reżimów.

2.6 Monitoring i alerty (operacyjne)

Minimum alertów:

• feed freshness (DLOB/ticki),
• RPC slot lag / error rate,
• order reject rate,
• panic triggers,
• disk fill/iowait (RPC node).

---

3) “Go/No-Go” do pierwszego live (small size)

Go jeśli:

• kontrakty i eventy są w DB,
• reconcile działa (test restartu),
• kill-switch działa (test: panic → flat),
• mamy twarde limity ryzyka,
• mamy podstawowe alerty,
• mamy 7 dni TS pod progi (albo chociaż 24h na start) i znamy percentyle spread/slippage/depth.

No-Go jeśli:

• nie potrafimy deterministycznie zidentyfikować orderów (brak client_order_id / brak logów),
• restart executora może zostawić pozycję bez kontroli,
• nie ma niezależnego guardiana.

---

4) Proponowana kolejność implementacji (minimalny path)

1. bot_contracts + bot_events + UI podgląd kontraktów (read-only).
2. “observe-only executor” (bez tx) → loguje decyzje z modelu/reguł.
3. TS history: DLOB (7 dni) + podstawowe agregacje.
4. Dry-run/paper: executor wylicza i loguje order plan (bez tx).
5. Live minimal: mały size, limit/post-only + chase, twarde caps.
6. Guardian poza klastrem.
7. Geyser/Yellowstone (jeśli WS RPC nie trzyma stabilnie na skali).