DeFi. Uniswap v.4. Хуки (Hooks). Часть II. Полный гид по v.4. Перевод 

Первая часть

Первая часть: https://teletype.in/@menaskop/uniswap-hooks-01.

Перевод

Это вольный, но довольно подробный перевод статьи, размещённой здесь: research.2077.xyz/a-complete-guide-to-uniswap-v4-1#uniswap-as-a-sustainable-platform.

Введение

(С помощью данной статьи вы) узнаете об инновациях Uniswap V4:

• архитектуре Singleton,
• мгновенном учёте (Flash Accounting)
• и хуках (Hooks).

(А также) разберётесь, как эти функции улучшают эффективность, масштабируемость и пользовательский опыт.

Предыстория

История Uniswap: V1 и V2

Прежде чем погрузиться в особенности V4, давайте посмотрим, как развивался протокол Uniswap. Проект (эволюционирует) уже более семи лет — от версии V1 до V4.

Uniswap V1, созданный в 2017 году, был крайне простым AMM-протоколом (автоматическим маркет-мейкером). Его простота видна даже по объёму кода — примерно 500 строк. Благодаря такой лаконичности V1 взимал значительно меньшие комиссии за газ по сравнению с другими AMM-протоколами того времени.

Однако V1 поддерживал только обмен между ETH и токенами стандарта ERC-20. Чтобы обменять один токен ERC-20 на другой, необходимо было сначала обменять его на ETH, а затем уже на нужный токен — что создавало дополнительные издержки.

Uniswap V2, запущенный в мае 2020 года, решил эту проблему благодаря более продвинутой архитектуре. Он позволил создавать пулы между двумя токенами ERC-20, обеспечивая прямой обмен без промежуточного шага через ETH.

Также во второй версии появились новые функции: оракулы, с помощью которых можно было запрашивать цену прямо из пула, и флэш-займы — возможность безопасно занимать средства на короткое время, например, для арбитражных сделок.

Тем не менее, у V2 были и недостатки. Один из основных — так называемая «ленивая ликвидность» (lazy liquidity). Рассмотрим эту проблему на примере.

Допустим, Алиса предоставляет ликвидность на $1,000 в пул USDC-ETH на Uniswap V2. Эта ликвидность распределяется равномерно по всему диапазону цен — от нуля до бесконечности — вне зависимости от текущей цены ETH. Пусть Боб проводит обмен в этом пуле, в результате чего цена ETH поднимается с $3,000 до $3,100.

В таком случае в сделке участвует лишь небольшая часть ликвидности Алисы, а большая часть её капитала остаётся неиспользованной. Это и называется «ленивой ликвидностью».

Проблема становится особенно очевидной в пулах со стейблкойнами.

Такие активы, как правило, привязаны к доллару, и их цена редко выходит за пределы этой отметки. Поэтому основная торговля происходит около значения $1. Но поскольку в V2 ликвидность распределяется равномерно по всему ценовому диапазону, большая часть средств не участвует в торгах, снижая эффективность DEX'ов, особенно (как раз) в парах со стейблкойнами.

Uniswap V3

Чтобы решить эти проблемы, в Uniswap V3 была внедрена концепция концентрированной ликвидности. Этот механизм позволяет провайдерам ликвидности (LP) задавать конкретные ценовые диапазоны, в которых их ликвидность будет активна.

Как показано на изображении выше, в модели концентрированной ликвидности провайдеры ликвидности (LP) могут самостоятельно выбирать ценовой диапазон, в котором они хотят размещать свою ликвидность.

При этом даже при одинаковом объёме средств плотность ликвидности возрастает, если она сосредоточена ближе к текущей рыночной цене.

Во время свопов комиссии распределяются пропорционально плотности предоставленной ликвидности, что стимулирует LP задавать более узкие диапазоны, максимально приближённые к текущей цене. Это позволяет зарабатывать больше комиссионных.

(Прим. Menaskop: о реальных доходах LP - см. здесь).

Такой подход повышает капитальную эффективность пула и снижает проскальзывание при обменах.

Хорошим примером работы этого механизма является пул USDC-DAI в Uniswap V3 на основной сети Ethereum. Как видно на изображении ниже, большая часть ликвидности в этом пуле сосредоточена в узком диапазоне от $0.9998 до $1.0002.

Такая модель поведения LP свидетельствует о том, что провайдеры ликвидности считают маловероятным отклонение курсов DAI и USDC от $1. Поэтому они концентрируют ликвидность именно вблизи этой отметки. Это позволяет LP зарабатывать больше на комиссиях, а трейдерам — совершать сделки с минимальным проскальзыванием.

Однако с появлением Uniswap V3 возникли и две серьёзные проблемы:

1. Ограниченная гибкость из-за жёсткой архитектуры. Uniswap V3 реализован по принципу «единое решение для всех»: все пулы работают на одной и той же структуре кода. Это значительно ограничивает гибкость — невозможно адаптировать функциональность под конкретные нужды пользователей. Например, встроенный оракул в Uniswap V3 был полезен для профессиональных трейдеров и провайдеров данных, но увеличивал издержки для обычных пользователей, совершающих простые свопы. Кроме того, из-за жёстко заданной логики было крайне трудно реализовать кастомные функции — такие как лимитные ордера — без внешних модификаций. Несмотря на хорошую реализацию токен-обменов, Uniswap V3 не смог стать полноценной платформой ликвидности, стимулирующей разработчиков к созданию новых решений.
2. Неэффективность по gas-расходам . Хотя комиссии за газ в Uniswap V3 были ниже, чем у большинства других DEX, одна своп-транзакция всё равно требовала более 200,000 gas. А если сделка проходила через несколько пулов, затраты на газ резко возрастали. Устранение этих неэффективностей стало бы значительным шагом в сторону улучшения пользовательского опыта.

Что нового в Uniswap V4?

Uniswap V4 — протокол, созданный с целью сделать свопы более эффективными и масштабируемыми, чтобы предоставить больше возможностей разработчикам и улучшить использование ликвидности. Он решает ключевые проблемы V3 и одновременно расширяет функциональность протокола.

