Hyperliquid vs dYdX: две модели onchain perpetuals

Какой сценарий вы сравниваете

Материал для трейдера, который уже работает с perpetual на CEX или DEX, понимает механику funding, margin tier и order book, и сравнивает Hyperliquid с dYdX не по маркетинговым тезисам, а по архитектуре, workflow депозита и практике исполнения ордеров.

Архитектурная разница: единый L1 против отдельной chain-модели

Hyperliquid построен как L1 с двумя средами на общем консенсусе HyperBFT: HyperCore для книги ордеров perpetual и spot, и HyperEVM как EVM-совместимая среда для смарт-контрактов. Торговый движок и контрактная среда работают на одной инфраструктуре, хотя капитал технически проходит через разные слои при переносе между HyperCore и HyperEVM. dYdX документирует отдельную onchain perpetual architecture со своей сетью, indexers для получения данных и собственным API — это иная модель разделения ответственности между сетью и торговым движком.

Для трейдера это различие ощутимо не в момент открытия обычного ордера, а при работе с данными аккаунта, депозитами и любой интеграцией через API. Проверка актуального маршрута, формы ордера и статуса позиции в обоих случаях требует обращения к первичному интерфейсу платформы, а не к сторонним агрегаторам.

Кастоди и маржа: адрес пользователя против сетевого аккаунта

На Hyperliquid маржа привязана к адресу пользователя в книге ордеров HyperCore, а не к внутренней записи биржи. Вывод не зависит от решения третьей стороны — контроль и ответственность за приватный ключ лежат на трейдере. Баланс, открытые позиции и историю fills трейдер проверяет через официальный торговый интерфейс, где отображается фактическое состояние аккаунта на HyperCore.

dYdX как отдельная сеть также реализует onchain-модель аккаунта со своим набором инструментов для чтения состояния через indexers. Механика subaccounts и расчёта маржи на dYdX в приложенных источниках не детализирована на том же уровне, что и у Hyperliquid, поэтому прямое сопоставление этих двух моделей числами здесь не приводится.

Проверка исполнения ордера: глубина книги вместо mid price

На HyperCore книга ордеров построена по классической модели с уровнями цены и объёма, поэтому анализ исполнения нельзя сводить к одной цифре mid price. Документация Hyperliquid описывает несколько параметров, которые формируют фактическую цену сделки: доступный объём на каждом уровне, положение заявки в очереди maker-стороны, текущий spread между лучшим бид и аском, а также среднюю цену по нескольким частичным fills, если ордер исполняется не одним объёмом.

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

В сравнении с CEX-практикой это не новый принцип, но на perpetual DEX ликвидность по конкретному рынку может быть заметно тоньше, чем на топовых парах централизованных бирж, поэтому привычка проверять глубину книги, а не полагаться на отображаемую mid price, имеет более прямое влияние на итоговый результат сделки.

Депозит и первый вход: конкретный маршрут на Hyperliquid

Onboarding-документация Hyperliquid описывает вход по email и подключение DeFi-кошелька как два отдельных пути к торговле с разным уровнем контроля над ключом. Для USDC базовый документированный путь — нативный bridge, связанный с сетью Arbitrum; актуальный интерфейс показывает и другие поддерживаемые deposit rails. Перед первым переводом стоит сверить адрес контракта и сумму непосредственно в официальном интерфейсе — конкретное числовое значение минимального порога в источниках не зафиксировано и в материале рассматривается как условная величина.

Для dYdX первый шаг — подключение к сети протокола и прохождение её собственного onboarding. Маршрут Hyperliquid прослеживается по документации до конкретного bridge-контракта на Arbitrum, тогда как по dYdX источники раскрывают только общую архитектуру сети без перечисления конкретных deposit rails и минимальных сумм.

Порядок действий перед переводом капитала на Hyperliquid

Перенос капитала с кастодиального баланса CEX на Hyperliquid стоит выполнять по проверяемой последовательности, а не разовым переводом всей суммы. Порядок ниже основан на документированном onboarding и структуре официального интерфейса.

1. 01
   Выбрать путь входа

   Определить, какой способ входа подходит: вход по email с меньшим контролем над ключом или подключение DeFi-кошелька с полным контролем над приватным ключом. Это влияет на то, как в дальнейшем выполняется вывод средств.

2. 02
   Сверить адрес контракта и маршрут депозита

   Открыть официальный интерфейс и проверить актуальный адрес bridge-контракта, связанного с сетью Arbitrum для USDC, либо другой поддерживаемый deposit rail, отображаемый в интерфейсе на момент операции. Не использовать адреса из сторонних источников.

3. 03
   Отправить тестовый перевод малой суммы

   Перед переводом основной суммы отправить небольшую тестовую сумму по проверенному маршруту, чтобы убедиться в корректности адреса и скорости зачисления средств именно на выбранном deposit rail.

4. 04
   Сверить баланс в официальном интерфейсе

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

5. 05
   Перевести основную сумму

   Только после успешной проверки тестового перевода и корректного отображения баланса переводить остальной капитал, ориентируясь на тот же маршрут и тот же адрес контракта.

6. 06
   Проверить состояние аккаунта перед первым ордером

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

Ликвидность и выбор платформы по конкретному рынку

Архитектурные различия между Hyperliquid и dYdX не отвечают на вопрос, где выгоднее торговать конкретным активом прямо сейчас. Источники по обеим платформам указывают на то, что фактическая ликвидность, глубина книги и spread по нужному рынку — параметры, которые нужно проверять непосредственно в интерфейсе платформы на момент сделки, а не выводить из общей архитектуры сети.

Для трейдера с интеграцией через API или бота значение имеет не только модель custody, но и то, какие order types, indexers и endpoints документированы и поддерживаются на практике. dYdX формально документирует более широкий набор network-инструментов для чтения состояния через indexers; Hyperliquid описывает интерфейс и API как производные от состояния HyperCore. Выбор платформы для конкретной стратегии в итоге определяется тем, какой workflow ближе к уже существующей инфраструктуре трейдера и какая ликвидность фактически доступна на нужном рынке в моменте.

Что проверить перед переносом стратегии между платформами

Перед тем как переносить работающую на одной платформе стратегию на другую, стоит свериться с несколькими пунктами, которые прямо влияют на исполнение и custody, а не только на комиссии. Во-первых, способ хранения ключа и путь вывода средств — модель адреса пользователя на HyperCore и сетевая модель аккаунта dYdX предполагают разные точки ответственности. Во-вторых, маршрут депозита: для Hyperliquid это конкретный bridge-контракт на Arbitrum и альтернативные rails, отображаемые в интерфейсе, для dYdX — прохождение сетевого onboarding без детализированного в источниках перечня rails.

В-третьих, при переносе алгоритмической стратегии важно заново проверить, как формируется цена исполнения: на HyperCore это книга ордеров с уровнями, очередью и spread, а не единая mid price, которую можно взять за основу расчёта проскальзывания без дополнительной проверки. Наконец, стоит свериться с фактической глубиной книги и ликвидностью именно на том рынке, где предполагается торговать, поскольку общая архитектура платформы не гарантирует одинаковую глубину по всем инструментам одновременно.