0x and Uniswap Clash Publicly: Over Half of v4 Hooks Flagged as Malicious — Who Should Pay for Openness?
- Core Viewpoint: 0x's report claims that over half of Uniswap v4 Hooks carry malicious risks. Uniswap's founder responded that this is the inevitable cost of a permissionless system, and that security filtering should be the responsibility of the application layer rather than the protocol layer.
- Key Elements:
- 0x analyzed 84,163 Hooks across 6 chains, finding only 19.4% safe, 54.2% malicious, and 26.4% suspected malicious.
- Malicious Hooks attack through "quote deception," detecting the execution environment and randomly alternating parameters to charge hidden fees of up to 18%. In extreme cases, users receive 50% less than the quoted amount.
- Since 2026, the 0x platform has routed 81.92 million transactions with a trading volume of $42.67 billion, approximately 70% of which involved Uniswap liquidity.
- Hayden Adams responded: Malicious contracts are not a problem unique to v4; the official API only integrates vetted Hooks; aggregators should be responsible for their own routing decisions.
- The 84,163 Hooks represent the total analyzed, not the number users actually interact with, and include a large number of zombie Hooks.
- The debate centers on the long-standing DeFi issue of the coexistence of permissionless system openness and malicious behavior. The v4 Hook system is Uniswap's largest architectural leap.
- Users face low risk through Uniswap's official frontend; risk through third-party aggregators depends on their filtering capabilities; direct on-chain interaction carries the highest risk.
Original author: Xiaobing
DEX aggregator 0x dropped a data bombshell on September 14: the team analyzed 84,163 Uniswap v4 Hooks across 6 chains, and as of September 11, concluded that only 19.4% of Hooks were deemed safe, 54.2% malicious, and 26.4% suspected malicious.
Uniswap founder Hayden Adams subsequently responded on X, with the core position being: the existence of malicious Hooks is an inevitable byproduct of a permissionless system, but users trading through the Uniswap official API and the reviewed frontend will not encounter these malicious pools. The problem lies in the aggregator's routing filtering capability, not in v4's architectural design.
A debate about the cost of DeFi's "openness" thus erupted publicly between two leading protocols.
0x's Accusation: Quote Spoofing
The attack pattern described by 0x is very specific: malicious Hooks display highly competitive quotes during the aggregator's price inquiry phase, luring routing engines to direct trades to their own pools. But during actual trade execution, the Hook tampers with pricing parameters or injects punitive fees, causing users to receive assets far below the quoted price.
0x defines this attack as "Quote Spoofing." Its technical implementation methods include: detecting the EVM execution environment (distinguishing between simulated calls and real transactions, only manipulating during real transactions), randomly alternating parameters (making it difficult for detection systems to consistently reproduce malicious behavior), and charging hidden fees of up to 18% on active trading pairs.
In the most extreme cases, users received 50% less in assets than quoted. 0x claims these malicious Hooks extracted hundreds of thousands of dollars from users with loose slippage tolerance settings.
0x's own data shows that since 2026, its platform has routed 81.92 million transactions with a trading volume of $42.67 billion, of which approximately 70% involves Uniswap liquidity. As one of the largest external distribution channels for Uniswap liquidity, 0x has a direct commercial incentive to solve this problem, because malicious Hooks damage the trading experience of 0x users, which in turn affects 0x's own brand reputation and trading volume.
Hayden Adams' Response
Adams' counterargument logic can be distilled into three layers:
Anyone can create malicious contracts on Ethereum — this is not a problem unique to v4. Malicious ERC-20 tokens, honeypot contracts, and Rug Pull pools existed in large numbers during the v2 and v3 eras. Hooks merely give malicious behavior a new technical vehicle; the essence of the attack remains unchanged — it still exploits users' default trust in the security of on-chain assets.
The Uniswap official frontend and API only connect to reviewed Hooks. Uniswap's Niko (@saintniko, a member of the Uniswap product team) explicitly pointed out at the same time that users trading through the Uniswap official API will only encounter vetted Hooks. Uniswap's position is clear: the protocol layer is open, but the application layer has already implemented filtering.
Aggregators need to take responsibility for their own routing decisions. If 0x's routing engine indiscriminately connects to over 80,000 unreviewed Hooks, then that is a risk control deficiency on the aggregator's part. Just as no stock exchange is responsible for off-exchange fraud, the Uniswap protocol should not bear responsibility for third-party aggregators' routing failures.
0x's data itself is shocking enough, but several dimensions need to be noted:
The 84,163 Hooks represent the total number "analyzed," not the total number "interacted with by users." This figure includes a large number of zombie Hooks that have never had real transactions — they were deployed but may never have been routed to. It's like counting all contracts ever deployed on Ethereum — over 90% may never have been called, but they are still counted in the base.
The Real Core of the Debate
Stripping away technical details and verbal sparring, the disagreement between 0x and Uniswap points to an old DeFi problem: the openness of a permissionless system inevitably comes with the entry of malicious actors.
v4's Hook system is the largest architectural leap in Uniswap's history. The pool logic of v2 and v3 is fixed — all pool behavior is entirely determined by protocol code. v4 opens up pool behavior to developers, allowing anyone to write custom logic and execute arbitrary code before and after transactions. This brings innovations like StablePair Hook (dynamic fees), DualPool Hook (idle capital yield), and Permissioned Pools (compliance verification), but inevitably also opens the door to malicious exploitation.
Uniswap's logic is: the value created by openness far exceeds the losses caused by malicious behavior, and security filtering should be done at the application layer (frontend, API, aggregators) rather than restricting innovation at the protocol layer.
This is consistent with Ethereum's own design philosophy — Ethereum won't stop you from deploying malicious contracts, but wallets and frontends will filter them.
0x's logic is: when more than half of Hooks are malicious, the filtering burden on the application layer has become unreasonably large. The protocol layer should at least provide better tools to help downstream identify and isolate malicious Hooks. 0x claims it has already prevented malicious pools from entering its routing through detection technology and pool auditing, but the cost of this arms race is growing ever higher.
Practical Impact on Users
If you trade through the Uniswap official frontend (app.uniswap.org), the risk of being affected by malicious Hooks is very low, because Uniswap claims its API only connects to reviewed Hooks.
If you trade through third-party aggregators (0x, 1inch, Paraswap, etc.), the risk depends on these aggregators' Hook filtering capabilities. 0x claims it has established detection and blocking mechanisms, while 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 also the highest-risk scenario.
A simple self-protection principle: Check whether your trading frontend has a filtering mechanism for v4 Hooks. If you're not sure, stick to the Uniswap official frontend. Set a reasonable slippage tolerance — 0x's report shows that malicious Hooks primarily target users with overly loose slippage settings.
