DeFi. Uniswap v.4. Хуки (Hooks). Часть III. Безопасная работа с пулами Uniswap V4 (LP)

Проверка пула

Если вы - LP, то при создании пула и работе с ним - необходимо:

1. Убедиться, что пул существует в официальном Uniswap V4 Factory. Сверьте адрес пула через официальную документацию или интерфейс.
2. Проверить адрес hook-контракта, привязанного к пулу. Hook-контракт — внешний смарт-контракт, на который пул делегирует логику (например, комиссии, ограничения, действия до/после свапов).
3. Проверить, верифицирован ли hook-контракт на Etherscan. Желательно, чтобы код был открыт и аудитирован.

Анализ hook-контракта

Следующий уровень:

1. Проверить, какие hook-функции реализованы (beforeSwap, afterSwap, beforeAddLiquidity и т.д.). Вредоносный хук может, например, блокировать выход LP, брать комиссии, менять правила пула.
2. Проверить наличие искажения логики в afterAddLiquidity или beforeRemoveLiquidity. Вредоносный код может украсть токены или заблокировать вывод.
3. Проверить, есть ли доступ к внешним вызовам или переменным, которые могут меняться вне пула. Это может быть использовано для манипуляций.

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

Ещё один уровень - это:

1. Протестировать ввод ликвидности с минимальной суммой. Убедитесь, что добавление и удаление ликвидности работает без ошибок или странных задержек.
2. Использовать приватный RPC и отслеживай входящие события. Некоторые хуки могут вести логи или пытаться деанонимизировать LP.
3. Проверять лимиты газа при действиях с пулом. Вредоносный хук может специально "тормозить" транзакции для атак.

Инструменты и ресурсы

Проверить пул на сервисах навроде eigenphi.io. Посмотреть пул в интерфейсах с фильтрацией хуков: некоторые фронтенды скрывают пулы с неаудированными хуками.

Чего нужно избегать?

Не полный перечень:

1. Пулов с приватными hook-контрактами.
2. Пулов без верификации кода.
3. Пулов, созданных неизвестными адресами.
4. Хуков с доступом к внешним токенам или управлением разрешениями.
5. Пулов с хуками с малой ликвидностью, если вы - начинаете путь в DeFi.

Как построить безопасную стратегию маршрутизации в Uniswap V4?

Соблюсти 2 простых правила:

• Исключить маршруты, ведущие через вредоносные и/или непроверенные хуки (см. в предыдущих статьях);
• Сохранять гибкость и оптимальность маршрута, используя V4, но с фильтрами.

Подход: "hook-aware routing"

Фильтрация пулов с хуками:

• Поддерживайте белый список хуков;
• Используются только те hook-контракты, чья логика:
• полностью верифицирована;
• проверена вручную или аудирована;
• не включает сложную или изменяемую бизнес-логику.
• Применяйте (пока) маршрутизацию только через нативные (безхуковые) пулы (используй опцию маршрутизации через пулы без hook-контракта (null hook). Это значит, что пул работает как классический V3.

• Динамический аудит хуков по ABI: Автоматически анализируй ABI hook-контрактов на наличие нежелательных методов:
• beforeSwap с внешними вызовами;
• afterSwap с неограниченной логикой;
• beforeRemoveLiquidity с логикой блокировки.
• Fail-safe fallback: Если пул с потенциально опасным хуком — автоматически перенаправлять маршрут через альтернативные пулы, даже если цена чуть хуже.
• UniswapX relayer должен быть hook-aware. В идеале UniswapX-рилайер (или свой бот) должен:
• Иметь whitelist-хуков;
• Отказаться от маршрутов, где hook делает external calls в токены.

Категории хуков и их безопасность

Что можно считать безопасными hook-контрактами?

Безопасные хуки:

• Hooks от команды Uniswap или проверенных проектов;
• Hooks с открытым исходным кодом и аудитом;
• Минималистичные хуки, реализующие только calculateFee с фиксированной логикой (например, swap fee 0.05%);
• Hooks без before/after логики — пассивные.

Подозрительные хуки:

• Контракты без верифицированного кода;
• Хуки с beforeRemoveLiquidity, afterSwap, где есть external calls;
• Хуки с переменными, управляемыми DAO или владельцем (возможна смена логики на лету).

Это конечно не всё, но для начала хватит, а пока -

До!