Какие механизмы внедрены в Uniswap V4, и какие новые сценарии использования они открывают?

Для начала рассмотрим ключевые нововведения в V4. Базовая структура пулов осталась схожей с V3 и продолжает использовать модель концентрированной ликвидности. Однако V4 представляет три принципиально новых элемента, значительно улучшающих взаимодействие пользователей с протоколом:

1. Архитектура Singleton
2. Мгновенное учётное сведение (Flash Accounting)
3. Hooks (хуки)

Давайте подробно разберём каждую из этих функций и узнаем, какие преимущества они дают.

Архитектура Singleton

До Uniswap V4 протокол состоял из двух ключевых компонентов: Factory и Pool.

Каждый раз при создании нового пула контракт Factory развёртывал новый контракт Pool. В Uniswap V4 эта модель изменилась — теперь все пулы управляются единым контрактом под названием PoolManager.

Такой подход позволяет объединить управление всеми пулами в одном контракте, что значительно снижает издержки на маршрутизацию между ними. Это делает свопы между несколькими пулами дешевле и эффективнее.

Рассмотрим пример маршрутизации, когда пользователь обменивает ETH на USDC, а затем — USDC на OP. В Uniswap V3 этот процесс включал отправку ETH в пул ETH-USDC, получение USDC, а затем перевод токенов в пул USDC-OP для завершения обмена на OP.

В Uniswap V4 всё стало проще: маршрутизация выполняется через обновление внутренних балансов внутри одного контракта. Вместо того чтобы отдельно изменять балансы каждого пула, обновления происходят только в начале и в конце транзакции, что значительно упрощает процесс и снижает его стоимость.

Кроме того, создание новых пулов стало намного дешевле. В ранних версиях для этого требовалось развёртывание отдельного смарт-контракта, что было затратным из-за высоких комиссий на развёртывание в сети Ethereum.

В V4 пулы можно создавать простым вызовом функции в контракте PoolManager, без необходимости развёртывания нового контракта. Это снижает стоимость создания пула более чем на 99% по сравнению с предыдущими версиями.

Flash Accounting (мгновенное сведение баланса) по EIP-1153

Второе ключевое нововведение в Uniswap V4 — Flash Accounting — новый подход к оптимизации gas-расходов, основанный на эффективной модели расчёта задолженностей при обменах и управлении ликвидностью.

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

Рассмотрим это на примере. Когда пользователь инициирует своп в Uniswap V4, в процессе участвуют три ключевых компонента:

1. Пользователь — инициирует обмен через контракт Router.
2. Router — получает токены пользователя и передаёт запрос в основной контракт Uniswap.
3. PoolManager — выполняет логику обмена и возвращает запрашиваемые токены пользователю.

Взаимодействие между этими компонентами можно представить следующим образом:

Когда пользователь взаимодействует с интерфейсом DEX и инициирует своп, контракт Router вызывает функцию unlock в контракте PoolManager. Эта функция открывает возможность для модификации балансов внутри контракта, разрешая вносить изменения.

Функция unlock выполняет две основные задачи:

1. Защита от повторного входа (reentrancy) — гарантирует, что функция не может быть выполнена дважды в рамках одной и той же транзакции.
2. Вызов callback-функции Router’а, которая и обрабатывает основную логику свопа.

Основная обработка обмена (включая обновление балансов и финальный расчёт) происходит внутри callback-функции Router’а под названием unlockCallback. Именно она вызывает несколько функций внутри PoolManager, чтобы выполнить требуемое действие.

В случае свопа unlockCallback выполняет два ключевых шага:

1. Модифицирует балансы и рассчитывает текущие обязательства;
2. Погашает долги и завершает обмен.

Весь процесс можно визуализировать следующим образом:

Важный момент, который следует отметить: в течение всей транзакции определённые значения должны оставаться неизменными до и после её выполнения. Самым критичным из них является delta — показатель текущей задолженности между пользователем и пулом. Он всегда должен возвращаться к нулю в начале и в конце транзакции.

Ethereum предоставляет специальный тип хранилища для хранения таких временных данных — транзиентное хранилище (transient storage). Этот механизм был введён в рамках обновления Dencun в 2024 году через предложение EIP-1153.

Транзиентное хранилище работает похоже на стандартное хранилище Ethereum, но его данные действительны только в пределах одной транзакции. Как только транзакция завершается, все значения в таком хранилище автоматически сбрасываются, как показано на схеме ниже:

Поскольку транзиентное хранилище является временным и не увеличивает постоянную нагрузку на хранилище Ethereum, операции с ним существенно дешевле, чем с обычным хранилищем.

Например, запись в пустой слот стандартного хранилища обходится в 20,000 gas, тогда как запись в транзиентное хранилище — всего в 100 gas.

Uniswap V4 активно использует это преимущество, сохраняя данные о долгах (delta) именно в транзиентном хранилище, что позволяет радикально сократить затраты на gas. Транзакции, которые раньше требовали более 100,000 gas, теперь можно завершить всего за несколько сотен gas. Кроме того, механизмы защиты от повторного входа (reentrancy guards) в Uniswap V4 также реализованы через транзиентное хранилище, что дополнительно снижает издержки.

Итог: Uniswap V4 внедряет уникальную модель «погашения задолженности», которая оптимизирует использование газа за счёт транзиентного хранилища. Это делает обмены значительно дешевле, чем в Uniswap V3.

Эта эффективность подтверждается и в реальных кейсах.

Ниже приведён пример: Хайден Адамс (создатель Uniswap) попытался обменять 0.3 ETH на USDT. Несмотря на то что пул ETH-USDT в Uniswap V4 имел ликвидность всего около $400,000, Router выбрал именно этот путь как оптимальный — благодаря высокой газ-эффективности V4.

