Home>Blog>Three Lines That Saved a Position: Liquidation Risk Alerts on Hyperliquid
Three Lines That Saved a Position: Liquidation Risk Alerts on Hyperliquid

Three Lines That Saved a Position: Liquidation Risk Alerts on Hyperliquid

By @CoinMarketMan - 01-Sep-2026

Три рядки коду, що врятували позицію: Алерти на ризик ліквідації на Hyperliquid

27 серпня HYPE досяг нового абсолютного максимуму $86.71 з ринковою капіталізацією близько $18.9 мільярда. У цей же час сумарні ліквідації лонгів на Hyperliquid склали $21.88 мільйона за 24 години — оскільки плечові лонги, що їхали на ралі, були вибиті різким внутрішньоденним розворотом. Відкритий інтерес становив $3.47 мільярда при ринковій капіталізації $19.63 мільярда, що дає левередж-експозицію близько 17.7% від ринкової капіталізації.

Ці цифри говорять про важливе: на піку ейфорії значна частина відкритого інтересу ринку перебувала поблизу примусового закриття. Трейдери, у яких були налаштовані алерти на ризик ліквідації, знали про зростання тиску за кілька годин до розгрому. Ті, у кого не було, дізналися про це, коли їхні позиції вже зникли.

Ця стаття розглядає практичний бік побудови алертів на ризик ліквідації на Hyperliquid за допомогою API HyperTracker. Ви отримаєте робочий Python-код, ешелоновану архітектуру алертів із маршрутизацією за серйозністю когорти, а також детектор кореляції між активами, що відрізняє ізольований стрибок від більш широкого делевериджингу.

Що повертає ендпоінт ризику ліквідації

Ендпоінт ризику ліквідації HyperTracker знаходиться за адресою GET /api/external/{segmentId}/assets/liquidation-risk. Передайте будь-який із 16 ідентифікаторів сегментів когорт, і він поверне всі активи, за якими ця когорта має відкриті позиції, відсортовані за рівнем ризику. Кожен елемент містить три поля:

  • totalValue: загальний відкритий інтерес за активом у цій когорті
  • riskValue: сума позицій у доларах, що знаходяться в межах 75% від порогу ліквідації
  • percentRisk: співвідношення вартості під ризиком до загальної експозиції

16 когорт розподілені за двома осями. Вісім класифікують гаманці за перп-капіталом (від Shrimp до Leviathan), і вісім — за сукупним PnL (від Money Printer до Giga-Rekt). Коли percentRisk Leviathan різко зростає по ETH, обсяг примусового закриття достатній, щоб рухати ринок. Коли стрибає когорта Shrimp — це шум. Саме ця асиметрія робить усереднений показник по всіх когортах марним для алертингу і пояснює, чому важлива ешелонована маршрутизація.

Побудова ешелонованих алертів за впливом когорти

Найпростіший монітор ризику ліквідації ставиться до кожної когорти однаково. Це хибний підхід, бо ринковий вплив ліквідації Leviathan і ліквідації Fish відрізняється на порядки величин. Кращий підхід — призначити рівні на основі умовної експозиції кожної когорти, а потім по-різному маршрутизувати алерти для кожного рівня.

Cohort Tier Alert Routing

Рівень 1: критичні когорти

Leviathan (сегмент ID 7), Tidal Whale (ID 6) і Money Printer (ID 8). Це найбільші гаманці та найприбутковіші трейдери на платформі. Коли їхні позиції концентруються поблизу ліквідації, обсяг вимушених продажів може спровокувати каскадні рухи ціни. Надсилайте алерти негайно і розгляньте автоматичне скорочення позиції.

Рівень 2: попереджувальні когорти

Whale (ID 5), Small Whale (ID 4) і Smart Money (ID 9). Суттєвий капітал, але менш схильний одноосібно запустити каскад. Алерт для ручного перегляду і жорсткішого управління стопами.

Рівень 3: інформаційний

Все інше: Apex Predator (ID 3), Dolphin (ID 2), Fish (ID 1), Shrimp (ID 16) і решта PnL-когорт (ID 10-15). Записуйте це до бази даних часових рядів для бектестингу та досліджень, але не надсилайте в канал алертів. Система алертів, яка спрацьовує на все, стає тією, яку ігнорують.

Ось Python-реалізація. Вона опитує когорти кожного рівня, обчислює зважений показник і маршрутизує до відповідного каналу алертів:

import requests, time

API_BASE = "https://ht-api.coinmarketman.com/api/external"
TOKEN = "YOUR_JWT_TOKEN"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

# Tier definitions: cohort_id -> (name, weight)
TIER_1 = {7: ("Leviathan", 2.0), 6: ("Tidal Whale", 1.5), 8: ("Money Printer", 1.3)}
TIER_2 = {5: ("Whale", 1.0), 4: ("Small Whale", 0.8), 9: ("Smart Money", 1.2)}
TIER_3_IDS = [3, 2, 1, 16, 10, 11, 12, 13, 14, 15]

