Разработка кастомных хуков для Uniswap v4
Uniswap v4 изменил архитектуру радикально: один singleton-контракт PoolManager управляет всеми пулами, а расширения логики — через хуки. Это не просто callback-и. Хуки получают контроль над критическими точками жизненного цикла пула: до и после инициализации, до и после свапа, до и после добавления/удаления ликвидности. Правильно написанный хук позволяет встроить limit orders, динамическое ценообразование, fee rebate, MEV-capture — без форка протокола. Неправильный — заблокирует пул или станет вектором атаки.
Архитектура хуков: что важно понять до написания кода
Флаги и permissions
Адрес хука кодирует разрешения в битах. Биты 0-7 определяют, какие callback-и активны: BEFORE_SWAP_FLAG, AFTER_SWAP_FLAG, BEFORE_ADD_LIQUIDITY_FLAG и т.д. Если хук объявляет getHookPermissions() с флагом afterSwap: true, но адрес деплоя не содержит соответствующий бит — PoolManager ревертнёт при инициализации пула.
Это означает: адрес контракта хука не произвольный. Нужен CREATE2-деплой с подбором salt до совпадения нужных битов в адресе. Для сложного хука с 4-5 флагами подбор salt — отдельная задача, которую решают off-chain скриптом.
PoolKey и изоляция пулов
Каждый пул в v4 идентифицируется PoolKey: {currency0, currency1, fee, tickSpacing, hooks}. Адрес хука — часть идентификатора пула. Два пула с одинаковыми токенами и fee, но разными хуками — разные пулы с разными liquidity positions. Это значит: ликвидность нельзя «мигрировать» между хуками без полного вывода и ввода.
transient storage и EIP-1153
V4 активно использует EIP-1153 transient storage — хранилище, которое очищается в конце транзакции. Это дешевле SSTORE/SLOAD и идеально для временного состояния внутри транзакции (например, флаг «свап уже идёт»). Хуки могут использовать transient storage для reentrancy-защиты без постоянного storage overhead.
Типичные кейсы хуков и их сложности
Dynamic fee hook
Самый популярный запрос: fee, которая меняется в зависимости от волатильности. Логика afterSwap: считаем отклонение от TWAP, если >threshold — повышаем fee для следующего свапа через poolManager.updateDynamicLPFee().
Проблема: TWAP нужно хранить in-hook. Если используем Uniswap v3 TWAP оракул как reference — это внешний вызов из afterSwap, что увеличивает gas cost каждого свапа на 3-5k gas. Альтернатива: собственный rolling TWAP в hook storage, обновляемый в afterSwap. Дешевле, но требует bootstrap периода и обработки edge case при первых свапах.
Второй нюанс: updateDynamicLPFee можно вызвать только если пул инициализирован с FEE_DYNAMIC_FLAG. Этот флаг должен быть установлен в fee поле PoolKey при создании пула. Пропустить — контракт задеплоен, пул создан, хук не работает. Переиграть нельзя.
Limit order hook
beforeSwap проверяет, есть ли pending limit orders в диапазоне текущего тика. Если да — исполняет их как часть свапа. Реализация: маппинг tick => orders[], обход при пересечении тика.
Главный риск: unbounded loop по orders на тике. Если на одном тике накопилось 500 ордеров, один свап через этот тик потратит >1M gas и упрётся в block gas limit. Защита: ограничение на количество ордеров на тик + батчинг исполнения через отдельную keeper-функцию для накопленных ордеров.
MEV capture через afterSwap fee redistribution
Идея: часть fee от свапа, который вызвал значительное движение цены (подозрение на MEV), перенаправляется в отдельный пул компенсаций для LP. afterSwap считает price impact, если выше порога — отправляет дополнительный платёж в vault.
Техническая сложность: afterSwap получает delta — изменение балансов. Нужно рассчитать price impact на основе delta и начального состояния пула. Начальное состояние пула нужно снять в beforeSwap и сохранить в transient storage — чтобы в afterSwap можно было сравнить. Это классический паттерн для пар beforeX/afterX хуков.
Инструменты разработки
Foundry — единственный нормальный выбор для v4 хуков. v4-core репозиторий написан под Foundry, тесты — тоже. forge test --fork-url <mainnet> позволяет тестировать хук против реального состояния PoolManager.
v4-template от Uniswap — стартовая точка. Содержит правильный setup HookMiner для CREATE2 деплоя, базовый BaseHook с абстракциями, примеры тестов.
Slither с кастомными детекторами для v4 — проверяем корректность флагов, отсутствие storage collision с PoolManager slots.
Частые ошибки при разработке хуков
| Ошибка | Последствие | Решение |
|---|---|---|
| Неправильные биты в адресе | Пул не инициализируется | CREATE2 + HookMiner до деплоя |
Внешний вызов в beforeSwap без reentrancy guard |
Возможен reentrancy через хук | nonReentrant + transient storage lock |
| Unbounded loop в order book | DoS через gas limit | Ограничение ордеров на тик + keeper |
Использование SSTORE в горячем пути |
+20k gas на каждый свап | Transient storage (EIP-1153) |
Мутация PoolKey в хуке |
Невозможно — PoolKey immutable | Проектировать логику без изменения key |
Процесс разработки
Спецификация (2-3 дня). Формализуем поведение хука в каждой точке жизненного цикла. Какие инварианты должны соблюдаться? «Сумма fee всегда ≥ base fee», «limit order никогда не исполняется по цене хуже заявленной».
Разработка (5-7 дней). Foundry + v4-template. CREATE2 деплой скрипт с HookMiner. Property-based тесты через Echidna на ключевые инварианты.
Fork-тестирование (2-3 дня). Тесты против реального mainnet состояния: инициализация пула, серия свапов, граничные случаи (empty pool, single-sided liquidity, large price impact).
Аудит и газовый профиль. Slither + ручной review. Gas snapshot через forge snapshot — сравниваем gas cost свапа с хуком и без. Допустимый overhead для большинства кейсов: <10k gas на свап.
Ориентиры по срокам
Простой хук (dynamic fee или whitelist) — 1 неделя включая тесты. Хук средней сложности (limit orders, MEV capture) — 2-3 недели. Комплексная система с несколькими взаимодействующими хуками — от 4 недель.
Стоимость рассчитывается индивидуально после обсуждения требуемой механики.