Beyond 90,000 Hooks: Uniswap v4 Is Running an AMM Kernel with Unaudited Plugins
Ninety thousand. That is the number of Uniswap v4 hooks initialized and linked to deployed pools, according to Crypto Briefing. Developers should pause before treating it as a trophy. An initialized hook is the cheapest possible form of commitment: a transaction that says, “this pool obeys extra rules.” It does not say the rules are safe, useful, or even unique.
I have watched DeFi run through similar numbers before. In 2020, everyone measured TVL. By 2021, everyone measured mints. By 2024, everyone counts hooks. The metric changes, but the bias does not. Hooks are not pools. They are attached contracts that execute at defined points in a pool’s lifecycle. They can be duplicated in a script. They can be initialized, abandoned, and forgotten while still appearing in an explorer chart. Ten thousand copies of the same limit-order hook still look like ten thousand innovations.
What does the count actually represent? Uniswap v2 pools are isolated x*y=k contracts. v3 adds concentrated liquidity and multiple fee levels, but the pool itself stays passive. v4 changes the unit of deployment. All pools now live in a Singleton contract. Accounting moves through flash accounting: a net balance system that computes what a user owes or receives at the end of the transaction, instead of moving tokens step by step. Hooks become the interface where external code can intervene before or after swaps, deposits, withdrawals, and donations.
For a builder, this is transformative. Limit orders become a hook. Automated LP rebalancing becomes a hook. Time-weighted average market making, dynamic fees, on-chain oracles, even custom auction mechanisms, can be nested inside a single pool. The report’s technical position is correct: v4 is not merely a DEX update. It is a shift from closed liquidity functions to open execution layers. The DEX becomes the execution layer; hooks become the strategy layer.
Yet the technical cost is exactly the thing the headline hides. Uniswap’s core contracts were audited by multiple firms and contested through bug bounties. The hook contracts were not. Anyone can write a hook that reads a pool’s balances and then acts after a swap. If that external code is buggy, malicious, or maliciously disguised as buggy, the pool’s liquidity sits at risk. I learned this pattern in a less glamorous place: auditing reward distribution functions during the 2020 liquidity mining period. The reentrancy was never in the transfer. It always lived in the state update that followed an external call. v4 has made external calls a core feature. Every callback is a potential reentrancy path, griefing vector, or bribe channel.
From outside, 90,000 hooks looks like ecosystem health. From inside, it looks like unmitigated surface area. The hidden insight is that hook count is nonlinear risk. An ordinary pool has one known code path. A v4 pool with a hook has at least two separate contracts executing in a single transaction. Multiply that by 90,000 individually deployed snippets, and you cannot retroactively assess the median quality of the ecosystem. All you can do is trust that the platform absorbs the explosion. Code does not lie, but it often forgets to breathe.
On the gas side, the efficiency argument is real. Singleton plus flash accounting batches multi-pool transfers into net settlements. Multiple fees can settle as one accounting delta. That is not marketing fluff; the bytecode savings are measurable. But gas optimization does not fix human behavior. Gas wars are just ego masquerading as utility. The same developer who celebrates 90,000 initialized hooks is often the one who publishes 500 copies of the same trading bot, turning a meaningful architecture signal into a false demand signal.
Here is the contrarian piece the celebratory dashboard leaves out: this milestone may be net negative for UNI tokenholders. Uniswap v4 hooks generate protocol usage, not protocol revenue. The fee switch is not active. UNI has no claim to the volume passing through these pools unless governance votes to activate that claim. In 2024, a proposal to distribute protocol fees to staked UNI was rejected. Hooks produce fees, but those fees flow to liquidity providers and hook operators, not to tokenholders. UNI remains an option on future governance, not a claim on current earnings. If someone treats 90,000 hooks as a UNI buy signal, they are conflating usage with cash flow.
The number also becomes courtroom evidence. The SEC has already argued that Uniswap functions as an unregistered exchange. A chart showing 90,000 executable plugins attached to an unlicensed trading surface is not a defense; it is a scale exhibit. A developer building a fork of Uniswap is another thing. But a financial system that allows 90,000 anonymous code modules to trigger, alter, or freeze trade settlement is exactly the kind of decentralised machine regulators struggle to classify—and choose to regulate through interface providers rather than core contracts.
Governance faces the deepest problem. Because hooks are permissionless, a pool can be controlled by immutable hook code outside any UNI vote. In v3, the DAO could, in principle, steer parameter changes on pools it governed. In v4, if a pool uses an immutable hook, the DAO has lost that lever. The governance blindspot is not theoretical. Malicious hooks could be deployed, attract liquidity, and be impossible to pause. Decentralization is a gradient, not a switch. The same property that makes v4 open makes it operationally indifferent to the people who depend on it.
The real winners so far are not UNI holders. They are LPs earning fees inside custom pools, arbitrage bots extracting inefficiencies from those same pools, and aggregators forced to support a broader routing graph. v4 is becoming a public goods layer for anybody who wants programmable AMM access. That is valuable. It is also unpaid.
So the only question that matters at 90,000 hooks is not “How big has the ecosystem become?” It is “Who can turn off a dangerous hook before it drains a pool?” No one can. In permissionless systems, safety is not prevention; it is the speed of detection after the exploit. Expect the next eighteen months to become a race between the first large hook catastrophe and an official hook allowlist. Uniswap will probably ship a curated registry or a security SDK. That registry will make some pools safer, but it will also recreate the gatekeeping that hooks were designed to remove. That is the trade-off hidden behind every integration at this scale.
