Last month I sat on a diligence call with a team that had raised $120 million to build on Uniswap V4 hooks. The architecture deck was beautiful โ animated liquidity flows, a three-sink token model, a roadmap shaped like a hockey stick. The threat model was one sentence. I asked who owned the failure mode of their beforeSwap callback. Silence. Then: "Hooks are permissionless, so that's Uniswap's problem."
I have asked that question forty times in eighteen months. That sentence is the whole bull market in miniature. We have sold a generation of founders on the idea that programmability is the same thing as safety, and the invoice for that confusion is being written right now, block by block.
Uniswap V4 shipped in early 2025 after one of the largest security budgets in DeFi history. It is a genuinely elegant redesign. Every pool now lives inside a single PoolManager singleton instead of its own contract, liquidity sits in transient storage, and flash accounting nets balances internally so only the final delta ever touches real tokens. Gas fell hard. An entire class of callback races disappeared. I have used it; it is fast in a way V3 never was. Under V3, pools were isolated, which meant an exploit was contained to one pool's liquidity โ brutal for that pool, survivable for the protocol.
V4 also turned every pool into an extension point. Hooks โ contracts that execute before and after swaps, liquidity changes, and donations โ let anyone bolt dynamic fees, on-chain limit orders, MEV recapture, or rebates onto a pool without forking the core. By 2026 several hundred hook-based venues hold real TVL, funded by a market that has decided programmability is the new moat. The pitch deck is always the same: "V4 lets you build a DEX that does X."
Here is the technical shape of the problem. Hooks are not sandboxed. A beforeSwap hook returns a BeforeSwapDelta, and the PoolManager trusts that number because it has to โ that trust is precisely what makes custom accounting possible. A hook that returns a delta it has never bounded, or that reenters the manager mid-flight while flash accounting is still unsettled, can propagate an accounting imbalance across every pool in the singleton. The blast radius is not one pool. It is the entire PoolManager. At my old audit desk we had a name for a design where a single contract custodies all the assets while arbitrary third-party code executes inside its call frame: a honeypot.
The economics make it worse. A V3 pool clone was roughly four hundred lines, and we could price it in a week. A V4 hook is four hundred lines of your own code sitting on a trust boundary against a four-thousand-line singleton, plus a fee curve, plus an oracle read, plus a liquidation path. That is four disciplines stacked in one file. Teams pay for one. In a sample of thirty-one hooks my collaborators and I reviewed through 2025, most had no explicit bound on the returned delta, and almost none had a pause path. Hooks are also immutable or timelocked, and they are permissionless: no registry, no review gate, no one to call at 3 a.m. Uniswap's documentation says, correctly, that hooks are third-party code. That is a disclaimer, not a control.
The audit market has not caught up. An audit of a hook is scoped to the hook, because that is what the client pays for, but the bug usually lives in the interaction โ the delta returned to a manager that has already credited a balance that does not exist yet. Nobody audits the seam. There is no coverage market either: insurers price protocols, not individual callbacks, so the hook author carries liability with none of the actuarial tools to model it.
The tooling gap is real too. Foundry can fuzz a hook against a mock manager, but almost nobody fuzzes it against a stateful singleton with realistic transient balances, because building that harness takes weeks and the round closes in three. We have better tools than 2020 and worse habits than 2020: the audit used to be the gate, and now it is a press release.
Who pays when it breaks is the part nobody models. The PoolManager is immutable; Uniswap governance cannot freeze a hook it did not write. If a hook drains the singleton, the loss is socialized across LPs who never opted into that hook's design โ they opted into a pool, and the pool inherited a callback. In V3, consent was per-pool. In V4, consent is per-transaction and mostly invisible.
I still think hooks are the right architecture โ that is not the dispute. The counter-argument writes itself, and I hear it from purists constantly: complexity is the price of expressiveness, and the market will eventually audit what the market values. Except right now the market values speed. Which is why the threat I worry about most is not a hack.
A hook can call an oracle, and a compliance provider is an oracle. Embedding a jurisdiction allowlist into a pool is now a few lines of Solidity, and it will ship as a feature โ "institutional-ready," "regulator-friendly," a slide with a shield icon. Once that lands, the permissionless claim dies quietly and nobody notices, because the interface looks exactly the same. The Tornado Cash precedent sharpened the blade here: if publishing code can be treated as an offense, hook authors are the least protected people in the stack, and the same lobbying engine that pushes programmatic compliance will not spend a dollar defending them.
So watch the audits, not the announcements. Watch whether the delta is bounded, whether there is a pause, whether the hook can reenter the manager before settlement. True ownership begins where the server ends โ and a hook is a server wearing a smart-contract costume. The pools that survive this cycle will be the boring ones: bounded deltas, timelocked hooks, an auditor who actually read the seam.
The question for 2026 is not whether V4 can be secured. It is whether we will keep calling it permissionless while quietly selling the permission. Debate is the compiler for better consensus. Let us have it before the invoice arrives.