TP/SL на Hyperliquid: trigger, market, limit и частичный выход

Что понадобится перед началом

Материал рассчитан на трейдера, который уже открывает perpetual-позиции на Hyperliquid, понимает разницу между mark price и last price, работает с cross и isolated margin и хочет настроить защитные ордера осознанно, а не по умолчанию из интерфейса. Предполагается знакомство с базовой механикой TIF (GTC, IOC, ALO) и funding.

Как устроен триггер TP/SL

TP/SL на Hyperliquid — условный ордер: он не лежит в книге сразу, а активируется при достижении заданного уровня mark price. Обычный лимитный ордер виден в стакане и может исполниться против встречной заявки в любой момент; TP/SL до срабатывания вообще не участвует в matching. Триггер завязан на mark price, а не на цену последней сделки, потому что mark price сглаживает кратковременные выбросы и используется в расчёте ликвидации — это защищает от ситуации, когда одна аномальная сделка на тонком уровне книги случайно активирует стоп, хотя реальная цена актива не менялась.

После срабатывания триггера ордер превращается либо в market, либо в limit заявку — этот выбор вы делаете при настройке TP/SL заранее, а не получаете как автоматическое поведение платформы. От него зависит, что вы получите на выходе: гарантированное закрытие позиции или гарантированную цену закрытия, но не оба сразу.

Market-триггер против limit-триггера

Market-вариант после срабатывания закрывает позицию в пределах заданной tolerance по цене. Ордер исполнится почти наверняка, но фактическая цена закрытия может отличаться от уровня триггера — величина отклонения зависит от глубины книги в момент исполнения. На ликвидном контракте с плотной книгой отклонение минимально; на тонком рынке или в момент резкого движения market-вариант может закрыть позицию заметно хуже, чем показывал mark price при срабатывании.

Limit-вариант даёт контроль над ценой, но документация прямо указывает: он не гарантирует полный fill после срабатывания — если рынок прошёл уровень слишком быстро или там не было встречного объёма, часть или вся позиция останется открытой. Для SL это критично: неисполненный лимитный стоп оставляет позицию без защиты именно тогда, когда она нужна больше всего.

Частичный выход: фиксация части прибыли

Частичное закрытие через TP/SL реализуется указанием размера ордера меньше полного объёма позиции. Это отдельная заявка со своим размером, привязанная к тому же mark price триггеру, а не модификация существующей позиции. Такой подход позволяет разделить выход на несколько уровней: закрыть часть на первом целевом уровне и оставить остаток с более высоким TP или подтянутым SL, снижая давление держать всю позицию до конца движения.

Каждый частичный TP/SL нужно выставлять с флагом Reduce Only — без него вместо закрытия части позиции можно случайно открыть встречную. Проверка флага перед подтверждением заявки должна стать привычкой при любом частичном выходе.

Порядок настройки TP/SL на реальной позиции

Настройка защитных ордеров — последовательность действий, а не один клик по кнопке TP/SL в интерфейсе.

1. 01
   Оценить буфер до ликвидации

   Определить расстояние между текущей mark price и границей ликвидации с учётом margin tier и notional позиции — maintenance requirement зависит от размера позиции и растёт вместе с ним.

2. 02
   Выбрать уровень SL с запасом

   Поставить SL на удалении от границы ликвидации, а не вплотную к ней, чтобы проскальзывание при исполнении не подвело позицию под маржин-колл.

3. 03
   Задать уровень TP по глубине книги

   Уровень TP выбирается исходя из целевой прибыли, но с проверкой доступного объёма на этом участке цены — тонкая книга у цели ухудшит фактическое закрытие.

4. 04
   Выбрать тип исполнения после триггера

   Определить для каждого ордера market или limit: market почти гарантирует закрытие с возможным проскальзыванием, limit фиксирует цену, но рискует не исполниться полностью.

5. 05
   Проставить Reduce Only при частичном выходе

   Если выход разбит на несколько ордеров, для каждого отдельно включить Reduce Only, чтобы исключить случайное открытие встречной позиции.

6. 06
   Сверить выставленные ордера

   Проверить итоговый набор заявок через интерфейс или программный запрос к info endpoint, а не полагаться на память или последний визуальный снимок формы.