Router выбирает пути для свопов, учитывая такие параметры, как проскальзывание, комиссии за газ и другие факторы. В приведённом примере низкие gas-издержки Uniswap V4 сделали его предпочтительным маршрутом, что привело к росту объёма обменов в пулах V4 и, как следствие, увеличению дохода от комиссий для провайдеров ликвидности.

Hooks — главный прорыв Uniswap V4

Среди всех новых возможностей хуки (Hooks) — наиболее значимое нововведение в Uniswap V4.

В Uniswap V3 и других DEX пользователи могли взаимодействовать только с заранее определённой логикой, встроенной в протокол. Uniswap V4 же позволяет создателям пулов добавлять собственную бизнес-логику через хуки, тем самым создавая пулы с уникальными функциями под конкретные задачи.

Согласно официальному блогу Uniswap V4, хуки могут использоваться для реализации таких возможностей, как:

• TWAMM (автоматический маркетмейкер с учётом времени);
• Динамические комиссии в зависимости от волатильности;
• Лимитные ончейн-ордера;
• Авто-депозит ликвидности;
• Кастомные оракулы;
• Автоматическое реинвестирование комиссий LP;
• Перераспределение прибыли от MEV в пользу провайдеров ликвидности.

Но как именно работают хуки, что они позволяют реализовать, и что уже строят разработчики на их основе? Давайте разберёмся.

Hooks в Uniswap V4: как это устроено?

Общий принцип хуков

В программировании под "хуком" обычно понимается вмешательство в вызов функций, событий или сообщений для изменения или расширения логики приложения. Компоненты, которые перехватывают такие вызовы и выполняют действия — и есть хуки. Этот паттерн часто используется в отладке и модификации поведения программ.

Uniswap V4 применяет эту архитектуру, чтобы разработчики могли расширять функциональность DEX с помощью специальных внешних контрактов-хуков.

Пять типов хуков в Uniswap V4

Uniswap V4 позволяет реализовать хуки, которые срабатывают до или после определённых действий в протоколе. Вот основные типы:

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

Например, beforeSwap вызывается до того, как PoolManager выполнит обмен, что позволяет разработчику внедрить кастомную проверку или изменить поведение транзакции.

Один хук может реализовывать как одну, так и несколько функций одновременно — таким образом, можно обрабатывать практически каждое действие внутри пула.

Структура и назначение хуков

В Uniswap V4 хуки — отдельные смарт-контракты, не связанные напрямую с пулами.

При создании пула его создатель указывает адрес нужного хука, и он становится частью логики этого пула. Важно: после установки хук нельзя изменить. Однако один и тот же хук можно использовать сразу в нескольких пулах.

Также стоит учитывать: даже если два пула имеют одну и ту же пару токенов (например, USDC-ETH) и одинаковый уровень комиссии, они считаются разными, если используют разные хуки.

Если в V3 одна пара могла существовать максимум в 6 пулах (по количеству уровней комиссии), то в V4 можно создавать бесконечное количество кастомных пулов на одних и тех же токенах, но с разной логикой — например:

• пул с интеграцией оракула;
• пул с поддержкой лимитных ордеров;
• пул с динамическими комиссиями.

Вывод: Uniswap V4 делает возможным создание кастомизированных пулов с индивидуальной логикой за счёт архитектуры хуков — это то, что принципиально отличает V4 от предыдущих версий.

На этом этапе у вас могут возникнуть резонные вопросы:

1. Можно ли через хуки реализовать любую бизнес-логику?
2. Насколько сложной и продвинутой она может быть?

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

Как работают хуки под капотом?

Основная логика хуков

Чтобы понять, как хуки работают на уровне внутренней реализации, важно разобраться в их структуре. В Uniswap V4 для каждой hook-функции определены конкретные форматы входных и выходных данных. Эта часть описывает, какие данные хуки получают от контрактов Uniswap V4 и что они могут с ними делать.

Рассмотрим, например, beforeSwap и afterSwap.

Функция beforeSwap вызывается до того, как PoolManager выполнит логику свопа. Она получает от PoolManager следующие 5 параметров:

Таким образом, каждый раз при совершении обмена хук получает (следующие данные):

• Кто инициировал своп?
• Сколько токенов обменивается?
• В каком направлении идёт обмен?
• Какой лимит проскальзывания установлен?
• Дополнительные входные данные (если есть).

После выполнения своей логики, beforeSwap возвращает следующие значения обратно в PoolManager:

Из этого видно, что хуки — не просто «слушатели» событий, а полноценные участники процесса, способные активно влиять на выполнение свопов.

Два ключевых механизма влияния хука:

№01. beforeSwapDelta: активное участие в обмене. Значение beforeSwapDelta связано с моделью погашения долгов в Uniswap V4. При каждом обмене в V4 возникает временное "задолженность" между Router и пулом, которая закрывается в конце транзакции. Хуки тоже могут вступать в подобные отношения с пулами, например:

• Взимать комиссию или предоставлять скидку в зависимости от условий;
• Изменять маршрут выполнения сделки, основываясь на кастомных правилах;
• Адаптировать проскальзывание под рыночную волатильность.

Важно: хуки не обязаны возвращать beforeSwapDelta. Некоторые могут просто выполнять вспомогательные действия, не вмешиваясь в механику обмена.

№02. lpFeeOverride: динамическая настройка комиссии. lpFeeOverride позволяет хуку изменить комиссию LP в рамках конкретного свопа. В Uniswap V4 комиссии могут быть динамическими, но меняться они могут только через хуки.

Существует два способа реализации динамических комиссий:

Постоянное изменение комиссии. Хук может вызвать updateDynamicLPFee, чтобы изменить базовую комиссию пула. Например, при повышенной волатильности комиссии увеличиваются (для компенсации рисков LP), а при низкой — снижаются для привлечения трейдеров.

Временное изменение комиссии. Через lpFeeOverride хук может применить специальную комиссию для конкретной транзакции. Это открывает множество сценариев:

• Скидки для держателей определённых NFT;
• Повышенные комиссии для арбитражников;
• Индивидуальные условия для разных стратегий трейдинга.

