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