0x’s review of 84,163 Uniswap v4 Hooks deployed across six blockchains found that 54.2% were classified as malicious and 26.4% as suspected malicious, according to results published through Sept. 11. Only 19.4% of the contracts examined met the firm’s “safe” classification, placing renewed focus on how trading interfaces and routing systems handle Uniswap v4’s programmable pool extensions.
The findings prompted a public response from Hayden Adams, founder of Uniswap Labs, who argued on X that harmful smart contracts are an expected byproduct of permissionless systems. Adams said protections against unreviewed code should be applied by interfaces and applications rather than imposed at the protocol layer.
The disagreement centers on a practical question for decentralized trading: who should bear responsibility for filtering pool logic that can alter the economics of a swap? Uniswap v4 allows developers to attach Hooks—smart contracts that execute custom functions before or after trades—to liquidity pools. That flexibility can support dynamic fees, automated yield strategies for idle liquidity, and pools with access restrictions. It can also give pool creators ways to change trade outcomes after a user has received an initial quote.
Quote spoofing changes a swap after the quote
0x described one recurring exploit pattern as “quote spoofing.” Under this design, a Hook presents a favorable exchange rate during a request-for-quote process, then modifies key parameters or imposes large fees when the transaction is executed onchain.
The firm said some contracts attempt to identify whether they are being examined in a simulated environment or called during a live Ethereum Virtual Machine transaction. A Hook that detects a simulation can return normal-looking results to a routing engine, then activate different behavior once a real user trade arrives.
Other contracts reportedly use random changes in their parameters, making repeated tests less reliable. A router may simulate the same trade several times and receive an acceptable result, only for the Hook to apply a different fee or pricing rule in the executed transaction.
0x said it observed hidden fees of as much as 18% on active trading pairs. In the most extreme case included in its findings, a user received 50% less than the amount shown in the quoted trade. According to the company, the contracts involved extracted hundreds of thousands of dollars from users whose swap settings permitted broad slippage—the percentage difference a trader accepts between an expected and final execution price.
The report cited a Base-based ETH/NVDAc pool that collected more than $143,000 in unexpected user fees. It also identified a BNB Chain deployment that took roughly $18,600 by changing the effective terms applied at settlement.
Those examples illustrate why a displayed quote alone may not fully describe the risk of a v4 route. A standard automated market maker pool has predictable swap mechanics encoded in its contract. A Hook can add an extra layer of logic that determines fees, access, or other conditions around that swap.
Scanned Hooks are not the same as user exposure
The 84,163 figure represents every Hook analyzed by 0x, rather than the number of contracts that users traded through. The scan included inactive deployments, a distinction that limits conclusions about how much trading volume was exposed to the flagged contracts.
That difference is central to interpreting the headline classification rate. A large onchain population of suspicious contracts does not establish that most Uniswap v4 users encountered them, nor does it show that malicious Hooks controlled a comparable share of liquidity or volume. Many deployed contracts may never have attracted meaningful activity.
Yet the size of the scanned universe shows how quickly the number of custom pool components can grow in a permissionless environment. Unlike a conventional listing process, developers can deploy smart contracts without obtaining approval from Uniswap Labs or a centralized venue. Trading applications then decide which pools and Hooks to expose, simulate, or route user orders through.
0x said that, since the beginning of 2026, its platform routed 81.92 million transactions valued at $42.67 billion. About 70% of that activity involved Uniswap liquidity, according to the company. The firm characterized unreviewed Hooks as a material routing risk when an aggregator or application reaches pools whose custom code has not been screened.
Adams points to application-level filtering
Adams said malicious behavior predates Uniswap v4 and has appeared through harmful ERC-20 tokens, honeypots and rug-pull liquidity pools in earlier iterations of the protocol. He added that Uniswap’s official interface and API route only through reviewed Hooks.
His position places the responsibility for selection controls with the applications that build trading routes, including third-party aggregators. In that model, the protocol remains open for developers to deploy new pool designs, while front ends establish their own standards for review, warnings, blocklists, and routing eligibility.
That approach has an operational consequence: protections can vary considerably between products. A user interacting through Uniswap’s official interface may face a different pool-selection process than a user who reaches the same liquidity through an independent router, a wallet swap feature, or a direct contract call.
The trade-off is familiar in decentralized finance, but v4 makes it more immediate. Hooks can provide useful specialized functions that may not fit a universal approval framework. At the same time, each added function expands the amount of code a router must understand before treating an initial quote as reliable.
Routing safeguards become a competitive issue
The report is likely to increase pressure on routing services to verify Hook behavior under live-like execution conditions rather than relying only on standard simulations. Screening may include reviewing source code where available, testing fee behavior across different transaction contexts, limiting routes to known implementations, and excluding pools whose execution results diverge from quoted output.
For users, the most direct safeguard remains setting tight slippage tolerance. A strict limit can cause a transaction to revert when the final amount received falls below the trader’s acceptable threshold, although it cannot prevent every form of harmful pool design. Checking the pool and Hook contract address before approving a trade can also help users avoid interacting with unfamiliar custom logic.
The dispute between 0x and Adams does not turn on whether malicious contracts exist; both sides acknowledge that they do. It turns on where permissionless trading systems should place the filtering layer as custom pool logic becomes more common: in the base protocol, in official interfaces, or in every independent service that chooses a user’s trading path.
Concerned about malicious Hooks and DeFi exploits? Learn essential protection strategies in crypto safety standards every trader should know.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