(Так что в итоге) может делать beforeSwap? beforeSwap позволяет хуку выполнять три основные функции:

Функция №01. Контроль доступа. Хуки могут проверять sender — то есть, кто инициировал своп. Это позволяет реализовать кастомные механизмы доступа. Например:

• Только пользователи с определённым NFT могут торговать в пуле;
• Пулы с белым списком адресов и т.д.

Однако есть важное уточнение: пользователи обычно не взаимодействуют с PoolManager напрямую, а через Router. Поэтому в хуке sender — это адрес Router'а, а не пользователя. Следовательно, логика проверки доступа обычно реализуется на уровне Router’а, а не внутри хука. Хук указывает, какой Router может проводить свопы, а сам Router проверяет права доступа пользователя.

Функция №02. Вмешательство в логику обмена. Хуки могут вмешиваться в саму механику выполнения сделки. Получая все детали обмена, они могут:

• Изменять параметры исполнения;
• Вводить свои алгоритмы расчёта;
• Реализовать уникальные механики обмена.

По умолчанию Uniswap V4 использует концентрированную ликвидность и формулу x * y = k с разбивкой на ценовые «тики». Но хуки могут переопределить этот механизм.

Например: хук может реализовать алгоритм StableSwap, аналогичный Curve, чтобы уменьшить проскальзывание при обмене стейблкойнов и повысить эффективность (капитала).

Функци №03. Динамическое управление комиссиями. Хуки позволяют гибко регулировать LP-комиссии, повышая доходность провайдеров ликвидности.

Один из популярных сценариев — изменение комиссии в зависимости от волатильности. В периоды высокой волатильности LP несут повышенные риски (IL и LVR), и комиссии могут быть увеличены для компенсации этих потерь. Когда рынок стабилен — комиссии можно снизить, чтобы привлечь больше сделок.

Важно: хуки не могут менять комиссии в любом пуле — только в тех, где включена поддержка динамической комиссии. Это означает, что пользователи в пулах с фиксированной комиссией могут торговать без риска неожиданного изменения условий.

Как хуки устанавливаются в пулы ликвидности?

Как именно хуки прикрепляются к пулам? Можно ли подключить любой хук к любому пулу? Нет, нельзя.

Uniswap V4 не позволяет свободно подключать хуки к существующим пулам. При создании нового пула контракт PoolManager выполняет проверку, чтобы убедиться, что указанный хук соответствует определённым условиям.

Адрес хука — это код конфигурации!

Контракт хука "общается" с PoolManager путём кодирования функций, которые он реализует, в свой адрес. Ключевая часть этого кодирования — последние четыре шестнадцатеричных символа (16 бит) адреса хука. Именно они указывают, какие функции реализованы в этом хуке.

Пример. Предположим, у контракта адрес 0x4f....00C0. Четыре последние символа — 00C0 — важны. В бинарной форме 00C0 будет выглядеть так: 0000 0000 1100 0000.

Каждый бит (0 или 1) в этом представлении соответствует определённой hook-функции. Если бит равен 1, функция реализована. Если 0 — нет.

Таблица битов и соответствующих функций:

Пример: Адрес “...00C0” = 0000 0000 1100 0000 означает, что хук реализует только две функции:

• beforeSwap (бит 7);
• afterRemoveLiquidity (бит 8).

Зачем это нужно?

Если бы в Uniswap V4 не использовалось кодирование адресов, то PoolManager не знал бы, какие функции реализует хук. Ему пришлось бы вызывать все возможные функции наугад, проверяя, какие существуют — это увеличивало бы затраты газа.

Например: хук реализует только beforeSwap, но PoolManager всё равно пытался бы вызвать afterSwap, beforeAddLiquidity, afterDonate и т. д., что тратит ресурсы впустую.

Благодаря кодированию через адрес, PoolManager заранее знает, какие функции активны — и вызывает только их. Это повышает эффективность.

Последние 4 бита: хуки с delta. Последние 4 бита таблицы (позиции 0–3) указывают, влияет ли хук на результат операции.

Если хук, например, изменяет механику свопа и возвращает beforeSwapDelta, это должно быть указано в его адресе. Таким образом, PoolManager заранее знает, нужно ли учитывать модификацию результатов. Это исключает ненужные расчёты в случае, если хук не меняет логику обмена.

Как разработчику получить нужный адрес?

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

(В частности, существует) решение CREATE2. Оператор CREATE2 в Ethereum позволяет развернуть контракт по заранее рассчитанному адресу, задавая:

• sender — адрес, с которого развёртывается контракт;
• salt — произвольное значение, которое можно подбирать;
• init_code — байт-код контракта.

Формула адреса:

Изменяя salt, разработчики могут подбирать нужный адрес, чтобы он заканчивался, например, на 00C0.

(Но) подбор нужного salt вручную — трудоёмкий и утомительный процесс. Кроме того, при каждом обновлении логики хука, приходится заново искать подходящий адрес.

Поэтому Uniswap создал библиотеку HookMiner — это инструмент, который автоматически подбирает salt для получения нужных адресов хуков. Библиотека упрощает разработку и тестирование кастомных хуков, избавляя от рутинной ручной работы.

Кроме CLI-библиотеки HookMiner, был также создан веб-интерфейс — V4 Hook Address Miner, который ещё больше упрощает работу с хуками. С помощью этого инструмента разработчики могут:

• Выбрать, какие функции должен реализовывать хук;
• Автоматически сгенерировать salt, который даёт нужный адрес;
• Развернуть хук без ручного перебора адресов.

Благодаря таким инструментам разработчики могут без труда развертывать хуки с корректной структурой адреса, делая экосистему Uniswap V4 более доступной и удобной для создания кастомных решений.

Потенциальные риски и соображения безопасности

Мы уже рассмотрели, как работают хуки в Uniswap V4 и как они расширяют возможности протокола. Но возникает важный вопрос: “Есть ли у этих функций побочные эффекты и риски?”.

