Uniswap v4 has been live since last February. One of its biggest innovations compared to Uniswap v3 is the ability to set up custom liquidity pools using hooks.
Hooks are a new feature that enables developers to customize actions at different stages of a pool's lifecycle. With these tailored functionalities, custom pools can be created with new automated strategies enhancing DeFi interactions, such as incentivization!
Incentivization on Uniswap v3 was a complex challenge (that’s why we built Merkl), but with hooks in Uniswap v4, you could create pools with built-in reward mechanisms for liquidity providers (LPs).
However, just because it’s possible doesn’t mean it’s always the right approach.
So why use Merkl to incentivize Uniswap v4 pools instead of building a custom hook?
Gas efficiency
First, incentive hooks can increase gas fees for liquidity providers with every swap, making Uniswap v4 less gas-efficient overall — especially when the primary goal is to attract volume.
On the other hand, incentivizing via Merkl minimizes gas fees. Merkl enables incentive distribution without altering pool logic. Since it operates on top of Uniswap, it requires no additional computation—meaning no extra gas costs.
Customization options
Second, Uniswap v4 hooks offer less customization compared to Merkl.
With Uniswap v4 hooks, there's no way to "forward" incentives to users. If a LP uses an automated liquidity manager (ALM), the rewards go to the ALM, not the user.
With Merkl, ALMs are automatically detected, and the incentive distributor can choose whether to activate the forwarder feature to ensure rewards are sent to the original liquidity owner.
Simplicity and security
Third, combining incentive hooks with other hook types could be challenging.
An incentive hook on Uniswap v4 wouldn’t add unique functionality to the pool’s behavior — it simply brings onchain what could be done more efficiently offchain (with Merkl for instance).
For example, imagine a Uniswap v4 pool with a hook designed to deposit idle liquidity from the pool into multiple lending protocols. Adding an incentive hook to encourage users to perform the desired action forces developers to design pools that combine both the incentive hook and the action hook, increasing complexity and potential vulnerabilities, thereby exposing users to greater risks.
Hook builders should focus on creating something new and useful, rather than expanding the attack surface by adding an incentive hook which could easily be managed separately.
To conclude, incentive hooks are interesting, but they might be overkill considering the existing incentive platforms that offer the same features with less complexity and risk.