Разработка кастомных пулов на Uniswap v4 с хуками

Мы разрабатываем кастомные пулы на Uniswap v4 с уникальными механиками ценообразования и защиты. Ключевое изменение архитектуры — хуки, позволяющие выполнять произвольный код до и после любой операции с пулом: инициализации, свапа, добавления/удаления ликвидности, донации. Это открывает пространство, которого не было в v2 и v3: динамические комиссии, on-chain order books, автоматический ребалансинг, MEV-защита прямо в пуле. Цена гибкости — сложность. Хук-контракт работает в контексте PoolManager через unlock callback с BalanceDelta системой учёта. Ошибка в хуке может заблокировать весь пул или слить ликвидность. Наш опыт 10+ лет в DeFi и 50+ блокчейн-проектов гарантирует безопасность и эффективность.

Разработка кастомных пулов на Uniswap v4: с чего начать

Архитектура Uniswap v4: что изменилось принципиально

В v2/v3 каждый пул — отдельный контракт. В v4 все пулы живут внутри одного PoolManager. Это сокращает газ на создание пула с ~500k до ~150k gas, и делает мультихоп свапы значительно дешевле (нет transfer между контрактами). Расчёт токенов ведётся через BalanceDelta — не реальные переводы, а дельты, которые накапливаются и рассчитываются в конце unlock callback. Пока PoolManager залочен (в рамках одного unlock), токены физически не переходят. Это открывает flash accounting: сделать свап, использовать полученные токены для чего угодно, вернуть долг — всё в одной транзакции без flash loan. Экономия газа достигает 40% по сравнению с v3.

Система хуков: адрес как битовая маска

Хук-контракт регистрируется при создании пула через PoolKey. Адрес хука кодирует разрешённые callback через leading bits: определённые биты адреса должны быть установлены для активации соответствующих хуков. beforeSwap — бит 7, afterSwap — бит 6, beforeAddLiquidity — бит 5, и так далее. Это означает, что адрес хук-контракта нельзя выбрать произвольно — нужно майнить ванити-адрес с нужными битами через CREATE2. Инструменты: v4-template от Uniswap, скрипты для mining адреса через Foundry. Всего 14 возможных хуков:

Как работают хуки Uniswap v4?

Динамические комиссии через beforeSwap

В v3 комиссия фиксирована (0.05%, 0.3%, 1%). В v4 хук может возвращать lpFeeOverride прямо в beforeSwap, меняя комиссию для каждого свапа динамически. Это позволяет строить:

• Волатильность-зависимые комиссии: Chainlink price feed + sliding window volatility → при высокой волатильности комиссия 1%, при низкой 0.05%. LP получают справедливое вознаграждение за риск impermanent loss.
• TWAP-based комиссии: если текущая цена отклонилась от TWAP более чем на X%, увеличить комиссию — защита от oracle-driven арбитража.

Limit orders через tick-based хуки

С afterSwap хук знает, что свап произошёл и цена изменилась. Если текущий tick пересёк заранее заданный уровень — можно исполнить limit order: выкупить/продать ликвидность из маппинга заявок. Это полноценный on-chain limit order book без centralized sequencer. Сложность: газ на итерацию по заявкам. Решение — lazy execution: заявки исполняются при следующем обращении к тику.

TWAMM (Time-Weighted Average Market Maker)

Крупные ордера разбиваются на маленькие виртуальные ордера, исполняемые непрерывно по времени. Хук накапливает токены от TWAMM-ордеров, постепенно выполняет их через пул, не создавая слиппаж. Это решает проблему whale orders — $10M свап за один блок двигает цену и создаёт sandwich возможности. TWAMM-хук размазывает его на 1000 блоков. Математика: виртуальные ордера вычисляются через формулу экспоненциального распределения.

Типичные ошибки при разработке хуков

• Reentrancy через PoolManager. PoolManager имеет собственный lock, но хук может вызывать внешние контракты, которые снова входят в пул. NoSuchPool, AlreadyUnlocked — частые ошибки. Правило: в хуках не делать внешних вызовов, кроме read-only запросов.
• Некорректный BalanceDelta. Хук возвращает дельту токенов. Если она неправильно рассчитана — PoolManager ревертит с DeltaNotSettled. Распространённый кейс: afterSwapReturnDelta пытается забрать больше, чем есть в дельте после свапа.
• Mining адреса для production. CREATE2 mining занимает от минут до часов в зависимости от количества нужных битов. Для 14 хуков — ~16 384 попыток в среднем.

Почему кастомные пулы на v4 выгоднее v3?

Поскольку весь код выполняется в рамках одного PoolManager, снижается накладные расходы на межконтрактные вызовы. Динамические комиссии привлекают LP в периоды высокой волатильности, а защита от MEV уменьшает потери от сэндвич-атак. В результате пулы становятся эффективнее и безопаснее. Экономия газа на создание пула — до 350k gas, на мультихоп свапах — до 40%.

Как мы разрабатываем кастомный пул: 5 шагов

Анализ и проектирование (2–3 дня). Определяем механику пула, набор хуков, BalanceDelta логику. Формальная спецификация инвариантов. Разработка хук-контракта (3–5 дней). Имплементация callback, mining адреса, вспомогательные контракты. Тестирование (3–5 дней). Unit-тесты, интеграционные тесты через PoolSwapTest, fuzz-тесты, fork-тесты. Аудит (2–3 дня). Slither, ручной review с фокусом на reentrancy и BalanceDelta. Деплой и верификация (1 день). Через Foundry forge script с верификацией на Etherscan.

Итого: 1–2 недели для хука с одной механикой. Сложные системы — 4–6 недель.

Что входит в работу

• Анализ требований и проектирование механики
• Разработка смарт-контрактов (хуки, вспомогательные контракты)
• Тестирование (unit, integration, fuzz, fork)
• Аудит безопасности (Slither, ручной review)
• Деплой с верификацией
• Документация и рекомендации по эксплуатации
• Поддержка на этапе запуска

Свяжитесь с нами, чтобы обсудить ваш проект. Мы оценим сложность и предложим оптимальное решение под ключ. Получите консультацию по вашему проекту — оставьте заявку.