Безопасность каждого пула

Несмотря на то, что в Uniswap V4 хуки проходят определённую проверку при установке (по входам/выходам), ограничений на внутреннюю логику хука не существует. Это значит, что злонамеренные разработчики могут внедрить вредоносную логику, способную:

1. Воровать средства у трейдеров или LP;
2. Блокировать деятельность пула (например, через DoS-атаки);
3. Навсегда замораживать ликвидность в случае ошибки или уязвимости.

Пример атаки. Мошеннический хук может использовать динамическое изменение комиссий и повышать swap fee до 100%, если цена входит в определённый диапазон. В результате — все обмены будут отклоняться, и пул окажется фактически «заблокирован».

Также неправильный контроль доступа может привести к тому, что ликвидность пула будет навсегда заморожена.

В статье от Composable Security описан сценарий, когда функция beforeInitialize, если она не защищена, может быть вызвана любым адресом, что навсегда зафиксирует состояние пула и сделает его непригодным для работы.

Как обезопасить себя?

Трейдерам беспокоиться не о чем (если использовать UniswapX): если обмениваете токены через официальный интерфейс Uniswap, и своп проходит через UniswapX (сеть исполнения обменов на основе намерений), то вся ответственность за безопасность лежит на исполнителях (fillers).

То есть:

• Вы указываете, что хотите обменять;
• Ваше намерение исполняет "filler", который сам взаимодействует с пулами;
• Если в процессе участвует вредоносный хук — ответственность несёт filler, а не вы.

Итог: при использовании UniswapX в официальном UI, вы защищены от вредоносных хуков.

LP (поставщикам ликвидности) — нужно быть осторожными: если вы добавляете ликвидность в пул на Uniswap V4, интерфейс позволяет вам вручную указать адрес хука, с которым связан пул.

Следовательно:

• Вы несёте ответственность за выбор хука;
• Перед внесением ликвидности важно: 1) Проверить адрес хука; 2) Убедиться в его безопасности и надёжности; 3) Понимать, какую логику он реализует.

Если указанный хук окажется взломанным или вредоносным, предоставленная вами ликвидность может быть заморожена или украдена. Поэтому поставщики ликвидности (LP) должны проявлять особую осторожность при использовании этой функции и использовать только те хуки, которые прошли аудит и имеют проверенные гарантии безопасности.

Проблемы маршрутизации в Uniswap V4

Как работает маршрутизация в Uniswap V4 при выполнении свопа? Чтобы понять это, давайте кратко рассмотрим, как эволюционировала маршрутизация в предыдущих версиях Uniswap.

Маршрутизация в Uniswap V3

В Uniswap V3, когда пользователь инициировал обмен, его запрос отправлялся на сервер Smart Order Router (SOR) — централизованный компонент на бэкенде Uniswap:

• Этот модуль рассчитывал оптимальный маршрут свопа;
• Возвращал его пользователю;
• Пользователь подтверждал и отправлял расчётный маршрут в контракт Router.

Появление UniswapX (июль 2023)

В 2023 году Uniswap запустил UniswapX — децентрализованный протокол исполнения обменов, основанный на намерениях (intents), призванный:

• Упростить маршрутизацию;
• Повысить эффективность свопов;
• Улучшить кроссчейн-UX.

Теперь маршрутизация передаётся не централизованному сервису, а децентрализованной сети исполнителей (fillers).

Как работает UniswapX?

1. Пользователь подписывает сообщение Permit2, указывая: а) Какой токен хочет обменять? б) Сколько хочет получить? в) Какой минимум он готов принять?
2. Исполнители участвуют в "голландском аукционе", чтобы предложить наилучшие условия исполнения. Пример:
1. Алиса хочет обменять 1 ETH на 3,200 USDC, минимально согласна на 3,190 USDC;
2. Боб проводит своп на 3,199 USDC, оставляя себе 1 USDC;
3. Чарли предлагает 3,196 USDC — он выигрывает аукцион;
4. UniswapX выбирает наиболее выгодное исполнение для пользователя.
3. Победивший filler подаёт Permit2-подпись в контракт Reactor, который:
1. Выполняет обмен;
2. Проверяет соблюдение условий.

Что с маршрутизацией в V4? Теперь возникает вопрос: “Будет ли этот алгоритм работать так же гладко в Uniswap V4?”.

По сравнению с V3, маршрутизация в Uniswap V4 значительно усложнилась. Почему? В V3 необходимо было:

1. Найти лучшую цепочку пулов;
2. Оценить ликвидность, комиссии и проскальзывание.

В V4 — добавляется ещё один фактор: встроенная логика хуков, которая может быть произвольной и нестабильной.

В чём проблема?

• По адресу хука можно узнать, какие функции он реализует;
• Но что именно делает этот хук внутри — неизвестно, пока его не выполнить;
• Это добавляет неопределённость и потенциальные риски при маршрутизации.

Алгоритм должен учитывать не только:

• Направление обмена;
• Ликвидность и комиссии;
• Состояние пула.

Но и:

• Влияние кастомной логики хука;
• Возможные побочные эффекты;
• Динамические комиссии;
• Ограничения доступа и пр.

Это делает задачу маршрутизации в V4 гораздо более сложной и ресурсоёмкой, особенно в автоматическом исполнении (например, через fillers в UniswapX).

Из-за потенциальных рисков безопасности, связанных с хуками, маршрутизация в Uniswap V4 будет происходить только в том случае, если исполнители (fillers) полностью понимают и доверяют логике хука, используемого в пуле ликвидности.

Это означает, что участники сети UniswapX должны тщательно проверять, прошёл ли хук:

• аудит,
• получил ли подтверждение от сообщества,
• и/или имеет ли верификацию через ончейн-источники.

Что это означает на практике?

• Пулы с популярными и проверенными хуками, уже используемые сообществом и обладающие значительной ликвидностью,
• Чаще всего будут выбраны исполнителями и попадут в алгоритмы маршрутизации UniswapX.

