Отдельный trading wallet: как изолировать операционный риск

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

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

Почему один адрес для всего — это концентрация риска

Типичный путь: завести кошелёк через email или MetaMask, задепонировать USDC через нативный bridge, начать торговать — и остановиться на этом. Один адрес хранит капитал, подписывает каждый ордер, взаимодействует с HyperEVM-контрактами и иногда участвует в staking HYPE. Каждая точка контакта с внешним интерфейсом, скриптом или контрактом становится вектором риска для всего баланса сразу.

Маржа на Hyperliquid привязана к адресу пользователя на книге ордеров HyperCore, а не к кастодиальному балансу площадки — это структурно ближе к self-custody, чем модель CEX. Но self-custody не отменяет операционный риск, а перекладывает ответственность за изоляцию ключей на пользователя.

Механика разделения: master address, agent wallet и subaccount

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

Ниже по тексту используется собственное обозначение для удобства изложения: связка master address как хранителя капитала и точки вывода, agent wallet как инструмента подписи для автоматизации, и при необходимости subaccount как слоя для изоляции конкретной стратегии. Это авторская концептуализация статьи для описания практики распределения ролей, а не официальная терминология Hyperliquid. Размер маржи, доступной agent через subaccount, — решение пользователя, а не встроенное свойство самого инструмента подписи.

Условный сценарий: торговый бот на agent wallet

Трейдер запускает автоматизированную стратегию через API. Частая ошибка — выдать скрипту приватный ключ master address, чтобы бот мог и торговать, и выводить прибыль. Любая уязвимость в коде или утечка ключа в логах превращает автоматизацию в канал полной потери капитала.

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

Если сервер с ботом скомпрометирован, злоумышленник может слить выделенную на subaccount маржу через убыточные сделки, но не может вывести её на внешний адрес. Потеря ограничена суммой, осознанно выделенной под стратегию, а не всем балансом master.

Где разделение ролей даёт структурное преимущество

На CEX права API-ключа для бота тоже можно ограничить настройками биржи, но конечный контроль остаётся внутри кастодиальной системы платформы: вывод и учёт баланса завязаны на её внутренние процессы. На Hyperliquid agent wallet подписывает торговые действия от имени master или subaccount, но не относится к адресам, с которых доступен вывод средств.

Такое разграничение работает только при условии, что пользователь создаёт отдельный agent wallet для автоматизации, а не подписывает всё через master напрямую.

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

Разделение ролей сужает риск до суммы, выделенной под agent wallet через subaccount, но не защищает саму эту маржу от ошибок или злонамеренных действий бота — если лимит на subaccount велик, потери в его рамках могут быть полными.

После deregistration адрес agent wallet не следует использовать повторно: nonce state привязан к конкретному agent, и переиспользование адреса создаёт риск конфликтов подписи.

Делегация HYPE блокируется на один день при входе и требует семидневной очереди при выходе обратно на spot. Если часть маржи оказалась в staking, вернуть её моментально не получится, и это нужно учитывать при распределении капитала между ролями.

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

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

Вторая — путать subaccount с полной изоляцией риска на уровне отдельного адреса. Subaccount снижает смешение стратегий внутри аккаунта, но остаётся частью общей системы — это инструмент организации капитала, а не замена кошелька с собственной seed-фразой.

Третья — не учитывать сроки блокировки при переводе капитала между ролями: перевод части маржи в staking без запаса на семидневный вывод способен оставить торговый баланс без нужного объёма именно в момент возможности для входа.

Пошаговый план построения изоляции ролей

Порядок действий для перехода от одного адреса на всё к разделённой схеме.

1. 01
   Определить master address и перевести его в холодный режим

   Выбрать адрес, который останется единственной точкой вывода капитала. Его приватный ключ не передаётся ни одному скрипту, боту или сторонней автоматизации.

2. 02
   Создать отдельный agent wallet для автоматизации

   Для каждой стратегии или бота выпускается собственный API wallet, подписывающий ордера от имени master или subaccount без доступа к выводу средств.

3. 03
   Выделить subaccount под конкретную стратегию

   Маржа, которой рискует бот, переносится на subaccount в объёме, который пользователь готов потерять полностью при провале стратегии, а не привязывается к общему балансу master.

4. 04
   Проверить права agent wallet перед запуском

   Убедиться, что agent действительно не может читать состояние аккаунта на уровне, дающем контроль над выводом, и что лимит на subaccount соответствует допустимому риску.

5. 05
   Спланировать сроки при использовании staking HYPE

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

6. 06
   Не переиспользовать agent wallet после deregistration

   При завершении цикла работы бота или смене стратегии создавать новый agent wallet вместо повторной активации старого адреса, чтобы избежать конфликтов nonce state.