Как проверять домен, подпись и разрешения кошелька

Для какого профиля позиции

Материал для опытных пользователей CEX/DEX, которые уже работают с perpetual, funding и stablecoin-переводами, но хотят системно закрыть операционный риск на уровне кошелька перед тем, как увеличивать объём капитала на Hyperliquid.

Почему проверка подписи важнее выбора стратегии входа

Перед первой позицией на Hyperliquid стоит решить не как торговать, а как подписывать. Способ входа определяет, кто хранит приватный ключ и насколько легко ошибиться в момент, когда интерфейс просит подпись. Onboarding-документация Hyperliquid описывает email-доступ и подключение DeFi-кошелька как отдельные пути к торговле и депозиту — это разные механизмы хранения ключа с разным уровнем ручного контроля над подписью.

Капитал на Hyperliquid разнесён по трём слоям: депозит USDC идёт через сеть Arbitrum One и нативный bridge (контракт bridge2), торговля и маржа считаются в HyperCore на книге ордеров, а связанные spot-активы отдельным маршрутом Core↔EVM переносятся в HyperEVM для взаимодействия со смарт-контрактами. Подтверждение обычного ордера в HyperCore от выбора кошелька почти не зависит — там нет отдельного окна с адресом контракта и суммой approve. Риск концентрируется там, где действие выходит за пределы HyperCore и требует подписи на уровне сети: при депозите, выводе или операциях на HyperEVM.

Три слоя проверки: домен, содержание подписи, разрешения

Домен — первый слой. Проверяется адресная строка браузера перед тем, как кошелёк открывает окно подтверждения: совпадает ли адрес с официальным интерфейсом. Фишинговые сайты копируют интерфейс Hyperliquid и используют похожие домены — тайпсквоттинг, замену символов легко пропустить при беглом взгляде, нужна посимвольная сверка.

Содержание подписи — второй слой. MetaMask показывает отдельное окно подтверждения с сетью, адресом контракта и суммой. Это позволяет сверить: та ли сеть (Arbitrum One), тот ли контракт (совпадает ли с официальным bridge2 или Core↔EVM маршрутом) и та ли сумма, что вводилась в интерфейсе.

Разрешения — третий слой, который проще всего пропустить. Rabby даёт дополнительный сигнал: встроенная симуляция транзакции показывает, какие балансы изменятся и какие разрешения выдаются. Approve на неограниченную сумму токена внешнему контракту — не то же самое, что approve на конкретную сумму под конкретную операцию, и симуляция делает эту разницу видимой до отправки.

Сценарий: депозит USDC через Arbitrum и bridge2

Чтобы перевести USDC с Binance, Bybit или OKX на Hyperliquid, сначала выведите USDC с биржи в сети Arbitrum One на адрес своего кошелька, а затем внесите его в Hyperliquid через нативный bridge (контракт bridge2), который также работает через Arbitrum. Ключевые условия: актив именно USDC, а не USDT; сеть Arbitrum One, а не другая сеть по умолчанию; сумма не ниже минимального порога bridge2, который на момент проверки документации составлял 5 USDC.

Адрес контракта стоит сверить в официальном интерфейсе Hyperliquid перед отправкой. На кастодиальной бирже баланс — запись в системе биржи; на Hyperliquid маржа привязана к адресу пользователя на книге ордеров HyperCore, а не к кастодиальному балансу платформы. Именно на этом стыке домен, подпись и адрес контракта нужно проверять максимально внимательно: сама операция необратима, а результат ошибки в сети или активе, по описанию поддержки Hyperliquid, зависит от типа входа и маршрута.

Пошаговый план проверки перед первой подписью

Разовая проверка перед первым депозитом или выводом снимает большую часть операционного риска на HyperEVM. Каждый шаг закрывает отдельный слой и не даёт пропустить его в спешке.

1. 01
   Шаг 1 — сверить домен

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

2. 02
   Шаг 2 — прочитать окно подтверждения

   В MetaMask или Rabby проверьте сеть (Arbitrum One), адрес контракта (bridge2 или Core↔EVM маршрут) и сумму — все три поля должны совпадать с тем, что вводилось в интерфейсе.

3. 03
   Шаг 3 — проверить scope разрешения

   Если запрашивается approve, выясните, ограничена ли сумма конкретной операцией или открывает доступ к большему балансу токена; в Rabby это видно через симуляцию, в MetaMask — вручную по полю разрешения.

4. 04
   Шаг 4 — подписать и зафиксировать хэш

   После подписи сохраните хэш транзакции, сеть и время — это понадобится для обращения в поддержку, если результат не совпадёт с ожиданием.

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

