Официальная поддержка и антифишинг: как не передать ключи

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

Материал для опытного пользователя CEX и DeFi, знакомого с perpetual, funding и работой некастодиальных кошельков. Подходит тем, кто переводит капитал на Hyperliquid через нативный bridge и хочет выстроить дисциплину проверки транзакций перед подписью, а не просто узнать общие правила безопасности.

Что официальная поддержка никогда не спросит

Поддержка Hyperliquid и поддержка MetaMask не запрашивают seed-фразу, приватный ключ или полный доступ к кошельку для диагностики проблемы. Документация MetaMask прямо указывает: support никогда не требует Secret Recovery Phrase для решения проблемы с транзакцией. На Hyperliquid диагностика депозита или вывода строится на данных, видимых в блокчейне и в интерфейсе, — адресе, хэше транзакции, сети и сумме.

Просьба подключить кошелёк к стороннему сайту для проверки баланса, ввести фразу восстановления в форму или подписать транзакцию, которая якобы разблокирует зависшие средства, — признак фишинга в сценариях диагностики депозита, подписи на HyperEVM и работы с agent wallet.

Что проверять перед каждой подписью

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

MetaMask показывает эти параметры в окне подтверждения и рекомендует проверять phishing-домены. Rabby подтверждает наличие transaction simulation и security prompts, но отдельно отмечает: пользователь всё равно сам сверяет домен, сеть, spender, сумму и scope разрешения — интерфейс кошелька эту проверку не заменяет.

Onboarding Hyperliquid поддерживает вход по email и по DeFi-кошельку как два отдельных маршрута с разной моделью доступа к счёту, поэтому способ входа стоит выбирать осознанно.

Где риск концентрируется сильнее всего

Риск подписи заметнее всего при взаимодействии с HyperEVM: депозит, вывод и любые on-chain действия, где интерфейс запрашивает подпись с явными параметрами сети и контракта. Злоумышленник, подделавший страницу депозита USDC через Arbitrum, рассчитывает, что пользователь скопирует адрес bridge-контракта с фальшивой страницы, не сверив его с официальным интерфейсом.

Отдельная зона риска — переводы связанных spot-активов между HyperCore и HyperEVM: они идут по разным маршрутам, а HYPE как native asset требует наличия газа на нужной стороне для завершения перевода. Документация указывает на необходимость проверять system address перед таким переводом, поскольку именно он определяет корректность маршрута Core→EVM или EVM→Core. Момент подписи — единственная точка во всех этих сценариях, где действие уже нельзя отменить после подтверждения.

Изоляция риска: master address и agent wallet

Даже при аккуратной проверке подписи компрометация одного ключа возможна: заражённое устройство, скомпрометированное расширение, социальная инженерия. Здесь работает второй уровень защиты — разделение ролей между master address, которым пользователь управляет счётом и выводит средства, и agent wallet (в документации — API wallet), отдельным ключом только для отправки ордеров.

По документации, agent wallet подписывает ордера от имени master address или subaccount, но этим ключом нельзя прочитать состояние счёта, и он не является адресом для вывода — вывод жёстко привязан к master address и не делегируется агенту ни при каких правах. Кража ключа агента позволяет открывать и закрывать сделки от имени счёта, но не забрать баланс.

Практика ротации agent wallet

Из механики agent wallet следует вывод: после деактивации агента для дальнейшей торговли нужен новый адрес, а не повторное использование старого ключа. Документация указывает, что повторное использование адреса agent после деактивации связано с тем, как система обрабатывает nonce state уже подписанных этим адресом ордеров, и может помешать корректной обработке новых.

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

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

Условный пример: пользователь переводит на Hyperliquid через Arbitrum условную сумму 500 USDC — заметно выше задокументированного минимума маршрута bridge2 в 5 USDC. Если через условные 20–30 минут после отправки перевода баланс не обновился, порядок действий строится на последовательной сверке параметров транзакции, а не на обращении в чат с раскрытием данных кошелька.

1. 01
   Сверьте маршрут перевода

   Проверьте одновременно сеть Arbitrum, актив USDC и соответствие суммы задокументированному минимуму маршрута bridge2 в 5 USDC.

2. 02
   Найдите транзакцию в эксплорере

   Откройте публичный хэш в эксплорере Arbitrum и убедитесь, что сеть действительно подтвердила перевод.

3. 03
   Сопоставьте статус с документацией

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

4. 04
   Подготовьте публичные данные

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

5. 05
   Обратитесь в официальную поддержку

   Передайте support только публичный хэш и описание маршрута; seed-фраза, приватный ключ и удалённый доступ не нужны для диагностики.

Вывод средств и роль способа входа

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

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

Признаки фишинга и интерфейс как ориентир

Диагностику депозита, подпись на HyperEVM и работу с agent wallet объединяет один набор признаков: просьба ввести seed-фразу или ключ в любую форму, домен с лишним символом или поддоменом вместо официального, и давление на срочность — обещание разблокировать «зависшие» средства сразу после подписи или подключения кошелька к стороннему сайту. Проверка через хэш транзакции от скорости реакции не зависит: записи в блокчейне уже существуют.

Официальный интерфейс Hyperliquid остаётся ориентиром для рынков, режима маржи, комиссий, маршрутов перевода и статуса позиции. Любое расхождение между тем, что показывает сторонняя ссылка или чат поддержки, и тем, что видно в официальном интерфейсе, — повод остановиться и проверить ещё раз. HyperCore и HyperEVM объединены общим консенсусом HyperBFT, но для трейдера это означает одно правило: параметры сети и контракта проверяются в актуальном интерфейсе, а не по памяти.

Почему письменный чек-лист надёжнее памяти

Проверка домена, сети, адреса контракта и суммы занимает меньше времени, чем восстановление счёта после ошибки, но именно спешка перед подписью чаще всего приводит к пропуску одного из пунктов. Короткий список из четырёх-пяти параметров — домен, сеть, адрес получателя или контракта, сумма и объём разрешений — практичнее памяти при каждой новой операции, особенно если депозиты и выводы происходят нерегулярно.

Это особенно актуально для тех, кто переключается между несколькими кошельками или способами входа: MetaMask, Rabby, email-доступ и agent wallet имеют разные интерфейсы подтверждения, и привычка из одного не переносится автоматически на другой. Единый список параметров, а не заученный интерфейс конкретного инструмента, снижает риск ошибки при смене инструмента.