Новые хуки и пулы всё же могут быть замечены, поскольку fillers постоянно ищут новые возможности для прибыли.

Как привлечь внимание к своему хуку? Если хук уже показал себя как надёжный и безопасный, стоит подумать над тем, как мотивировать исполнителей включить его в маршрутизацию:

• Ончейн-метки доверия;
• Открытые аудиты;
• Интеграция с мониторинговыми дашбордами;
• Экономические стимулы для fillers (например, ребейты).

Необходима прозрачная система мета-информации. С учётом этих вызовов становится ясно, что для экосистемы необходим прозрачный дашборд, агрегирующий информацию о хуках.

Такой инструмент уже разрабатывается — HookRank — аналог L2Beat, но для хуков Uniswap V4. HookRank поможет:

• Анализировать популярность и надёжность хуков;
• Проверять их использование в пулах с высокой ликвидностью;
• Быстро находить проверенные и безопасные хуки для маршрутизации.

На платформе HookRank пользователи могут просматривать:

• Название и адрес каждого хука;
• Общий TVL (Total Value Locked) — совокупную ликвидность, связанную с хуком;
• Уровень успешных транзакций в пулах, использующих данный хук.

Пока что, поскольку Uniswap V4 был запущен совсем недавно (на начало 2025 года), объём данных на HookRank остаётся относительно небольшим.

Однако по мере роста количества хуков и пулов V4, такие инструменты, как HookRank, станут незаменимыми для участников UniswapX, особенно исполнителей (fillers), занимающихся маршрутизацией.

Используя подобные дашборды, fillers смогут быстро оценивать:

• надёжность хука;
• его активность и ликвидность;
• риски, связанные с его логикой.

Это позволит оптимизировать выбор маршрутов при минимизации потенциальных угроз.

Экосистема хуков в Uniswap V4

На февраль 2025 года Uniswap V4 всё ещё находится на ранней стадии развития — протокол был запущен всего несколько недель назад. Тем не менее, уже ряд команд начали активно строить продукты на основе хуков в V4.

В следующем разделе мы рассмотрим:

• Наиболее заметные проекты, уже использующие хуки;
• И потенциальные направления для новых протоколов, которые можно построить с помощью этой новой архитектуры.

Обзор текущего состояния хуков

(Экосистема хуков Uniswap V4)

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

Давайте рассмотрим, как хуки Uniswap V4 могут быть интегрированы в каждую из этих сфер, и какие механизмы при этом используются.

Основные сценарии использования хуков

Минимизация MEV

Когда речь заходит о MEV (Maximal Extractable Value), чаще всего вспоминают ущерб для трейдеров, например, сэндвич-атаки. Однако влияние MEV на DEX-платформы вроде Uniswap также существенно сказывается и на поставщиках ликвидности (LP). Проще говоря, LP теряют часть прибыли из-за MEV.

Проблема LVR (Loss-Versus-Rebalancing). Эта проблема была исследована под названием Loss-Versus-Rebalancing (LVR). LVR возникает потому, что в DEX’ах, таких как Uniswap, время разделено на дискретные блоки. LP не могут динамически управлять своими позициями в реальном времени, в отличие от идеальной среды с постоянным ребалансом.

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

В следующих разделах рассмотрим, какие именно проекты и хуки решают проблему MEV и LVR, а также другие направления, такие как:

• Динамические комиссии;
• Интеграция с лендинг-протоколами;
• Автоматизация LP-доходов;
• Кастомные модели ордеров (лимитные/TWAMM);
• Ончейн-аналитика и оракулы.

(LVR и непостоянные потери LP в условиях волатильного рынка | Источник: Delphi Digital)

Рассмотрим пример: предположим, что цена ETH внезапно удваивается на централизованной бирже (CEX) до $2000, в то время как на децентрализованной бирже (DEX) она всё ещё остаётся на уровне $1000. Арбитражники сразу воспользуются этой возможностью: они покупают ETH на DEX по $1000 и продают на CEX по $2000, зарабатывая на разнице.

Но поставщики ликвидности (LP) на DEX не успевают отреагировать на ценовое изменение: они вынуждены продавать ETH по заниженной цене — в два раза ниже его рыночной стоимости.

Теперь предположим, что цена ETH снова резко падает до $1000. Арбитражники снова действуют: покупают ETH на CEX и продают на DEX — и опять зарабатывают, в то время как LP теряют.

Иными словами: Поставщики ликвидности на DEX вынуждены отдавать все возможности заработка на рыночной волатильности арбитражникам. В идеале LP должны иметь возможность быстро перебалансировать позиции, чтобы захватывать прибыль, но вместо этого они теряют её — из-за неспособности реагировать в реальном времени.

Это и есть суть LVR (Loss-Versus-Rebalancing) — потери LP по сравнению с идеальным сценарием, где они могли бы динамически управлять ликвидностью.

В следующих частях можно рассмотреть, как хуки в Uniswap V4 могут минимизировать LVR, автоматизируя ребаланс или компенсируя LP через новые модели комиссий:

(Токсичность ордерфлоу в Uniswap V3 | Источник: arxiv.org/pdf/2210.10601)

LVR (Loss-Versus-Rebalancing) была признана одной из ключевых причин снижения доходности LP в Uniswap V3. На графике выше LP Uniswap V3 моделируются как "трейдеры", а их PnL (прибыль и убытки) рассчитывается в зависимости от момента выхода из позиции. Практически на всех таймфреймах видно, что LP стабильно несут убытки.

Корневая проблема LVR заключается в том, что LP не могут оперативно реагировать на изменения цены. Самый прямой и эффективный способ решения этой проблемы —

перераспределение части прибыли от MEV в пользу LP через протокольные механизмы.

Arrakis Diamond Protocol — хук для минимизации LVR

Один из наиболее интересных и инновационных хуков, направленных на устранение LVR, — Arrakis Diamond Protocol, вдохновлённый архитектурой Diamond Protocol.

