Три строки, которые спасли позицию: алерты риска ликвидации на Hyperliquid

27 августа HYPE достиг нового исторического максимума в $86.71 при рыночной капитализации около $18.9 миллиарда. В том же временном окне суммарные ликвидации лонгов на Hyperliquid составили $21.88 миллиона за 24 часа: leveraged лонги, которые ехали на ралли, выбило на резком внутридневном развороте. Открытый интерес составлял $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 несопоставимы. Правильнее назначить уровни на основе номинальной экспозиции каждой когорты, а затем по-разному маршрутизировать алерты для каждого уровня.

Уровень 1: критические когорты

Leviathan (segment 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 в одной когорте — это уже сигнал масштабного делевериджинга. Разница принципиальна: коррелированный всплеск означает, что принудительные продажи ударят по нескольким позициям в портфеле одновременно, многократно усиливая ущерб.

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

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

Риск ликвидации говорит вам, что давление нарастает. Он не говорит, в каком направлении. Здесь на помощь приходит эндпоинт 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/mo) это правильная архитектура: получить данные, оценить, алертировать при необходимости, подождать, повторить.

Однако у поллинга есть структурный изъян. Ваша задержка алерта равна интервалу поллинга плюс время вычислений. Если всплеск риска случился сразу после последнего опроса, вы не увидите его до пяти минут. Для большинства задач риск-менеджмента это приемлемо. Для автоматизированного управления размером позиции или высокочастотных стратегий — нет.

Путь обновления — доставка через вебхуки, доступная на уровне Flow ($799/mo) и выше. С вебхуками HyperTracker пушит данные о рисках на ваш эндпоинт сразу после обновления, полностью устраняя цикл поллинга. Код становится проще (нет планировщика, нет цикла ожидания), а задержка сокращается до времени сетевой передачи.

На уровне Stream ($1,999/mo) WebSocket-соединения обеспечивают непрерывные обновления. Паттерн меняется с запрос-ответ на событийно-управляемый: подписываетесь на изменения рисков, обрабатываете их по мере поступления и отправляете алерты в близком к реальному времени.

Начните с поллинга, переходите на следующий уровень, когда вырастете из него. Уровень Pulse за $179/mo даёт всё необходимое для построения рабочего алерт-пайплайна. Поллинг каждые 5 минут достаточен для большинства задач мониторинга рисков. Переходите на вебхуки или WebSocket только когда вам нужна меньшая задержка, что обычно означает работу с автоматизированным управлением позицией, которое реагирует быстрее человека.

Калибровка порогов: бэктестинг на исторических данных

Самая сложная часть любой системы алертов — не код. Это порог. Поставьте слишком низко — утонете в ложных срабатываниях. Поставьте слишком высоко — пропустите тот самый каскад.

HyperTracker предоставляет примерно четыре недели исторических данных когортных метрик, чего достаточно для бэктестинга порога на недавних рыночных условиях. Подход такой: выгрузить исторические баллы риска, наложить их на ценовые данные и найти значения percentRisk, которые предшествовали значимым ценовым движениям.

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

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

Это не разовое упражнение. Рыночная структура меняется. Аппетит к кредитному плечу смещается вместе с настроением. Порог, который работал в осторожный постcoррекционный период начала августа (когда HYPE упал почти на 20% за 30 дней), необязательно будет работать во время эйфорийного ралли, которое вынесло HYPE на исторические максимумы позже в том же месяце. Пересматривайте калибровку не реже одного раза в месяц.

Вывод в продакшн

Рабочий алерт-пайплайн требует нескольких вещей помимо основной логики оценки:

• Постоянное состояние: Сохраняйте каждый вычисленный балл риска, даже если он ниже порога. Исторические баллы — это ваш датасет для калибровки. Подойдёт простая база временных рядов (InfluxDB, TimescaleDB или даже SQLite для прототипирования).
• Дедупликация: Если монета остаётся выше порога три последовательных опроса, отправляйте один алерт с флагом «по-прежнему повышен», а не три идентичных сообщения. Усталость от алертов убивает полезность любой системы мониторинга.
• Логика cooldown: После срабатывания алерта и принятия трейдером мер, подавляйте повторные алерты по тому же активу на настраиваемый период cooldown. Иначе система будет напоминать о риске, который вы уже устранили.
• Наложение на дашборд: Подавайте баллы риска в Grafana или Retool рядом с ценовыми данными. Визуальное распознавание паттернов быстрее, чем чтение вывода логов, и делает калибровку порогов интуитивной.

Создайте свой алерт-пайплайн риска ликвидации

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

Получить API-ключ

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