Post Only, IOC, GTC и Reduce Only на практике

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

Материал рассчитан на трейдера, который уже открывал perpetual-позиции на CEX или DEX, понимает разницу между maker и taker, знает, что такое funding и margin tier, и хочет перейти от базового market/limit к точному управлению исполнением на Hyperliquid через комбинацию режимов TIF и Reduce Only.

Что означают ALO, IOC, GTC и Reduce Only на уровне протокола

На Hyperliquid типы исполнения задаются как параметры ордера в exchange endpoint, а не как отдельные виды заявок. Базовый тип — limit или market, поверх него накладывается time-in-force и флаг Reduce Only. ALO (add liquidity only) — название поля API для Post Only: если лимитная цена пересекает противоположную сторону книги в момент отправки, ордер отменяется целиком, а не исполняется частично как taker. IOC (immediate or cancel) исполняет всё, что доступно немедленно, и отменяет неисполненный остаток без постановки в очередь. GTC (good till cancelled) — стандартный режим лимитной заявки, остающейся в книге до исполнения или явной отмены. Reduce Only — независимый флаг, комбинируемый с любым из этих режимов: он гарантирует, что ордер не увеличит позицию, а при недостаточном её размере для покрытия объёма заявки сократит исполняемый объём или отменит его.

Сценарий: вход лимитной заявкой без риска taker-комиссии

Вы хотите набрать позицию вблизи mid price, не переплачивая taker-комиссию и не рискуя моментальным исполнением по худшей цене при резком движении книги. Обычный GTC-лимит, поставленный слишком близко к спреду, может в момент отправки оказаться агрессивнее задуманного и исполниться как taker, если цена уже пересекла уровень. ALO решает это жёстко: если на момент отправки цена пересекает противоположную сторону книги, биржа отменяет ордер целиком вместо частичного taker-исполнения. Это защищает от непреднамеренного market-fill, но требует смириться с тем, что заявка может не встать в книгу вовсе, если рынок ушёл. ALO подходит для терпеливого набора позиции внутри спреда или на уровнях поддержки, но не годится, если нужно гарантированно оказаться в позиции к определённому моменту.

Почему явное разделение режимов даёт больше контроля, чем один переключатель

На части CEX Post Only реализован как автоматическая подрезка цены до ближайшего maker-уровня: биржа тихо меняет лимит, и заявка исполняется по цене, которую трейдер явно не указывал, вместо прозрачной отмены. Hyperliquid поступает иначе: ALO либо встаёт в книгу по указанной вами цене, либо отменяется целиком — без скрытой корректировки лимита. То же с IOC и GTC: это явные поля ордера exchange endpoint, а не производное поведение одного переключателя «безопасный вход», как иногда упаковано в интерфейсах CEX. Это позволяет комбинировать флаги предсказуемо — например, отправить ALO с Reduce Only для добавления к TP-уровню без риска нарастить позицию, если книга сдвинулась. Это не делает исполнение быстрее или дешевле по умолчанию — на CEX с глубокой книгой такие комбинации тоже возможны, а onboarding там часто проще. Конкретное преимущество здесь в том, что цена и объём исполнения не подменяются биржей без вашего ведома: поведение каждого флага соответствует тому, что указано в ордере, а не молчаливой перезаписи параметров бэкендом.

Реальные ограничения: что режимы TIF не решают

IOC исполняет только доступный на момент отправки объём — на тонкой книге это частичное исполнение по заметно худшей средней цене, чем видимая mid price, так как заявка поглощает несколько уровней подряд. ALO не защищает от того, что заявка вообще не встанет в книгу на волатильном рынке, если цена постоянно уходит в сторону лимита. GTC-ордер без присмотра может исполниться спустя долгое время по цене, уже не соответствующей тезису, поскольку срока действия по умолчанию у него нет. Reduce Only не гарантирует полное закрытие позиции одним ордером — при недостаточной ликвидности исполнится только часть, а остаток отменится или останется ждать в зависимости от TIF. Ни один режим не устраняет проскальзывание как таковое — оно определяется соотношением размера ордера и глубины книги на конкретных уровнях. Практический ориентир: если объём ордера превышает объём на первых 2-3 уровнях книги, стоит заранее считать среднюю цену по нескольким уровням, а не мгновенную реакцию флага.

Типичные ошибки при выборе режима исполнения

Самая частая ошибка — market-ордер там, где подошёл бы IOC с лимитной ценой: market не ограничивает проскальзывание, тогда как IOC с разумным лимитом исполнит доступный объём и отменит остаток, если цена ушла слишком далеко. Вторая по частоте — ставить Reduce Only на вход в новую позицию по привычке: флаг предназначен для закрытия и урезает или отменяет заявку, если позиции ещё нет или она меньше желаемого объёма. Реже, но болезненнее — не проверять статус ALO-ордера после отправки: заявка может быть отменена биржей без исполнения, и при работе через API без polling статуса бот может считать позицию открытой, когда её на самом деле нет. Ещё одна ошибка — ставить GTC с крупным объёмом на тонком активе без разбивки на части: заявка долго стоит в очереди и сигнализирует рынку о крупном интересе на конкретном уровне.

Условный числовой пример: закрытие половины позиции через Reduce Only с IOC

Допустим (числа условные), у вас длинная позиция 2 BTC, последняя сделка прошла по 100 000 USDC, и вы хотите зафиксировать половину прибыли. Вы отправляете ордер на продажу 1 BTC с флагом Reduce Only и режимом IOC, лимит — 99 900 USDC (на 0,1% ниже последней сделки). Если на уровнях от 100 000 до 99 900 в книге стоит встречных бидов на 1,3 BTC, ордер исполняется полностью: позиция сокращается ровно на 1 BTC без риска открыть шорт сверху. Если на этих уровнях доступно только 0,6 BTC, IOC исполнит именно эти 0,6 BTC по средней цене чуть хуже 100 000 и отменит оставшиеся 0,4 BTC. В этом случае вы получаете частичный fill и как отдельное последующее действие — не автоматическое продолжение того же ордера — можете вручную поставить новый лимитный ордер по обновлённой цене либо TP/SL, который сработает по mark price и закроет остаток market-вариантом в пределах заданной tolerance.

Пошаговый план выбора режима перед отправкой ордера

Ниже — последовательность проверок перед отправкой ордера, а не только теория.

1. 01
   Определите цель ордера

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

2. 02
   Оцените глубину книги на нужных уровнях

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

3. 03
   Выберите TIF исходя из терпимости к отсутствию fill

   Если критично не переплатить taker-комиссию и вы готовы ждать — ALO. Если важно исполниться сейчас с ограничением на цену — IOC. Если позиция набирается постепенно без спешки — GTC.

4. 04
   Добавьте Reduce Only для любых закрывающих действий

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

5. 05
   Проверьте статус ордера после отправки

   ALO и IOC могут завершиться полной или частичной отменой без исполнения — это нужно обрабатывать в торговой логике или ручным контролем, а не предполагать по умолчанию.

6. 06
   Сверьте фактическую цену исполнения с планом

   После fill сравните среднюю цену исполнений с ожидаемой mid price на момент отправки, чтобы откалибровать размер будущих ордеров и лимитные уровни.