Основная идея хука: арбитражник должен внести залог (collateral) в хук до совершения арбитражной сделки в пуле. Эта модель:

• снижает прибыльность MEV-арбитража;
• поощряет back-running (следующие за свопом сделки);
• и тем самым минимизирует LVR.

Допущения в Proof-of-Concept реализации:

1. Арбитражник полностью знает входящие транзакции и их влияние на цену и ликвидность пула;
2. До того как будет произведён следующий блок, он всегда выполнит сделку, которая синхронизирует цену токена в пуле с внешним рынком.

Механика работы хука: в пулах с поддержкой Arrakis Hook арбитражники обязаны внести залог до начала сделки. Далее следуют два важных правила:

1. Первая транзакция в блоке — выравнивание цены: допустим, в Uniswap V4 цена ETH = $1200, а на внешних рынках (например, CEX) = $1100. Арбитражник обязан выполнить своп, чтобы цена в пуле снизилась до $1100. Эта цена становится зафиксированной (committed price). Если этого не происходит — все последующие свопы в блоке запрещаются.
2. Залог должен быть достаточным, чтобы вернуть цену к committed price. Размер залога рассчитывается динамически — в зависимости от общего объёма сделок в блоке. Поскольку арбитражник сам контролирует, какие транзакции входят в блок, он также может рассчитать, какой объём залога будет нужен. После того как цена пула синхронизирована с внешним рынком, наиболее выгодной стратегией становится back-running — то есть извлечение MEV уже после установления справедливой цены, а не за счёт LP.

А если арбитражник отклоняется от стратегии? Если он не выполняет backrunning или нарушает порядок, часть залога не возвращается — таким образом протокол наказывает нарушителей, заставляя их соблюдать правила и поддерживать синхронизацию цен.

Использование функции afterSwap. Для отслеживания отклонений цены и корректировок залога Arrakis Hook использует хуковую функцию afterSwap. После каждого свопа она:

• Пересчитывает отклонение текущей цены от committed price;
• Соответственно пересчитывает, сколько залога арбитражник может вернуть.

Результат:

• MEV-извлечение снижается;
• LVR уменьшается;
• Доходность LP возрастает.

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

На графике выше сравниваются различные стратегии минимизации LVR с обычным положением LP в классической модели Uniswap (CFMM). LP, использующие стратегии минимизации LVR, зарабатывают на ~5%–20% больше, чем стандартные LP в Uniswap.

Вывод: хук от Arrakis реализует жёстко структурированное поведение арбитражников, что позволяет:

• снизить утечку ценности из-за MEV,
• и существенно повысить доходность поставщиков ликвидности.

Sorella Angstrom — хук на базе AVS для минимизации LVR

Angstrom от команды Sorella — ещё одно решение, направленное на устранение LVR,

но реализованное через App-Specific Sequencing (ASS) — специализированную архитектуру упорядочивания транзакций.

Sorella комбинирует:

• Off-chain консенсус на базе AVS (Actively Validated Services);
• Хуки Uniswap V4.

(Тем самым создаётся) уникальный механизм перераспределения MEV с акцентом на защиту интересов LP.

Вот как работает пользовательский процесс в архитектуре Angstrom, использующей хуки Uniswap V4:

1. Арбитражники участвуют в аукционе за право отправить первую транзакцию в пуле с активированным Angstrom-хуком.
2. В это же время трейдеры отправляют свои своп-запросы в AVS-сеть Angstrom, которая поддерживает общий mempool.
3. Сеть Angstrom обрабатывает результаты аукциона и формирует транзакционный бандл, который затем отправляется в сеть Ethereum.
4. Транзакция арбитражника-победителя всегда размещается первой в этом бандле.
5. Бандл направляется к блок-билдерам и в мемпул Ethereum, после чего включается в блокчейн.

Как это минимизирует LVR? Ставка арбитражника-победителя (bid) перераспределяется между LP. Вместо того чтобы арбитражники забирали весь MEV себе, Angstrom продаёт MEV через аукцион и направляет доход LP.

Таким образом, LVR компенсируется, поскольку LP получают часть прибыли, которую они бы в противном случае потеряли из-за арбитража.

Как происходит перераспределение? Для корректного распределения доходов Angstrom:

• Отслеживает позиции LP;
• Обновляет данные при добавлении или удалении ликвидности;
• Использует хуки beforeAddLiquidity и beforeRemoveLiquidity в Uniswap V4.

Как и в Uniswap V3, Uniswap V4 использует переменную feeGrowthInside, чтобы отслеживать доход LP на единицу ликвидности. Angstrom расширяет эту механику, добавляя к ней распределение ставок из аукционов.

При каждом выполнении Angstrom-бандла сумма ставки добавляется к общей награде LP. При изменении ликвидности хук автоматически обновляет значения через хуковые функции. В результате LP получают часть MEV-прибыли, что снижает их LVR-риски.

Динамические комиссии на основе волатильности

Минимизировать LVR можно не только через перераспределение MEV. Поскольку LVR растёт при высокой волатильности, альтернативный способ — динамически менять комиссии LP в зависимости от рыночных условий.

Благодаря хукам, архитектура Uniswap V4 легко позволяет реализовать такие модели.

Другие DEX-платформы, такие как Trader Joe, Algebra, Hypersea, уже используют подобные механизмы. А проекты A51 Finance и Bunni разрабатывают хуки для V4 с адаптивными комиссиями, помогающими LP восстанавливать прибыль и снижать потери от LVR.

Запуск токенов на базе Uniswap V4 Hooks

Хуки в Uniswap V4 можно использовать и для создания инновационных механизмов запуска токенов.

Flaunch — честный запуск (Fair Launch) в Uniswap V4

Один из популярных кейсов — Fair Launch, где все получают равный доступ к покупке токена по фиксированной цене.

Flaunch разработал хук, позволяющий полностью провести запуск токена внутри пула Uniswap V4 — без дополнительных контрактов или миграции ликвидности.

Механика:

