120 lines
4.5 KiB
Markdown
120 lines
4.5 KiB
Markdown
# 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).
|