Liquidity Management UniswapV4 Hook
In this article, we cover the design of our Liquidity management hook from our Uniswap Foundation Hook POC grant. This hook automates position management for liquidity providers directly after the deposit. The goal of the hook is to make providing liquidity seamless and more profitable for the LPs.
If you are interested in building your own hooks, we recommend reading the V4 documentation for a general introduction to UniswapV4 and hooks.
❓ Why is liquidity management needed?
For liquidity providers, concentrated liquidity pools are very demanding and require frequent manual management. On top of that, it is hard to remain profitable as impermanent loss, LVR, and rebalancing costs eat a big part of the generated fees. This is reflected in the amount of newly opened pools in V2 and V3, more than 90% of them are V2 and hold 40% of the Uniswap liquidity.
The liquidity management hook automates the liquidity deposited in the pool and provides the services of an Automated Liquidity Manager (ALM). Thanks to the hook, users don’t have to manage it on their own or visit 3rd party platforms to do the same thing, which increases the user experience and removes entry barriers to becoming an LP.
How the hook works
The hook manages all users’ deposits and divides them into two positions. The first one is fixed and deposited in an infinite range (like a V2-pool); the second one is narrow and automatically rebalanced. Having an infinite range, or at least very wide, is needed to guarantee enough liquidity to automatically rebalance the narrow position.
Parameters for rebalancing the narrow range are hardcoded at the pool deployment but could be replaced by a backend system. By having the parameters publicly available, the users can always verify how the hook works, but that is a double-edged sword because it is known when the hook will rebalance and could be front-run.
The hook determines the narrow range and rebalance triggers by:
- Tick space — The number of ticks, where 1 tick = 0.01%
- Price boundary — Defines the width of the narrow range by the number of Tick spaces
- Rebalance boundary — Defines how many Tick spaces the price needs to move to rebalance the narrow range
Example
Tick space = 60 (0.6%)
Price boundary of the Narrow range = 30
Rebalance boundary = 25
Narrow range width = Tick space * Price boundary = 1800 (6%)
Trigger to rebalance = Tick space * rebalance boundary = 1500 (5%)
In this example, the narrow range will be 6% and the rebalance will happen if the price moves by 5%.
Generated fees
The generated fees from trading are autocompounded back to the pool, but they may not be distributed equally. This can result in leaving some liquidity in the contract for a short time, but they will be gradually reinvested with additional swaps, deposits, and withdrawals.
🎁 Providing Liquidity
Users can choose if they deposit directly into the pool or into the hook that manages the position. If they deposit in the hook, the hook automatically claims all accumulated fees from the pool and adds them together with the new deposits in the full and narrow ranges.
After the deposit, the hook calls the ERC20 LP token contract which mints an appropriate amount of new LP tokens for the liquidity provider.
⚖️ Rebalances
When a user tries to swap, the hook automatically checks if the narrow range needs to be rebalanced. If the incoming swap moves the price out of the rebalance boundary, the rebalance gets triggered in the same transaction after the swap. It will withdraw the funds from the narrow range, swap them in the pool, and deposit them again in the narrow range around the current price. The gas fees for the rebalance are paid by the swapper and the rebalance can happen only once per swap. The rebalance should happen as a top-of-block swap to prevent MEV searchers from front-running the transaction.
The rebalancing mechanism could be enhanced by other parameters than just the price movement. It could limit the amount of rebalances in a day, it could widen the narrow range if the position gets rebalanced too many times, or it could use external data from oracles to check if the rebalancing is needed.
🔓 Withdrawing Liquidity
When a liquidity provider initiates a withdrawal, they burn the specified amount of ERC20 LP tokens from their wallet. Then the hook collects all fees and removes liquidity from narrow and wide ranges proportional to the amount of tokens burned. Then the user receives the withdrawn liquidity.
⚠️ Risks
Many potential risks come from the initial setup of the hook and it will require a good understanding of concentrated liquidity pools and their mechanics. How the narrow position and its rebalance triggers are set is the first stage where something might go wrong, because many setups won’t be profitable in the long run.
Another risk comes from how the liquidity is divided between the infinite and narrow ranges as it impacts the slippage on rebalances. Having too much liquidity in the narrow range compared to the infinite range could result in substantial losses during rebalances as there won’t be enough liquidity to trade upon and the slippage will slowly drain the pool. Further research and experiments will be needed to find the optimal ratio.
The hook manager could get exploited or be malicious. Even though the attacker can’t withdraw the funds, they could trigger a constant rebalancing leading to losing funds in the pool to the swapping fees.
Then there are some risks related to the hook being a POC and not production-ready
- It is susceptible to sandwich attacks, as it rebalances the narrow range in one transaction, but it can be mitigated by rebalancing through multiple smaller transactions
- Reentrancy attacks can be mitigated by including a standard reentrancy attack solution by OpenZeppelin
Having the right setup for the Liquidity Management Hook will require thorough testing and experimentation due to its complexity. The hook manager needs to take care of security while making the hook work well for the liquidity providers. But when done properly, it will be a great asset for pool deployers and their LPs.
🪝 Check Our Other Hooks
- Locking liquidity for incentives
- Dynamic fees by Volume
- Liquidity Management
- Combo hook — Locking liquidity + Dynamic fees (coming)
