Over the past seven days, thirty-four new hooks went live on the Uniswap V4 hook registry. Twenty-nine of them recorded zero unique wallet interactions by their third day of existence. Nineteen were never called at all โ not a single swap, not a single liquidity event, nothing beyond the deployer's initial probe transaction.
I have been pulling this registry data every Tuesday for eleven months. The pattern is not new. What is new is the silence around it.
In February 2026, Uniswap Labs pushed a series of governance proposals celebrating what its communications team called "the composability era." The decks were clean. The dashboards were green. The Discord was euphoric. What the decks did not show was that 61% of all hooks deployed since the V4 mainnet launch have fewer than ten lifetime unique callers. Charts lie, but the on-chain wallets never sleep. And what the wallets are saying, in a language no marketing team can edit, is that V4's greatest architectural promise โ the ability to turn a DEX into programmable Lego โ has become DeFi's most expensive way to deploy dead code.
This is not a eulogy. It is an audit.
The Registry Numbers
Let me be precise about what the canonical registry actually contains, because the aggregate numbers are misleading and I have watched too many analysts cite them without context. As of the fourth week of February 2026, the Uniswap V4 Hook Registry lists 1,847 deployed hook contracts. Of those, 1,129 have been classified by my team as "inactive" โ zero transactions in the trailing ninety days. Another 314 are classified as "abandoned" โ they had activity at some point but no unique caller in the last six months. That leaves 404 hooks with any meaningful trailing activity. That is 21.9% of the registry.
Strip out the hooks that are essentially duplicates โ forks of a handful of popular templates, redeployments by the same studio under a new address, and a small cluster of hooks that appear to have been deployed for testing purposes and never cleaned up โ and you get roughly 140 hooks that have documented organic usage. That is 7.6% of everything deployed.
A 7.6% survival rate sounds damning. And if you stopped your analysis there, you could write a very clean, very viral post titled "Uniswap V4 Is Dead." The problem is that this framing is lazy, and lazy framing is how you lose money. The interesting question is not how many hooks are dead. The interesting question is what the surviving hooks have in common, and what the distribution of failure looks like at the developer level rather than the contract level.
To answer that, I spent six weeks reconstructing the deployer graph. The method matters, so I will describe it in full.
Methodology
I pulled every deploy transaction from the registry and extracted the deployer address. I then clustered deployers by funding source โ the address that first sent ETH to the deployer wallet. This separates organic developers from sybil farms, from hackathon participants, from a small set of well-known studios, and from a long tail of wallets funded by the same centralized exchange hot wallet cluster that also funds thousands of unrelated testnet-farming bots.
I then mapped each surviving hook to its deployer's historical mainnet deployment record, using Etherscan's API to pull contract age. A deployer with a three-month-old mainnet contract is a different animal from a deployer whose only on-chain footprint is the hook itself. This distinction turns out to matter more than anything else in the dataset.
Finally, I categorized the 140 organic hooks by function, and I built a gas cost model comparing them to a matched sample of V3-era integration contracts deployed in the same period. The methodology for the cost model is described later. I want the reader to understand the chain of evidence before I start drawing conclusions, because the conclusions are uncomfortable and I expect them to be disputed by people who have not done the work.
Finding One: The Failure Distribution Is Bimodal
Of the 1,847 hooks, 1,021 were deployed by addresses that funded themselves from a single central exchange hot wallet cluster. These are almost certainly hackathon submissions, tutorial deployments, or straight-up noise. Their median lifetime unique callers: one. Their median gas consumption on deployment: 1.8 million gas, which at current base fees is real money that somebody paid to deploy code nobody will ever use.
This is the first and most important observation. The hook registry is not failing gradually. It is failing at the moment of deployment. The vast majority of hooks are born dead, and they are born dead for a trivial reason: the deployer had no plan beyond the tutorial.
I have seen this pattern before, and I want to flag the analogy because it will save you time. In 2021, when the EVM's CREATE2 opcode became widely accessible, there was a wave of deterministic deployment scripts and factory contracts that produced thousands of empty contract addresses. Analysts briefly confused the count of deployments with the count of deployed applications. The same confusion is happening now with hooks. Count is a vanity metric. It is the equivalent of measuring the health of a city by the number of registered businesses rather than the number of businesses that generate revenue.
Finding Two: The Surviving Hooks Come From Prior Mainnet Deployers
Of the 140 organic hooks, 118 were deployed by developers with a documented pre-V4 mainnet track record. Only 22 came from first-time mainnet deployers. That is a 5-to-1 ratio.
The ledger is the only court of final appeal, and it is telling us something uncomfortable. The composability thesis โ the idea that V4 would lower the barrier to entry for building financial primitives โ is real, but the barrier is not where anyone advertised. The barrier is not Solidity knowledge. The barrier is not the ability to read the V4 whitepaper. The barrier is the accumulated judgment that comes from having shipped mainnet code before, watched it fail in production, and fixed it.
I audited four hooks in the last quarter as part of my fund's due diligence. Two had reentrancy vulnerabilities that had not been caught in their published audits. One had a rounding error in a fee-splitting calculation that leaked value to the pool deployer at a rate of about 0.3 basis points per swap โ small, but compounding, and invisible on any dashboard because the loss is distributed across thousands of LPs. The fourth was clean.
A 50% vulnerability rate in a non-random sample is not a scientific finding. But it is a signal, and signals are what this business runs on. The signal is that V4 hooks are being deployed faster than they are being understood, by developers who are not yet ready to deploy financial infrastructure. The teams that survive this filter are the ones that treat the hook as a security perimeter, not a weekend project.
Finding Three: The Surviving Hooks Are Overwhelmingly Passive
I categorized the 140 organic hooks by function. Here is the breakdown:
- 62 hooks (44.3%) are fee-related: dynamic fee adjustment, fee routing, fee splitting, fee rebates. These are mostly passive observers that adjust a variable within a predefined range.
- 31 hooks (22.1%) are oracle-related: TWAP feeds, volatility detectors, price-band triggers.
- 19 hooks (13.6%) are LP-related: automated rebalancing logic, LP position management, just-in-time liquidity provision.
- 11 hooks (7.9%) are compliance-related: KYC gates, sanction filters, allowlist enforcement.
- 17 hooks (12.1%) are everything else: MEV auctions, limit orders, custom curves, and a long tail of experiments.
Notice what is missing. The one hook category that would justify the entire V4 thesis โ the one that would turn Uniswap into a general-purpose liquidity layer for arbitrary financial logic โ is the smallest. Limit-order books? Seventeen hooks. On-chain options? I counted four viable ones. Structured products? Two, and both are still below $2 million in TVL.
The grand promise of V4 was that it would let anyone build a financial primitive on top of the deepest liquidity in DeFi. What actually happened is that it let a few experienced teams build incremental improvements to fee mechanics, and then it let everyone else deploy dead code. The most popular hook category is the one that is essentially a knob. The most ambitious category is the one that barely exists.
The Complexity Tax, Quantified
I want to quantify the developer barrier, because "complexity" is a word analysts throw around without numbers, and numbers are the whole point. So I built a cost model.
Method: I selected ten hooks from the registry with documented organic usage and extracted three metrics โ deployment gas, per-swap gas overhead, and average monthly maintenance gas, with the latter defined as the gas spent on administrative transactions such as updating parameters, adjusting fees, and migrating state. I compared those to ten comparable V3 integration contracts deployed in the same period, matched by pool type and TVL range.
The results:
- Deployment gas: V4 hooks averaged 2.1 million gas versus 480,000 gas for comparable V3 integrations. A 337% increase.
- Per-swap overhead: V4 hooks added an average of 41,000 gas per swap versus V3's baseline. On a 1 ETH swap at current gas prices, that is roughly a 12-14 basis point tax on every trade that touches the hook.
- Monthly maintenance gas: V4 hooks averaged 380,000 gas per month versus 94,000 gas for V3 integrations. A 304% increase.
This is what I mean by the complexity tax. It is not abstract. Every hook that actually operates is paying a premium in gas to do what a V3 integration could do for a third of the cost โ and that premium is passed on to LPs and swappers, one basis point at a time.
For a hook to be economically rational, it has to generate more value than 12 basis points per swap. Most do not. The ones that do are the fee hooks, because a well-tuned dynamic fee can recapture more than 12 basis points from adverse selection. The ones that fail are the exotic ones โ the hook that tries to offer a limit order, the hook that tries to run an auction, the hook that tries to do something clever with MEV. They cannot clear the cost bar.
This is the part the marketing decks leave out. Alpha is found in the friction, not the flow. The friction here is real, and it is fatal to the majority of the projects the V4 ecosystem has celebrated. I have watched three hook teams announce mainnet launches in the last six months, run for roughly three weeks, and then quietly stop posting updates because the gas economics ate their LP returns alive. None of them published a post-mortem. You will not find their names in any ecosystem report. You will only find them in the registry, where their contracts sit with zero callers in the trailing ninety days, waiting to be reclassified as abandoned.
A Case Study in Dynamic Fees
Let me make this concrete, because the aggregate numbers are easy to dismiss and a single case is harder to argue with.
I followed one dynamic-fee hook on a major stablecoin pair for four months. The hook's stated purpose was to widen fees during volatility events and narrow them during calm, capturing more revenue from arbitrageurs and less from retail. The design was clever. The audit was legitimate. The team was experienced.
What happened is instructive. During calm periods, the hook's narrow fees attracted volume, which is the intended behavior. During volatility spikes, the hook widened fees, which drove volume to a competing V3 pool with static fees. The hook captured the spread it was designed to capture, but it lost the flow. Over the four months, the hook's average fee revenue per dollar of TVL was 18% lower than the static V3 pool it was competing against.
Why? Because the hook's dynamic logic was reactive. It widened fees after volatility already started, which is precisely when searchers are most active and most price-sensitive. The V3 pool with static fees simply absorbed the flow at a predictable cost. In a sideways market, predictability beats cleverness. The hook's designers built a better mousetrap and then discovered that the mice had already left for a cheaper neighborhood.
This is not a story about a bad team. It is a story about an architecture that imposes costs on every participant that touches it. The hook could be perfectly designed and still lose to a simpler mechanism, because the simpler mechanism does not pay the complexity tax.
The Governance Problem Nobody Talks About
There is a second-order effect that I have not seen anyone else model, and I want to put a flag on it because it will matter in the next twelve months.
Hook parameters โ the fee bounds, the oracle sources, the rebalancing thresholds โ are usually set by a governance process. Sometimes that process is a multisig. Sometimes it is a token-voted DAO. Sometimes it is a single EOA, which is a different problem entirely and not the one I want to discuss here.
What I want to discuss is delegation.
I pulled the governance structures of the top twenty organic hooks by TVL. Of those twenty, thirteen have some form of delegated voting. Of those thirteen, the median number of unique delegates holding at least 1% of voting power is four. Four people. Four people making fee decisions for pools that, in aggregate, hold $1.4 billion in liquidity.
This is the exact pathology I have been writing about for years in the DAO context, and it is now infecting DeFi's most important protocol. Delegation was sold as a democratization mechanism. In practice, it is a laziness mechanism. Users do not want to research hook-level parameters. They delegate to whoever has the loudest social media presence. That opinion leader then becomes a de facto central banker for a liquidity pool they may not even understand.
I traced one case in detail. A dynamic fee hook on a major stablecoin pair delegated fee-setting authority to a group of seven addresses. Within three months, four of those seven had been replaced by the same multisig, because the original delegates were inactive. Nobody noticed. There was no governance alert. The hook's fee schedule quietly changed from a 2-8 basis point range to a 1-15 basis point range. That is a real change to the economics of every LP in that pool, and it happened without a single forum post.
Skepticism is the shield; data is the sword. If you are providing liquidity through a hook and you have not checked who actually controls its parameters, you are not an LP. You are a counterparty to a governance process you did not participate in, and probably did not know existed.
The V4 vs. V3 Frontline
Let me put the comparison directly on the table, because the V4 ecosystem's defenders will want to argue this is an unfair framing.
V3 integrations required forking or building on top of the V3 periphery. That had costs โ audit costs, upgrade costs, security surface โ but the mechanism was well-understood, the tooling was mature, and the failure modes were documented. V4 hooks reduce some of those costs by keeping the core protocol singleton and letting hooks plug in. In theory, that is a better architecture.
In practice, the V4 hook developer has to reason about a state space that is dramatically larger. Hooks interact with the pool's tick bitmap. They interact with the fee accumulator. They interact with the position manager. They run before and after every swap, and if the hook is not gas-optimal, every swap pays for that inefficiency. The attack surface is not smaller than a V3 fork. It is different, and it is more subtle, and subtle bugs are worse than obvious ones because they survive audits.
I have been on both sides of this comparison. I spent six weeks in 2017 reverse-engineering the 0x Protocol v1 contracts, looking for edge-case vulnerabilities in the order matching logic. What I learned then applies here: the attack surface of a composable system is the union of every component that can be composed, not the surface of any single component. V4 hooks compose with each other. That is the feature. It is also the risk. A single flawed hook in a widely used pool does not just break that pool. It changes the behavior of every other hook that reads from it, including hooks that were audited and deployed by more careful teams.
Ecosystem reports do not model this. They count deployments. They celebrate TVL. They do not reconstruct the dependency graph, because the dependency graph would show them how fragile the whole structure is.
What the Bears Get Wrong
I want to push back on something I expect to hear from both sides of this debate, because both sides are getting it wrong in a way that costs real money.
The bears will say: hooks are a failed experiment, V4 was a mistake, the registry is a graveyard. This is true in a narrow sense and wrong in a broad one. A registry full of dead contracts is not evidence that the design failed. It is evidence that the design is ungated, and ungated systems always fill with noise. The question is not how many hooks are dead. The question is how much liquidity is being productively managed by hooks that work. On that metric, the numbers are actually growing. Slowly. Selectively. But growing.
The bulls will say: give it time, hooks are early, the ecosystem is still maturing. This is also true, but it is a way to avoid asking the harder question, which is whether the architecture itself imposes a ceiling on adoption. Some of what I am seeing is early-adopter friction that will resolve with better tooling. Some of it is structural. The gas overhead of running custom logic on every swap is not going to disappear with developer experience. It is a thermodynamic constraint of the design. Hooks that cannot overcome that constraint will never be viable, no matter how much time passes.
We didn't miss the crash; we shorted the narrative. And the narrative here โ that hooks would democratize financial engineering โ is a narrative worth shorting. But the underlying technology, the composability, the singleton architecture, the ability to express custom liquidity logic without forking โ that is real, and it will compound for years. The mistake is confusing adoption of a tool with adoption of a market. They are different curves. The tool is being adopted. The market is being tested.
What I Am Watching Next
The signal to watch is not hook deployment count. It is the concentration of TVL in hooks that meet three criteria: more than six months live, a second audit after launch, and a delegate set that has not turned over in ninety days. Those are the hooks that will define V4's legacy. If that concentration is rising quarter over quarter, the ecosystem is maturing. If it is flat or falling, the ecosystem is thrashing, and the clever teams will migrate to a different architecture within eighteen months.
I will be publishing that concentration metric monthly, starting next Tuesday, because the registry is public and the data does not forgive. That is the entire point.
If you are an LP, stop allocating to hooks on the basis of deployment date or headline TVL. Check the governance structure. Check the maintenance gas spend. Check whether the hook is actually doing something necessary or whether it is a thinly veiled way to extract fees from an uninformed pool.
If you are a developer, understand that the composability thesis is real but the economics are brutal. A hook that does something clever is worth less than a hook that does something necessary and cheap. The teams that win in the next eighteen months will be the ones that treat gas overhead as a first-class design constraint, not an afterthought.
If you are an investor, the question to ask is not who is building on V4. It is who is building on V4 and still shipping after the third month, when the initial enthusiasm has faded and the gas bills have arrived. That is the only cohort that matters.
Everything else is noise. And noise, in my experience, is where people lose money without ever knowing why. The ledger will keep the score. It always does.