Written by: Xiaobing

The DEX aggregator 0x dropped a data bomb on September 14: the team analyzed 84,163 Uniswap v4 Hooks across 6 chains, with the conclusion as of September 11 that only 19.4% of Hooks were deemed safe, 54.2% malicious, and 26.4% suspiciously malicious.

Uniswap founder Hayden Adams subsequently responded on X, with the core position being: the existence of malicious Hooks is a necessary byproduct of a permissionless system, but users transacting through the official Uniswap API and vetted frontend will not encounter these malicious pools. The issue lies in the routing selection capability of aggregators, not in the architecture design of v4.

A debate regarding the cost of DeFi's "openness" thus erupted publicly between two leading protocols.

0x's accusation: Quote Spoofing

0x described the attack model very specifically: malicious Hooks display highly competitive quotes during the aggregator's pricing inquiry phase, attracting the routing engine to redirect transactions to their pools. However, during the actual execution of transactions, the Hook alters pricing parameters or injects punitive rates, leading users to receive assets far lower than the quoted amounts.

0x defined this attack as "Quote Spoofing." Its technical implementation includes: detecting the EVM execution environment (differentiating between simulated calls and actual transactions, only modifying during real transactions), random alternating parameters (making it difficult for the detection system to consistently reproduce malicious behavior), and charging hidden fees of up to 18% on active trading pairs.

In the most extreme case, users received assets 50% less than the quoted amount. 0x claimed that these malicious Hooks extracted hundreds of thousands of dollars from users with loose slippage tolerances.

Data from 0x itself shows that since 2026, its platform has routed 81.92 million transactions, with a trading volume of $42.67 billion, of which about 70% involved Uniswap liquidity. As one of the largest external distribution channels for Uniswap liquidity, 0x has a direct commercial incentive to solve this issue, as malicious Hooks harm the trading experience for 0x users, thereby affecting 0x's brand reputation and trading volume.

Response from Hayden Adams

Adams's rebuttal can be distilled into three layers:

Anyone can create malicious contracts on Ethereum; this is not an issue unique to v4. Malicious ERC-20 tokens, honey pot contracts, and Rug Pull pools existed in abundance during the v2 and v3 eras. Hooks merely provide a new technical carrier for malicious behavior; the essence of the attack has not changed—it still exploits users' default trust in the safety of on-chain assets.

The official Uniswap frontend and API only connect to vetted Hooks. Uniswap's Niko (@saintniko, a member of the Uniswap product team) clearly pointed out at the same time that users trading through the official Uniswap API will only encounter audited Hooks. Uniswap's position is clear: the protocol layer is open, but the application layer has done the filtering.

Aggregators need to be responsible for their routing decisions. If 0x's routing engine indiscriminately connected to over 80,000 unvetted Hooks, that is a flaw in the aggregator's own risk control. Just as any stock exchange would not be responsible for over-the-counter scams, the Uniswap protocol should not bear responsibility for routing errors of third-party aggregators.

0x's data is indeed shocking, but several dimensions need attention:

84,163 Hooks is the total number of "analyzed" ones, not the total number "interacted with by users." This number includes many zombie Hooks that have never had real transactions; they were deployed but may have never been routed. It's like counting all contracts deployed on Ethereum, where over 90% may never have been called, yet they are still included in the base count.

The true core of the debate

Peeling away the technical details and the mudslinging, the divergence between 0x and Uniswap points to an old DeFi problem: the openness of a permissionless system inevitably invites malicious actors.

The v4 Hook system represents the largest architectural leap in Uniswap's history. The pool logic of v2 and v3 was fixed, with the behavior of all pools entirely determined by protocol code. v4 opened up the behavior of pools to developers, allowing anyone to write custom logic and execute arbitrary code before and after transactions. This has led to innovations like StablePair Hook (dynamic rates), DualPool Hook (idle fund earnings), and Permissioned Pools (compliance verification), while inevitably opening the door to malicious exploitation.

Uniswap's logic is that the value created by openness far outweighs the losses caused by malicious actions, and security filtering should be done by the application layer (frontend, API, aggregator), rather than restricting innovation at the protocol layer.

This aligns with Ethereum's own design philosophy, where Ethereum will not prevent you from deploying malicious contracts, but wallets and frontends will filter them.

0x's logic is that when over half of the Hooks are malicious, the filtering burden on the application layer has become unreasonable. The protocol layer should at least provide better tools to help downstream identify and isolate malicious Hooks. 0x claimed it has already prevented malicious pools from entering the routing through detection technology and pool audits, but the cost of this arms race is increasingly high.

Actual impact on users

If you trade through the official Uniswap frontend (app.uniswap.org), the risk of being affected by malicious Hooks is very low, as Uniswap claims its API only connects to vetted Hooks.

If you trade through third-party aggregators (0x, 1inch, Paraswap, etc.), the risk depends on the Hook filtering capability of these aggregators. 0x claims it has established detection and blocking mechanisms; other aggregators have varying levels of defense.

If you interact directly with on-chain contracts (through Etherscan or custom scripts), you are fully exposed to the risk of malicious Hooks. This is the domain of advanced users and the highest risk scenario.

A simple self-protection principle: Check if your trading frontend has a filtering mechanism for v4 Hooks. If you are unsure, stick to using the official Uniswap frontend. Set a reasonable slippage tolerance; 0x's report shows that malicious Hooks mainly target users with overly loose slippage settings.