Большинство потерь на этапе подписи связано не с незнанием риска, а с пропуском одного из трёх слоёв проверки в спешке.

• Подписывать транзакцию, не открывая окно подтверждения полностью — сеть и адрес контракта скрыты за коротким текстом
• Путать сеть по умолчанию, предложенную биржей при выводе, с Arbitrum One, требуемым для депозита через bridge2
• Игнорировать симуляцию Rabby и подписывать approve на неограниченную сумму там, где нужен лимит под конкретную операцию
• Доверять каналу поддержки, который запрашивает seed phrase «для диагностики» проблемы с депозитом
• Использовать email-доступ там, где нужна ручная проверка каждого on-chain шага, полагая, что контроль идентичен DeFi-кошельку
• Переходить по ссылке из чата или соцсети вместо прямого перехода на официальный интерфейс, пропуская проверку домена

Асимметрия цены проверки и цены ошибки

Источники не приводят статистики вероятности ошибки на этапе подписи или размера типовых потерь — количественных данных для реального кейса в них нет. Но качественная логика прослеживается чётко: сверка домена, сети, адреса контракта и суммы перед подписью занимает меньше минуты. Стоимость ошибки, напротив, растёт вместе с размером транзакции: если сеть в окне подтверждения не Arbitrum One, а другая сеть, предложенная биржей по умолчанию, средства уходят не туда, куда планировалось для маршрута bridge2 — и на условном небольшом тестовом переводе, и на условном крупном депозите механизм один и тот же.

Та же логика распространяется на approve при работе с HyperEVM-контрактами. Разрешение на неограниченную сумму токена, выданное один раз, остаётся действующим, пока пользователь не отзовёт его вручную; разрешение, ограниченное конкретной операцией, закрывает этот риск сразу после исполнения транзакции. Разница между двумя вариантами не отображается в момент подписи явным текстом — её видно только через симуляцию Rabby или ручное чтение поля разрешения в MetaMask, и именно этот шаг чаще всего пропускают в спешке.

Где эта проверка не спасает от ошибки

Три слоя проверки закрывают конкретный риск — подмену интерфейса и избыточные разрешения. Есть ситуации, которые они не покрывают.

• Проверка домена и подписи не защищает от ошибки в самой сумме или адресе получателя, если они введены неверно ещё до открытия окна подтверждения
• Симуляция транзакции в Rabby показывает ожидаемый эффект, но не гарантирует, что сеть не изменит поведение контракта между симуляцией и фактическим исполнением
• Email-доступ убирает саму возможность такой проверки на уровне подписи, потому что ключ и подтверждение скрыты внутри интерфейса Hyperliquid — осознанный компромисс простоты в обмен на контроль
• Минимальный порог депозита и адрес контракта bridge2 со временем могут измениться, поэтому перед переводом стоит свериться с официальным интерфейсом, а не с цифрой, запомненной с прошлого раза

Как разделение master address и agent wallet снижает цену одной ошибки

Смежный вопрос — какой адрес вообще подписывает операции. Agent wallet (он же API wallet) может подписывать ордера от имени master address или subaccount, но не может инициировать вывод средств — это ограничение уровня протокола, а не настройка интерфейса. Практический смысл: если ключ agent скомпрометирован именно на этапе неаккуратной подписи, под риском оказывается только маржа, выделенная под него через subaccount, а не весь баланс master.

Это снижает последствия компрометации, но не заменяет саму проверку домена, сети и разрешений при каждой подписи. Дополнительная деталь: после отключения agent (deregistration) его адрес нельзя использовать повторно — протокол считает такой адрес недействительным для новых подписей, поэтому для новой роли нужен новый agent-кошелёк, а не переиспользованный старый ключ.

Что делать, если депозит или подпись вызвали сомнение после отправки

Если транзакция уже подписана и расхождение — не та сеть, не тот адрес или неожиданный scope approve — замечено постфактум, шаги ограничены. Первый — обращение в поддержку Hyperliquid с деталями транзакции (хэш, сеть, сумма, время); дальнейший результат зависит от типа входа и конкретного маршрута. Официальный канал поддержки не запрашивает seed phrase для диагностики — такой запрос от его имени является признаком фишинга.

Для approve с избыточным scope ситуация отличается: пока средства не списаны, разрешение можно отозвать вручную через тот же кошелёк, которым оно было выдано. Это не отменяет факт временного риска, но ограничивает его дальнейшее действие. До подписи достаточно свериться по трём слоям за минуту; после подписи приходится полагаться на диагностику с неопределённым исходом.