Разработка моделі обнаруження pump-and-dump схем
Pump-and-dump у крипто працює швидше ніж на традиційних ринках: від початку скоординованої покупки до dump — години або навіть хвилини. On-chain дані повністю публічні, що створює унікальну можливість для обнаруження: можна бачити рух гаманців, концентрацію об'єму, синхронізацію транзакцій у реальному часі.
Задача — побудувати систему, що детектує P&D схему під час pump-фази, до dump, щоб попередити користувачів або автоматично захистити протокол.
Анатомія pump-and-dump схеми
Розуміння механіки критичне для побудови правильних ознак.
Фаза накоплення: організатори постепово скупають токен дрібними ордерами, стараючись не рухати ціну. Ознаки: рост числа унікальних hold addresses при стагнації ціни, необичный buy volume у нерабочие часи, поява скоординованих гаманців.
Фаза pump: скоординована покупка, зазвичай узгоджена в Telegram/Discord. Ціна росте на 200-2000% за години. Volume spike в 10-100x від середнього. Social media spike с шаблонними сообщениями.
Фаза dump: організатори продають у пік. Роздрібні покупці, привабдені ростом, входять і залишаються з losses. Ціна падає до pre-pump рівня або нижче.
Ознаки для моделі
On-chain метрики
Volume anomaly score:
VAS = current_volume / rolling_avg_volume_30d
Значення > 10 без fundamental news — сильний сигнал.
Holder concentration delta: зміна HHI (Herfindahl-Hirschman Index) балансів:
HHI = Σ (balance_i / total_supply)²
Рост HHI = концентрація токенів у меншої кількості адрес = акумуляція.
Transaction synchronization: коефіцієнт синхронності транзакцій — скільки незалежних адрес совершили buy в одному часовому вікні (±5 хвилин). При органічному росту покупки розподілені рівномірно. При P&D — spike.
Wallet clustering: граф зв'язків між адресами. Адреси, що отримали ETH з одного джерела, купили з одного EOA, совершили транзакції за схожими паттернами — вірогідно контролюються одною сутністю. Якщо 60%+ volume від кластера — сигнал.
Price-volume divergence: у здоровому росту об'єм нарастає постепово вместе з ціною. У P&D об'єм спочатку, потім ціна різко — або синхронно, без раскачки.
Крос-ринкові метрики
DEX vs CEX price discrepancy: якщо ціна на DEX значно вище ніж на CEX — можлива намісна маніпуляція DEX ціною.
Liquidity depth change: різке зменшення ліквідності в пулі (removal LP) перед pump знижує resistance — класичний preparation паттерн.
New wallet ratio: процент транзакцій від гаманців, створених < 7 днів тому. Висока = fresh адреси для організаторів.
Social signals (опціонально)
Telegram/Discord мониторинг на упоминання тікера. Різкий рост упоминань + позитивний sentiment + шаблонні призиви = coordinated pump сигнал.
Архітектура системи обнаруження
Data pipeline
Blockchain RPC (geth/erigon)
→ Event streaming (WebSocket)
→ Kafka / RabbitMQ
→ Feature extractor (Python)
→ Feature store (Redis realtime, PostgreSQL historical)
→ ML model inference
→ Alert engine
Feature extraction
Вичислення volume anomaly, sync score, HHI, і так далі у реальному часі.
ML модель
Для обнаруження P&D добре працюють ансамблеві методи: XGBoost або LightGBM на tabular features. Інтерпретовані (SHAP values), швидкий інференс, устійчиві до missing data.
Метрики оцінки: precision-recall важливіші за accuracy через strong class imbalance. Мета: precision > 0.7 при recall > 0.6. False positives (ложні тревоги) дратують користувачів; false negatives (пропущені P&D) — репутаційна шкода.
Реалізація алертингу
Thresholds та confidence levels
Не бінарне "P&D / не P&D", а вірогідність з порогами:
- > 0.8: висока впевненість, невідкладний алерт
- 0.6 - 0.8: середня впевненість, попередження
- < 0.6: мониторинг, немає алерту
Інтеграція з протоколом
Для протоколів, де важлива захист: trading contract може читати оцінку ризику через oracle. Якщо ризик високий — підвищений slippage tolerance або pause специфічного пулу.
Обмеження та застереження
Система обнаруження не усуває P&D — вона попереджає. Організатори адаптуються до алгоритмів детекції (adversarial атаки). Якість моделі деградирует з часом, вимагає переобучення.
Юридична сторона: автоматичні блокування торговлі на основі ML предсказань несуть правові ризики залежно від юрисдикції. Безпечніше — попередити користувачів, не автоматично обмежувати торгівлю.
Сроки розробки
Збір та розмітка даних — 3-4 тижні, модель — 2-3 тижні, інфраструктура та алертинг — 3-5 тижнів, тестування — 2 тижні.
Всього: 8-14 тижнів.