• После создания пула токены доступны по фиксированной цене;
• Во время фазы запуска все сделки проходят по фиксированной цене;
• По окончании запуска — пул переходит к стандартному поведению Uniswap.

Это реализовано через функцию beforeSwap, которая проверяет, находится ли пул в режиме запуска и фиксирует цену, если да.

Doppler от Whetstone Research — голландский аукцион + динамическая bonding-curve

Doppler — другой проект, использующий хуки для запуска токенов. Он сочетает:

• Голландский аукцион (цена уменьшается со временем);
• И динамическую bonding curve — для повышения цены после старта.

Механика запуска Doppler:

• Фаза 1: цена токена быстро падает (голландский аукцион), используя тики Uniswap V4. Аукцион продолжается, пока не появится первый покупатель — это и есть начальная рыночная цена.
• Фаза 2: после этого цена начинает плавно расти по кривой, зависящей от спроса.

Такой подход помогает:

• избежать снайперов, которые скупают токены по низкой цене;
• сформировать справедливую стартовую цену;
• автоматически создать ликвидность внутри пула V4.

После того как начальная цена токена установлена, он переходит в режим свободной торговли с использованием механизма bonding curve (ценовой кривой).

Ключевое отличие: кривая не статична — она динамически адаптируется к рыночным условиям.

Эпохи на bonding curve в Doppler. Doppler делит движение ценовой кривой на эпохи (epochs). В каждой эпохе оценивается спрос:

• Если в эпоху продано достаточно токенов → кривая сдвигается вверх (цена растёт);
• Если токены продаются плохо → кривая сдвигается вниз (цена снижается);

Результат:

• Процесс формирования цены более точно отражает реальный рыночный спрос;
• Поведение становится менее предсказуемым для ботов;
• Сложнее реализовать MEV-атаки и снайпинг, поскольку стартовая цена не фиксирована, а кривая динамична.

Таким образом, Doppler создаёт более справедливую и устойчивую модель запуска токенов, которая совмещает преимущества аукционов, bonding curves и гибкости хуков в Uniswap V4.

Вместо того чтобы вводить всю ликвидность одним действием после завершения фазы bonding curve, Doppler распределяет ликвидность поэтапно — через несколько эпох.

Такой подход:

• предотвращает front-running и sandwich-атаки,
• не позволяет ботам воспользоваться моментом добавления ликвидности,
• и снижает риски манипуляции с пулом или пользовательскими свопами.

Эта логика реализуется с помощью функций хуков Uniswap V4:

• beforeSwap;
• afterSwap;
• beforeAddLiquidity.

Резюме: Doppler предлагает уникальное решение для запуска токенов, объединяя:

• голландский аукцион,
• динамическую bonding curve,
• и постепенное распределение ликвидности.

Это позволяет:

• справедливо определить начальную цену токена,
• избежать MEV-эксплойтов,
• и создать устойчивый пул ликвидности с минимальными рисками.

Базовая реализация всего этого — через хуки Uniswap V4, что делает Doppler отличным примером продвинутого использования хуков для запуска токенов.

Будущее Uniswap V4 и DeFi

Uniswap остаётся самым используемым DEX в истории Ethereum, и с выходом V4 он стал:

• более модульным;
• более эффективным;
• и гораздо более настраиваемым

Что это значит для будущего DeFi?

Более устойчивый и эффективный рынок DeFi. Одно из главных ограничений AMM-протоколов — неэффективность капитала. Проблемы вроде impermanent loss, LVR, и высоких gas-издержек существовали давно.

Uniswap V4 решает это:

• через архитектуру Singleton;
• Flash Accounting;
• Нативную поддержку ETH.

Благодаря этому:

• стоимость развёртывания пула снизилась на 99%+;
• комиссии при обменах стали существенно ниже, чем в V3;
• пользовательский опыт на основной сети Ethereum стал значительно лучше.

Хуки = автономия для разработчиков

Хуки в V4 позволяют:

• настраивать логику AMM-пула;
• применять динамические комиссии;
• проектировать стратегии под разные рыночные сценарии.

Это позволяет достигать такой капитальной эффективности, что Uniswap может конкурировать с централизованными биржами.

Перераспределение MEV как стандарт

Сейчас активно разрабатываются хуки для:

• App-specific sequencing (ASS);
• MEV-минимизации;
• Реализации LP-инcентивов (доходов от MEV).

Модель, при которой часть MEV-дохода перераспределяется LP, может стать новым стандартом DeFi, что значительно укрепляет устойчивость всей системы.

Uniswap как устойчивая платформа

Самое большое нововведение V4 — хуки. Теперь разработчики могут:

• изменять механику AMM;
• строить пулы с любыми стратегиями;
• запуск токенов;
• адаптивные комиссии;
• MEV-защита;
• автоматизация LP-доходов.

Ожидается, что появится множество специализированных пулов под конкретные условия и цели.

Поверх Uniswap — новые протоколы

Хотя это не рассматривалось подробно в этом обзоре, на базе ликвидности Uniswap могут появляться:

• лендинговые протоколы;
• деривативные рынки;
• институциональные пулы с ограничением доступа (для соответствия регуляторным требованиям).

Это значит, что Uniswap перерастает DEX и становится платформой ликвидности, на которой могут строиться новые протоколы с помощью хуков.

Экосистема V4 = экосистема разработчиков

Например, экосистема Curve в 2022 году зависела от стимулов через токен $CRV,

что сделало её уязвимой к рыночным падениям.

Uniswap V4 устроен иначе:

• это экосистема для билдеров,
• проекты конкурируют и дополняют друг друга за счёт своей логики, а не токеномики,
• V4 привлекает разработчиков не наградами, а гибкостью и мощью хуков.

Позитивная петля роста

В результате:

• растёт прибыль LP;
• увеличивается TVL;
• растёт объём свопов;
• протокол усиливает свои позиции как лидер DeFi

Uniswap V4 — это новый фундамент для модульного, устойчивого и прогрессивного DeFi будущего.

До!