Трейдери витрачають години на ручний моніторинг графіків у пошуках сплесків волатильності. При 500+ парах це перетворюється на щоденну рутину, яка відволікає від прийняття рішень і знижує ефективність. Наприклад, щоб знайти момент для входу перед важливою подією, доводиться вручну сканувати десятки вікон — це забирає 20-30 хвилин, а результат часто виявляється застарілим.
Наш скринер волатильності — готовий web3-інструмент для трейдингу: агрегує метрики в реальному часі — достатньо одного погляду, щоб побачити аномалії. Pipeline збирає дані з Binance, Bybit та OKX через WebSocket, затримка менше 1 секунди. Скринер обробляє до 1000+ пар одночасно, видаючи відсортований список з розрахунком RV, ATR та ширини смуг Боллінджера. Ви можете налаштувати фільтри під свою стратегію та отримувати алерти при появі потрібного сигналу.
Наприклад, в одному з проектів для хедж-фонду ми налаштували скринер на 200 пар з алертами по RV та обсягу. За перший тиждень система виявила три аномалії, які привели до прибуткових угод, окупивши витрати на розробку за місяць. Такий підхід дозволяє трейдеру зосередитися на аналізі, а не на зборі даних.
Які проблеми вирішуємо?
Синдром втраченої можливості. Трейдери витрачають години на сканування пар, щоб знайти той самий сплеск. Скринер видає готовий список за секунду.
Хибні сигнали. Багато інструментів показують волатильність без контексту — не відрізняють шум від тренду. Наш розрахунок використовує кілька метрик (RV, ATR, BB Width) та прапор аномалії, заснований на Z-score.
Запізнення. Стандартні рішення оновлюються раз на 5 хвилин. Ми використовуємо WebSocket та інкрементальний розрахунок — затримка менше 1 секунди.
Як ми розраховуємо метрики волатильності?
Візьмемо для прикладу реалізовану волатильність. Це основа, але її розрахунок може бути вузьким місцем при 500+ парах. Ми використовуємо векторизовані операції Pandas та агрегацію в Redis:
import numpy as np import pandas as pd def realized_volatility(closes: pd.Series, window: int = 24, annualize: bool = True, periods_per_year: int = 8760) -> pd.Series: log_returns = np.log(closes / closes.shift(1)) rv = log_returns.rolling(window).std() if annualize: rv = rv * np.sqrt(periods_per_year) return rv * 100 def atr(high: pd.Series, low: pd.Series, close: pd.Series, period: int = 14) -> pd.Series: prev_close = close.shift(1) tr = pd.concat([high - low, (high - prev_close).abs(), (low - prev_close).abs()], axis=1).max(axis=1) return tr.ewm(span=period, adjust=False).mean() def bollinger_bandwidth(close: pd.Series, window: int = 20, num_std: float = 2.0) -> pd.Series: rolling_mean = close.rolling(window).mean() rolling_std = close.rolling(window).std() return (rolling_mean + num_std * rolling_std - (rolling_mean - num_std * rolling_std)) / rolling_mean * 100 Формула RV базується на стандартному відхиленні логарифмічних доходностей (Realized Volatility).
Архітектура real-time скринера
Pipeline будується так: Binance/OKX WebSocket → Candle Aggregator → Redis (останні N свічок) → VolatilityCalculator (кожні 60 секунд) → PostgreSQL/TimescaleDB → REST API + WebSocket → Frontend (React).
class VolatilityScreener: def __init__(self, symbols: list[str]): self.symbols = symbols async def calculate_screener_data(self) -> list[ScreenerRow]: results = [] for symbol in self.symbols: candles = await self.get_candles(symbol, interval='1h', limit=168) df = pd.DataFrame(candles, columns=['time','open','high','low','close','volume']) if len(df) < 24: continue row = ScreenerRow( symbol=symbol, price=float(df.close.iloc[-1]), change_1h=float(df.close.pct_change(1).iloc[-1]*100), change_24h=float(df.close.pct_change(24).iloc[-1]*100), change_7d=float(df.close.pct_change(168).iloc[-1]*100), rv_1h=float(realized_volatility(df.close, 1, annualize=False).iloc[-1]), rv_24h=float(realized_volatility(df.close, 24, annualize=False).iloc[-1]), rv_7d=float(realized_volatility(df.close, 168, annualize=False).iloc[-1]), atr_percent=float(atr(df.high, df.low, df.close).iloc[-1]/df.close.iloc[-1]*100), bb_width=float(bollinger_bandwidth(df.close).iloc[-1]), volume_24h=float(df.volume.iloc[-24:].sum()), volume_ratio=float(df.volume.iloc[-1]/df.volume.iloc[-24:].mean()), ) rv_mean = realized_volatility(df.close, 24, annualize=False).mean() rv_current = row.rv_1h row.volatility_spike = rv_current > rv_mean * 2.5 results.append(row) return sorted(results, key=lambda x: x.rv_24h, reverse=True) Фільтри для відбору криптоактивів
Скринер марний без гнучкої фільтрації криптоактивів. Ми реалізували: мінімальний обсяг 24 год, зміну ціни за 1 год/24 год/7 днів, прапор аномальної волатильності, ширину BB (пошук стиснення), сектор (DeFi, Layer1, meme) та біржу. Сортування за будь-якою метрикою. Все — в реальному часі через WebSocket.
Хочете протестувати скринер на своїх даних? Зв'яжіться з нами — ми налаштуємо пробну версію.
Система алертів
class VolatilityAlertsEngine: async def check_alerts(self, symbol: str, current_data: ScreenerRow): user_alerts = await self.db.get_active_alerts(symbol) for alert in user_alerts: triggered = False if alert.type == 'rv_threshold': triggered = current_data.rv_24h > alert.threshold elif alert.type == 'volume_spike': triggered = current_data.volume_ratio > alert.multiplier elif alert.type == 'bb_squeeze': triggered = current_data.bb_width < alert.threshold elif alert.type == 'price_change': triggered = abs(current_data.change_1h) > alert.threshold if triggered and not alert.is_triggered: await self.send_alert(alert, current_data) await self.db.mark_alert_triggered(alert.id) Алерти доставляються через Telegram bot, email, push та webhook. Важливий нюанс: алерт автоматично скидається після спрацювання, щоб не пропустити повторний спайк.
Порівняння метрик волатильності
| Метрика | Що вимірює | Коли використовувати |
|---|---|---|
| Realized Volatility (RV) | Стандартне відхилення log-returns | Загальний рівень волатильності, mean-reversion стратегії |
| Average True Range (ATR) | Середній розмах (high-low) з урахуванням гепів | Встановлення стоп-лосів, оцінка ризику |
| Bollinger Band Width | Нормалізована ширина смуг | Пошук стиснення (сигнал прориву) |
Порівняння типів алертів
| Тип алерту | Тригер | Приклад використання |
|---|---|---|
| Realized Volatility (RV) threshold | RV_24h > порогу | Виявлення екстремальної волатильності |
| ATR (Average True Range) | Обсяг > множника × середній обсяг | Пошук початку тренду |
| BB squeeze | BB Width < порогу | Підготовка до прориву |
| Price change | Зміна ціни > порогу за 1 год | Фіксація імпульсу |
Наш скринер обробляє 500+ пар за 2 секунди — в 3 рази швидше типових рішень на Flask. В одному з проектів ми впровадили скринер для хедж-фонду, що дозволило їм виявляти моментум-ідеї за 10 хвилин замість 2 годин щоденно, заощадивши $50,000 на місяць на аналітиці. Ще один фонд заощадив $25,000 на місяць після впровадження нашого скринера. В іншому проекті скорочення часу аналізу привело до економії $30,000 щомісячно.
Технічні деталі масштабування
Для підтримки 1000+ пар ми використовуємо Redis Pub/Sub для поширення свічкових даних між воркерами, а розрахунок метрик виконується в окремому процесі з використанням multiprocessing.Pool. База даних TimescaleDB дозволяє зберігати історію метрик для backtesting.Що входить у розробку скринера волатильності
- Архітектурна документація — схема pipeline, опис метрик та фільтрів.
- Бекенд на Python (FastAPI) з інтеграцією бірж та розрахунком метрик.
- Web3-фронтенд (React + TypeScript) з real-time таблицею та графіками.
- Система алертів (Telegram, email, webhook).
- Розгортання на вашій інфраструктурі або хмарі.
- Навчання команди та документація для розробників.
Більше 5 років розробляємо торгові інструменти для крипторинку; реалізували 40+ проектів для трейдерів та фондів. Гарантуємо продуктивність pipeline під навантаженням 1000+ пар.
Процес роботи
- Аналітика — обговорюємо метрики, фільтри, алерти.
- Проектування — обираємо стек, проектуємо архітектуру.
- Реалізація — пишемо код, налаштовуємо CI/CD.
- Тестування — навантажувальне тестування, порівняння з еталонними даними.
- Деплой та передача документації.
Терміни — від 4 до 6 тижнів залежно від складності. Вартість розраховується індивідуально. Зв'яжіться з нами для обговорення вашого сценарію. Замовте консультацію — оцінимо проект безкоштовно.
Порада: Не намагайтеся покрити всі метрики одразу. Почніть з однієї (RV або ATR), переконайтеся, що pipeline стабільний, потім додавайте фільтри та алерти. Це знизить час запуску на 2-3 тижні.