Пример: одна позиция, два исхода

Условный пример с округлёнными числами для иллюстрации механики, а не готовая формула расчёта. Позиция с notional 50 000 USDC при mark price 3000, margin tier с maintenance requirement около 1% от notional — то есть порядка 500 USDC. Допустим, при таком запасе маржи граница ликвидации оказывается на условном уровне около 2900. Точный расчёт для конкретного тира и размера позиции нужно проверять по актуальным параметрам margin tier, а не выводить из этого примера. Принцип остаётся верным: буфер до ликвидации — это расстояние от текущей mark price до границы, и SL логично ставить с запасом от неё, например на уровне 2950, а не вплотную к 2900.

Если SL на 2950 выставлен как limit-ордер, а рынок резким движением проходит уровень без остановки, лимитная заявка может не собрать встречный объём и остаться неисполненной — позиция продолжит двигаться к границе ликвидации без защиты. Та же позиция с SL на 2950, настроенным как market-триггер с условной tolerance 0.5%, в аналогичной ситуации, скорее всего, закроется в диапазоне 2935–2950 — хуже уровня триггера из-за проскальзывания на тонкой книге, но с закрытием позиции. Конкретный диапазон зависит от реальной глубины книги в момент исполнения.

Типичные ошибки при настройке защитных ордеров

Первая ошибка — путать mark price и last price при планировании уровней: триггер срабатывает по mark price, и если ориентироваться на цену последней сделки из другого источника, реальный уровень активации может отличаться от предполагаемого.

Вторая — ставить limit-триггер на SL без учёта глубины книги, рассчитывая, что рынок обязательно даст исполниться заявке ровно на нужной цене; при быстром движении это часто не так, и лимитный стоп превращается в отсутствие стопа.

Третья — забывать про Reduce Only при частичном выходе, из-за чего вместо сокращения позиции можно случайно нарастить противоположную экспозицию.

Четвёртая — не пересчитывать буфер до ликвидации после частичного закрытия: изменение размера позиции меняет maintenance requirement и расстояние до критического уровня.

Реальные ограничения этого подхода

Даже корректно настроенный market-триггер SL не даёт абсолютной гарантии цены закрытия — tolerance ограничивает отклонение, но не устраняет проскальзывание полностью на тонком рынке или при резком гэпе mark price. Limit-триггер может вообще не исполниться, и тогда единственной защитой остаётся ликвидация по правилам margin tier, что почти всегда хуже добровольного выхода.

Ещё одно ограничение: несколько частичных TP-ордеров увеличивают число условных заявок, за состоянием которых нужно следить отдельно. При автоматизации критичные решения об ордерах должны опираться на подтверждение через info endpoint, а не только на последний визуальный снимок формы, — websocket-снимок может отставать от реального состояния книги.

Как TP/SL сочетаются с cross и isolated margin

Режим маржи не меняет механику триггера TP/SL, но меняет цену вопроса при ошибке в его настройке. В isolated margin маржа ограничена конкретной позицией, поэтому неисполненный SL или закрытие по худшей цене влияет только на выделенный под эту позицию collateral. В cross margin доступный collateral общий для аккаунта, и та же самая ошибка в настройке TP/SL на одной позиции может задеть margin buffer остальных открытых позиций, потому что maintenance requirement считается по совокупности.

Из этого следует практический вывод: для позиций в cross margin запас у SL и выбор между market и limit триггером стоит подбирать консервативнее, чем для изолированной позиции того же размера, — цена ошибки здесь выше, чем просто убыток по одной сделке.

Проверка состояния TP/SL после установки

После того как защитные ордера выставлены, их существование стоит подтверждать не по визуальной форме в интерфейсе, а по фактическому состоянию аккаунта. Интерфейс и программный запрос к info endpoint отражают одно и то же состояние — то, по которому реально происходит matching, — но именно программная сверка полезна, если управление позицией частично автоматизировано или если TP/SL выставлялись через несколько последовательных действий.

Это особенно важно после любого изменения позиции: частичного закрытия, добавления маржи или смены режима margin. Каждое такое действие может сдвинуть параметры, от которых зависит расстояние до ликвидации, и старый TP/SL, рассчитанный для прежнего размера позиции, перестаёт соответствовать актуальному риску.