To me, Uniswap v4 hooks are the best thing to happen to DEXs in years. When I look at the onchain ideas that have interested me most over the past two years, hooks keep coming up. They let developers change how a pool works, and I think some of the most interesting things still to come onchain will be built with them.
Useful technology can also be used maliciously. That is a reason to understand what you are integrating. It does not make the technology a mistake.
0x's analysis classified only 19% of the more than 84,000 v4 hooks it examined as safe. Its article was titled Uniswap v4 hooks were a mistake.
Hayden Adams, Uniswap's founder, responded that teams should filter the hooks they route through, and pointed them to Uniswap's API.
I agree with him. If your router sends a user's trade through a malicious pool, why did it accept that pool? An attractive quote is not enough. Leave it out if you cannot support it safely. That applies to 0x just as much as anyone else.
0x's article does advocate validation and describes its filtering work. I agree with that work. I disagree with the headline.
Was ERC-20 a mistake too?
Anyone can create an ERC-20 token. If a large number of abusive deployments is enough to dismiss hooks, we could use the same reasoning to say ERC-20 was a mistake.
In its study of Ethereum tokens launched in 2023, Chainalysis found that 53.6% of those listed on a DEX met its criteria for possible pump-and-dump activity. Yet those tokens represented just 1.3% of Ethereum DEX trading volume.
That is the distinction I care about. Deployment counts alone tell us little about which contracts people actually trade through. Scam tokens do not make the ERC-20 standard itself a mistake. Hooks introduce their own execution risks, but counting malicious implementations does not settle whether the design is useful.
What did you actually trust?
A v4 hook is an external contract attached to a pool. It can run custom logic at specific points in the pool's execution, including before and after swaps. The hook address encodes callback permissions, and some permissions allow the hook to adjust accounting deltas. The amounts owed or received. These are documented parts of the hook interface.
Those permissions describe what a hook can participate in. You still need to understand what its implementation does.
I have built a v4 hook myself. kvhook used address verification to restrict access to a pool. That restriction was the product. A router integrating it would need to understand who could actually use it.
The best quote still needs validation
Your router has two candidate routes. One advertises 100 tokens. Another advertises 103 through a hook your integration does not understand. The larger number does not establish that the user will receive it.
0x reports hooks that behave differently during quoting and settlement. Its ETH/NVDAc example on Base shows this fee distribution:
Variable fees alone do not prove a deceptive quote. This chart also does not identify which router selected each trade or what each user was promised. The failure to prevent is accepting a quote that does not hold under the transaction's execution conditions.
Validation is part of finding the best route. If 0x's hook selection fails, that routing failure belongs to 0x. If it cannot support a hook safely, leaving the pool out is a valid engineering decision.
What does the 19% establish?
0x's breakdown covers 84,163 hooks across six chains: 19.4% safe, 54.2% malicious, and 26.4% likely malicious.
As with the ERC-20 example, the share of deployments does not tell us the share of trading volume or user exposure. It also does not tell us which hooks a particular aggregator accepts.
The question for that aggregator is: which hooks did your system accept, and what justified accepting them?
Uniswap already provides the routing API
Hayden pointed to an existing integration path. The Uniswap Trading API handles routing, quoting, and transaction construction. Its quote endpoint lets integrators include hooks, require them, or exclude them from v4 quotes.
For teams that are really building their own routers, Uniswap publishes hooklist, with deployed addresses, callback flags, and properties such as dynamic fees and upgradeability. Registry inclusion does not mean routing approval. Uniswap Labs has a separate routing allowlist process. Some hooks require review, while others are automatically eligible. That review checks compatibility and is not a security audit.
0x has its own custom hook integration process. Both teams already treat hook support as a decision. Uniswap provides tools for making it, an aggregator choosing its own routing still owns the resulting integration.
Hayden's follow-up challenged the framing of 0x's criticism:
Skill issue
Users rely on aggregators to evaluate routes. Expecting them to audit every hook in a split trade defeats much of the point of using one.
I agree with Hayden. 0x's findings make the case for better routing. They do not establish that hooks were a mistake.
You choose the route. Keeping malicious pools out of it is part of the job, and part of why users rely on aggregators in the first place. The integration tools already exist. Use them, or build your own validation. Make the product better.
If your router cannot safely support a hook, leave it out. Blaming hooks for that is a skill issue.