def get_risk(segment_id):
    url = f"{API_BASE}/{segment_id}/assets/liquidation-risk"
    resp = requests.get(url, headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["items"]

def weighted_score(coin, tier):
    total_w, w_sum = 0, 0
    for seg_id, (name, weight) in tier.items():
        assets = get_risk(seg_id)
        match = next((a for a in assets if a["coin"] == coin), None)
        if match:
            w_sum += match["percentRisk"] * weight
            total_w += weight
    return w_sum / total_w if total_w else 0

def scan():
    all_assets = get_risk(7)  # use Leviathan as asset index
    for asset in all_assets:
        coin = asset["coin"]
        t1 = weighted_score(coin, TIER_1)
        t2 = weighted_score(coin, TIER_2)
        if t1 >= YOUR_CRITICAL_THRESHOLD:
            send_critical_alert(coin, t1)
        elif t2 >= YOUR_WARNING_THRESHOLD:
            send_warning_alert(coin, t2)

while True:
    scan()
    time.sleep(300)  # 5-min poll matches API refresh

Примітка щодо порогів і ваг. Призначення рівнів і ваги вище є орієнтовними відправними точками. HyperTracker класифікує гаманці за когортами. Він не встановлює конкретних порогів алертів, правил розміщення позицій або параметрів управління ризиками. Калібруйте пороги й ваги відповідно до власної толерантності до ризику та результатів бектестингу.

Виявлення стрибків кореляції між активами

Ізольований стрибок по одному активу — це одне. Коли ризик ліквідації одночасно зростає по BTC, ETH і SOL в одній когорті — це більш широкий сигнал делевериджингу. Різниця суттєва: корельований стрибок означає, що вимушені продажі вдарять по кількох позиціях портфеля одночасно, посилюючи збитки.

Multi Asset Correlation Spike

Логіка виявлення проста. Після обчислення зважених показників ризику для кожного активу підрахуйте, скільки з них одночасно перевищують ваш поріг. Якщо кількість перетинає другий поріг (наприклад, три або більше активів у підвищеному стані одночасно), підвищте серйозність алерту:

def detect_correlation(tier, threshold):
    """Count assets above threshold in a given tier."""
    all_assets = get_risk(list(tier.keys())[0])
    elevated = []
    for asset in all_assets:
        score = weighted_score(asset["coin"], tier)
        if score >= threshold:
            elevated.append((asset["coin"], score))
    return elevated

elevated = detect_correlation(TIER_1, YOUR_CRITICAL_THRESHOLD)
if len(elevated) >= 3:  # example threshold - calibrate to your model
    send_correlated_alert(elevated)  # highest severity

Чому це важливо? Розгляньте ралі наприкінці серпня 2026. HYPE досяг абсолютного максимуму, тоді як ліквідації лонгів домінували на кожному таймфреймі. Якби ваша система алертів стежила лише за окремими активами, вона могла б спрацювати окремо по BTC, ETH і HYPE — кожен класифікувався б як рутинний стрибок. Детектор кореляції розпізнав би патерн по всіх трьох і ескалував би до єдиного алерту високої серйозності: «зростає широкий тиск ліквідацій лонгів по всьому портфелю».

Поєднання показників ризику з упередженістю когорти

Ризик ліквідації говорить вам про те, що тиск зростає. Але не вказує, в якому напрямку. Тут на допомогу приходить ендпоінт bias. GET /api/external/{segmentId}/bias від HyperTracker повертає, чи є когорта нетто-лонг або нетто-шорт по певному активу. Поєднання двох ендпоінтів дає вашій системі алертів напрямний контекст:

  • Високий ризик ліквідації + когорта схиляється до лонгу = вимушені продажі, якщо вони відбудуться, штовхатимуть ціну вниз
  • Високий ризик ліквідації + когорта схиляється до шорту = вимушені покупки (шорт-сквізи) штовхатимуть ціну вгору

Ця відмінність змінює вашу реакцію. Якщо ви тримаєте лонг-позицію, а когорта Leviathan також сильно в лонгу з підвищеним ризиком ліквідації, ви на одному боці з потенційним каскадом. Це сигнал до скорочення позиції. Але якщо Leviathan'и сильно в шорті з підвищеним ризиком, шорт-сквіз може фактично піти на користь вашій лонг-позиції.

def get_bias(segment_id, coin):
    url = f"{API_BASE}/{segment_id}/bias"
    resp = requests.get(url, headers=HEADERS)
    data = resp.json()
    match = next((a for a in data["items"] if a["coin"] == coin), None)
    return match["bias"] if match else "neutral"

# In your alert handler:
coin, score = "ETH", weighted_score("ETH", TIER_1)
if score >= YOUR_CRITICAL_THRESHOLD:
    bias = get_bias(7, coin)  # Leviathan bias
    msg = f"ALERT: {coin} risk={score:.1f}%, Leviathan bias={bias}"
    send_critical_alert(msg)

Шлях оновлення від поллінгу до вебхуків

Усі наведені вище зразки коду використовують REST-поллінг із циклом на 5 хвилин, що відповідає частоті оновлення даних HyperTracker. Для акаунту рівня Pulse ($179/міс) це правильна архітектура: отримати дані, оцінити, надіслати алерт за потреби, зупинитись, повторити.

Але поллінг має структурну слабкість. Ваша затримка алерту дорівнює інтервалу поллінгу плюс час обчислення. Якщо стрибок ризику відбувається одразу після вашого останнього запиту, ви не побачите його до 5 хвилин. Для більшості сценаріїв управління ризиками це прийнятно. Для автоматизованого розміщення позицій або високочастотних стратегій — ні.

Alert Pipeline Architecture

Шлях оновлення — це доставка через вебхуки, доступна на рівні Flow ($799/міс) і вище. З вебхуками HyperTracker надсилає дані про ризик на ваш ендпоінт щойно вони оновлюються, що повністю усуває цикл поллінгу. Ваш код стає простішим (без планувальника, без циклу очікування), а затримка скорочується до часу мережевої передачі.

Для рівня Stream ($1,999/міс) WebSocket-з'єднання забезпечують безперервні оновлення. Патерн зміщується від запит-відповідь до подієво-орієнтованого: підпишіться на зміни ризику, обробляйте їх у міру надходження та надсилайте алерти майже в реальному часі.

Починайте з поллінгу, переходьте, коли він вас обмежує. Рівень Pulse за $179/міс дає вам все необхідне для побудови робочого конвеєра алертів. Поллінг кожні 5 хвилин достатній для більшості моніторингу ризиків. Переходьте до вебхуків або WebSocket лише тоді, коли вам потрібна менша затримка — зазвичай це означає, що ви запускаєте автоматизоване управління позиціями, яке реагує швидше, ніж людина.

Калібрування порогів: бектестинг на історичних даних

Найважча частина будь-якої системи алертів — не код. Це поріг. Встановите його занизько — потонете в хибно-позитивних спрацьовуваннях. Встановите занадто високо — пропустите той каскад, що має значення.

HyperTracker надає приблизно чотири тижні історичних даних метрик когорт, чого достатньо для бектестингу вашого порогу на нещодавніх ринкових умовах. Підхід полягає в отриманні історичних показників ризику, накладанні їх на цінові дані та визначенні значень percentRisk, що передували значним ціновим рухам.

Практичний процес калібрування:

  1. Отримайте чотири тижні щоденних знімків ризику для ваших когорт Рівня 1 по BTC, ETH і найбільш торгованих активах
  2. Відзначте дати, коли відбувалися значні просадки (рухи на 10%+ за 24 години або менше)
  3. Виміряйте зважений percentRisk в інтервалах поллінгу, що передували кожній просадці
  4. Встановіть поріг алерту на рівні, який би спрацював перед більшістю цих просадок без щоденних спрацьовувань на рутинних коливаннях

Це не разова вправа. Ринкова структура змінюється. Апетит до левериджу зміщується разом із настроями. Поріг, що працював у обережний пост-корекційний період на початку серпня (коли HYPE впав майже на 20% за 30 днів), не обов'язково спрацює під час ейфорійного ралі, що підняло HYPE до абсолютних максимумів пізніше того ж місяця. Переглядайте калібрування щонайменше раз на місяць.

Запуск у виробництво

Робочий конвеєр алертів потребує кількох речей поза основною логікою оцінювання:

  • Постійний стан: Зберігайте кожен обчислений показник ризику, навіть коли він нижчий за поріг. Історичні показники — ваш набір даних для калібрування. Підійде проста база даних часових рядів (InfluxDB, TimescaleDB або навіть SQLite для прототипування).
  • Дедуплікація: Якщо монета залишається вище порогу три послідовні цикли поллінгу, надішліть один алерт з позначкою «все ще підвищений», а не три однакових повідомлення. Втома від алертів вбиває корисність будь-якої системи моніторингу.
  • Логіка кулдауну: Після спрацювання алерту і вжиття трейдером заходів, придушіть повторні алерти по тому ж активу на налаштований період кулдауну. Інакше система нагадуватиме про ризик, який ви вже врахували.
  • Накладка на дашборд: Передавайте показники ризику до Grafana або Retool разом із ціновими даними. Візуальне розпізнавання патернів швидше, ніж читання виводу логів, і робить калібрування порогів інтуїтивним.

Побудуйте свій конвеєр алертів на ризик ліквідації

API HyperTracker надає попередньо обчислені показники ризику ліквідації по 16 поведінкових когортах. Один REST-запит на когорту, оновлення кожні 5 хвилин. Починайте на безкоштовному рівні для дослідження, потім переходьте на Pulse ($179/міс) для продакшн-алертингу.

Отримайте ваш API-ключ

Каскади ліквідацій не надсилають запрошень у календар. Вони трапляються під час святкових вихідних, оракульних розбіжностей і саме в той момент, коли леверидж стає переповненим. Трейдери, які стабільно їх переживають, мають одну спільну рису: вони знали про зростання тиску до того, як ціна зрушила. Кілька рядків коду, що опитують правильний ендпоінт, зважені за правильними когортами, маршрутизовані до правильного каналу. Ось різниця між алертом на телефоні і квитанцією про ліквідацію в поштовій скриньці.