Розробка Uniswap v4 хуків (hooks)
Ми спеціалізуємося на розробці хуків для Uniswap v4, включаючи динамічні комісії, whitelist пул, LVR mitigation, аудит смарт-контрактів, використовуючи Foundry та Solidity в DeFi DEX з PoolManager. Uniswap v3 обмежує кастомізацію пулів: для динамічних комісій доводилося форкати пул-контракт. v4 перевертає архітектуру — замість тисяч окремих пул-контрактів один singleton PoolManager і 14 callback-функцій, що реалізуються через хуки. Але кожен хук вимагає тонкого розуміння flash accounting та адресної конфігурації. Ми спеціалізуємося на таких задачах: розробляємо production-ready хуки з повним покриттям тестами та audit-prep документацією.
Ми розробили хуки для 30+ DeFi проєктів, включаючи динамічні комісії для великих DEX. Наш досвід — 10+ років у блокчейні, сертифіковані аудитори по Solidity. Маємо 5+ років досвіду в DeFi, реалізували 30+ проєктів з хуками. Гарантуємо якість коду та безпеку.
Чому адреса хука — це його конфігурація?
У v4 адреса хука — це його конфігурація. Останні 14 біт адреси кодують, які callback-функції реалізує хук: beforeSwap, afterSwap, beforeAddLiquidity, afterAddLiquidity та інші — всього 14 прапорців. PoolManager при реєстрації пула читає адресу хука і знає, які callback викликати, без додаткових on-chain запитів.
Наслідок: не можна просто задеплоїти контракт і отримати потрібну адресу. Потрібен mining — перебір salt у CREATE2, доки адреса не міститиме правильні біти. Foundry дозволяє це автоматизувати:
bytes32 salt = HookMiner.find(deployer, flags, creationCode, constructorArgs); При неправильних прапорцях PoolManager.initialize робить revert з HookAddressNotValid. Це перше, на чому спотикаються при переході з v3.
BeforeSwap і AfterSwap: асиметрія контролю
beforeSwap може повернути (bytes4 selector, BeforeSwapDelta delta, uint24 lpFeeOverride). Через delta хук може змінити кількість токенів, що беруть участь у свапі — по суті, перехопити частину потоку. Через lpFeeOverride — виставити динамічну комісію в конкретному хопі замість статичної, заданої при ініціалізації пула.
afterSwap отримує BalanceDelta — підсумок свапу — і може додати власну логіку поверх. Типовий кейс: rebate хук, який повертає частину fee активним LP у вигляді токенів.
Важливий нюанс: хуки працюють у контексті транзакції PoolManager. Всі операції з токенами йдуть через flash accounting — реальні ERC-20 трансфери відбуваються лише в кінці через settle/take. Якщо хук намагається зробити прямий transfer всередині callback — це зламає flash accounting і викличе revert або, гірше, некоректний стан балансу.
Reentrancy у v4: нові правила
PoolManager захищений Lock модифікатором — лише один lock-виклик активний одночасно. Хук, що намагається викликати PoolManager.swap всередині beforeSwap, отримає revert. Це означає, що архітектури, де хук повинен ініціювати вторинний свап (наприклад, автоматичний rebalancing), вимагають відкладеного виконання — через чергу у зовнішньому контракті або через afterSwap з наступним окремим викликом.
Як хук може реалізувати динамічні комісії?
Кейс з нашої практики. Ми реалізували хук, який читає TWAP з власного акумулятора (оновлюється в afterSwap), обчислює σ за останні N блоків, мапить σ на fee tier: низька волатильність → 0.01%, висока → 1%. lpFeeOverride повертається в beforeSwap. LP автоматично отримують захист при різких рухах ринку без ручного втручання.
Інші типові кейси:
- Whitelist пул: перевіряє merkleProof або ERC-721 баланс свіпера в beforeSwap/beforeAddLiquidity.
- LVR mitigation через аукціон: before-swap хук реалізує commit-reveal схему, де MEV-боти торгуються за право першого свапу. Виручка йде LP.
Стек та інструменти
Розробка — Foundry з v4-template від Uniswap. Тести — fork на Ethereum Sepolia (v4 вже задеплоєний на тестнеті). HookTest базовий контракт надає deployFreshManagerAndRouters — не потрібно налаштовувати mock PoolManager вручну.
Для mining адреси хука — HookMiner з v4-periphery. У CI це виглядає як крок перед тестами: майнимо salt, передаємо в deployment script.
Верифікація коректності прапорців — окремий тест:
assertEq(uint160(address(hook)) & HookFlags.ALL_FLAGS, expectedFlags); Провалений тест одразу показує, що адресу змайнено неправильно.
Аудит-специфіка хуків
Стандартні Slither детектори не знають про v4 callback-контекст. Пишемо кастомні детектори під конкретні патерни:
- прямий ERC-20 transfer всередині callback (порушення flash accounting)
- читання slot0 напряму замість через PoolManager (застарілий патерн з v3)
- відсутність перевірки msg.sender == address(poolManager) у callback-функціях
Ми проводимо професійний аудит смарт-контрактів для хуків, використовуючи кастомні детектори Slither.
Останній пункт критичний: якщо хук не перевіряє, хто викликає beforeSwap, будь-хто може викликати його напряму з довільними параметрами. Залежно від логіки це може призвести до маніпуляції станом хука без реального свапу.
Порівняння Uniswap v3 та v4 з хуками
| Параметр | Uniswap v3 | Uniswap v4 з хуками |
|---|---|---|
| Архітектура пула | Окремий контракт на кожен пул | Singleton PoolManager + хуки |
| Кастомізація комісії | Фіксована при ініціалізації | Динамічна через lpFeeOverride |
| Газ на створення пула | ~500k gas | ~50k gas (в 10 разів менше) |
| Можливість whitelist | Ні (тільки форк) | Вбудована через beforeSwap |
| Фреймворк для тестів | Hardhat/Foundry | Foundry + HookTest |
У порівнянні з v3, v4 з хуками зменшує газ на створення пула в 10 разів.
Що входить в роботу
| Етап | Результат | Термін |
|---|---|---|
| Аналітика | Технічне завдання, схема взаємодії | 2-3 дні |
| Проєктування | Storage layout, інтерфейс owner-функцій | 2-3 дні |
| Розробка | Код усіх callback, тести на Sepolia, fuzz | 1-2 тижні |
| Аудит | Кастомні детектори Slither, ручний review | 1 тиждень |
| Деплой | HookMiner CI, deployment script, моніторинг | 2 дні |
| Навчання команди | Документація, архітектурні рекомендації | 1 день |
Процес роботи
- Аналітика (2-3 дні). Формалізуємо логіку хука: які callback потрібні, чи є власний storage, чи потрібен доступ до oracle. Перевіряємо сумісність з існуючою архітектурою пула.
- Проєктування (2-3 дні). Схема взаємодії хука з PoolManager, визначення storage layout (мінімізуємо SLOAD у гарячих шляхах), інтерфейс для конфігурування хука owner-ом.
- Розробка (1-2 тижні). Реалізація callback-функцій, тести на fork Sepolia, fuzz-тести на граничні значення вхідних параметрів.
- Аудит. Кастомні Slither детектори + ручний review усіх шляхів, де хук змінює BeforeSwapDelta. Документація інваріантів для зовнішнього аудитора.
- Деплой. HookMiner у CI, deployment script через Foundry з верифікацією прапорців. Моніторинг через подієвий лог PoolManager перші 72 години після деплою.
Орієнтири за термінами та вартістю
Простий хук (single callback, лише читання) — 4-6 днів. Хук з динамічними комісіями та власним оракулом — 1-2 тижні. Комплексний хук з аукціонною механікою або власною системою обліку LP-позицій — 3-4 тижні. Вартість розробки базового хука — від 5000 USDT, з динамічними комісіями — від 8000 USDT.
Ознайомтеся з офіційною документацією Uniswap v4 для поглибленого розуміння специфікації.
Отримайте консультацію щодо вашого проєкту
Замовте розробку хука — оцінимо задачу за 24 години. Зв'яжіться з нами для обговорення архітектури та термінів.