100 lines
5.0 KiB
Plaintext
100 lines
5.0 KiB
Plaintext
BOT: analiza wielu par na Solanie + sygnał wejścia (top 10)
|
||
|
||
Cel
|
||
- Zbudować bota, który:
|
||
- monitoruje i analizuje dane z kilkudziesięciu par/rynków na Solanie,
|
||
- wylicza sygnał wejścia (long/short lub buy/sell) i wybiera ~10 najlepszych okazji,
|
||
- opcjonalnie automatycznie składa zlecenia (po wcześniejszym dopracowaniu ryzyka).
|
||
|
||
Założenia / pytania decyzyjne (ustalić na start)
|
||
1) Czy handlujemy SPOT czy PERPS?
|
||
- SPOT: swap + ewentualnie limit (zależnie od venue).
|
||
- PERPS: leverage, funding, osobne ryzyka i mechanika zleceń.
|
||
2) Interwał i horyzont: skaner 5s / 30s / 1m? Sygnał intraday czy swing?
|
||
3) Jakie typy sygnałów: momentum, mean reversion, breakout, funding-arb, basis, orderflow?
|
||
4) Jakie ograniczenia: max dźwignia, max ekspozycja per rynek, max łączna ekspozycja, SL/TP?
|
||
|
||
Źródła danych (Solana)
|
||
- RPC (stan kont, transakcje, price feeds, orderbook/AMM state): Helius/Alchemy/QuickNode (zależnie od budżetu).
|
||
- Oracle: Pyth (ceny), Switchboard (alternatywnie).
|
||
- Dane DEX:
|
||
- AMM (Orca/Raydium): pool state, price, liquidity, tick.
|
||
- Orderbook (Phoenix/OpenBook): book depth, spread, imbalance.
|
||
- Dane PERPS:
|
||
- Drift: mark price, oracle, funding, OI, pozycje, margin, orderbook/perp state (przez Drift SDK).
|
||
|
||
Architektura (proponowana)
|
||
1) Universe (lista rynków)
|
||
- Start: 30–80 rynków (np. top wolumen / top open interest / ręcznie wybrane).
|
||
- Aktualizacja listy raz dziennie lub co godzinę.
|
||
2) Collector (pobieranie danych)
|
||
- Polling (bez batch) + cache:
|
||
- ceny (Pyth/oracle),
|
||
- wolumen / OI / funding (perps),
|
||
- spread/depth (orderbook),
|
||
- liquidity/TVL (AMM).
|
||
- Normalizacja do jednego formatu:
|
||
- timestamp, symbol/marketId, price, returns, vol, spread, depth, funding, OI, liquidity.
|
||
3) Feature engineering (cechy)
|
||
- returns (1m/5m/15m), RSI, EMA cross, ATR/volatility,
|
||
- orderbook imbalance, spread %, slippage estymowana dla rozmiaru pozycji,
|
||
- perps: funding (aktualny + trend), basis, utilization, OI change.
|
||
4) Scoring (ranking i selekcja top N)
|
||
- wynik = f(signal_strength, liquidity_score, cost_score, risk_score)
|
||
- filtr: minimalna płynność / maksymalny spread / maks. slippage
|
||
- wybór: top 10 rynków do wejścia lub do obserwacji.
|
||
5) Execution (składanie zleceń) – dopiero po stabilizacji
|
||
- tryb “paper” (log + symulacja) -> tryb “live” (małe size).
|
||
- risk manager przed wysłaniem zlecenia:
|
||
- max size per rynek,
|
||
- max łączna ekspozycja,
|
||
- cooldown, max liczba otwartych pozycji,
|
||
- warunki anulowania (np. slippage > X).
|
||
6) Observability
|
||
- logi sygnałów i decyzji,
|
||
- metryki (winrate, MDD, slippage, koszt fee, latency),
|
||
- alerty (RPC errors, divergence oracle/mark, brak danych).
|
||
|
||
Jaki dApp jest najlepszy do bota?
|
||
To zależy od tego, czy chcesz SPOT czy PERPS. Praktyczne kryteria “najlepszy” dla bota:
|
||
- Czy ma stabilne API/SDK (TS/Python), dobre typy i przykłady?
|
||
- Czy obsługuje zlecenia limit/market i ma sensowną płynność?
|
||
- Czy pozwala na bezpieczny model kluczy (delegate / subaccount / ograniczenia)?
|
||
- Jakie są koszty (fees, slippage) i ryzyka (leverage/funding)?
|
||
|
||
Rekomendacja (jeśli celem jest PERPS i sygnały na 10 rynkach)
|
||
- Drift (PERPS) jest najpraktyczniejszy dla bota na Solanie, bo:
|
||
- ma dojrzałe SDK (@drift-labs/sdk) i workflow delegate (hot key do tradingu),
|
||
- umożliwia margin/perps, typowe order types i subaccounty,
|
||
- ma jeden spójny system ryzyk (margin, health), co ułatwia kontrolę ekspozycji.
|
||
- To jest też spójne z obecnym repozytorium (workflow Drift + delegate + SOL-PERP).
|
||
|
||
Rekomendacja (jeśli celem jest SPOT i egzekucja swapów)
|
||
- Jupiter (agregator) jest zwykle najlepszy do wykonania swapów na SPOT:
|
||
- optymalizuje routing, upraszcza egzekucję,
|
||
- łatwo wycenić i policzyć slippage dla różnych par.
|
||
- Jeśli potrzebujesz limit orders na SPOT:
|
||
- rozważ venue orderbook (Phoenix/OpenBook) albo dApp, które natywnie wspiera limity,
|
||
- kosztem większej złożoności (orderbook + cancel/replace).
|
||
|
||
Proponowany “hybrid” (często najlepszy w praktyce)
|
||
- Sygnał generujesz niezależnie od venue (feature store + ranking),
|
||
- SPOT wykonujesz przez Jupiter (najlepsza egzekucja),
|
||
- PERPS wykonujesz na Drift (leverage + perps),
|
||
- Dane rynkowe mieszasz: oracle + DEX metrics + perps metrics.
|
||
|
||
Minimalny MVP (1–2 tygodnie, bez live trading)
|
||
1) Universe 30–50 rynków + konfiguracja w pliku.
|
||
2) Collector: ceny + podstawowe metryki per rynek (wspólny format).
|
||
3) Ranking: prosty score (momentum + liquidity - cost).
|
||
4) Output: co X sekund zapis:
|
||
- top 10 rynków, strona (long/short), siła sygnału, est. slippage, uzasadnienie (cechy).
|
||
5) Backtest “na sucho”:
|
||
- zapis sygnałów do CSV/JSONL, później analiza w Pythonie.
|
||
|
||
Następne kroki (żeby doprecyzować i dobrać dApp ostatecznie)
|
||
1) Potwierdź: SPOT czy PERPS (czy oba)?
|
||
2) Podaj listę par (albo kryterium wyboru).
|
||
3) Potwierdź częstotliwość skanowania (np. 10s/30s/60s) i horyzont.
|
||
4) Powiedz, czy bot ma tylko sygnalizować, czy też automatycznie tradować.
|