{"id":205467,"date":"2026-07-28T13:11:00","date_gmt":"2026-07-28T13:11:00","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=205467"},"modified":"2026-07-28T13:11:00","modified_gmt":"2026-07-28T13:11:00","slug":"after-uniswap-v4-went-live-the-pool-is-no-longer-the-whole-market","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=205467","title":{"rendered":"After Uniswap v4 Went Live. The Pool Is No Longer the Whole Market."},"content":{"rendered":"

Overview.<\/strong> Schematic only. Hooks are opt-in modules around a concentrated-liquidity pool; simple pools can remain simple. Not measured from a live deployment.<\/p>\n

Uniswap v4 has been live long enough that the interesting question is no longer what hooks can do. The question is what changes when the pool is no longer the whole market\u00a0object.<\/p>\n

The deeper shift is not that pools gained features. It is that routes can now select rule ownership.<\/p>\n

A v4 pool can still be simple. But once it opts into hooks, the router is no longer touching only liquidity and price. It is also touching an authority graph<\/strong>: which hook can run, when it can run, what it can write, which fees it can change, and which accounting assumptions it controls.<\/p>\n

Put differently: the route is no longer just choosing liquidity. It may also be choosing who owns the\u00a0rules.<\/p>\n

That is the engineering shift. Programmability is not just flexibility. It makes the authority around the pool part of the thing being traded\u00a0against.<\/p>\n

Why now?<\/h3>\n

Uniswap v4 is not new launch news anymore. That is exactly why the question is more interesting now.<\/p>\n

At launch, hooks were mostly described as optional customization: dynamic fees, callbacks, custom accounting, new pool behavior. That was the design story. The post-launch question is different: once those rules move into hook contracts, who owns the rule, who audits it, and who pays when it\u00a0fails?<\/p>\n

That question is no longer theoretical. Bunni<\/a> made it visible from the security side: custom logic can fail outside the core pool. Hyperliquid makes it visible from the market side: book-native venues can still attract flow, fees, and attention when traders care about execution, leverage, and speed. CoW makes it visible from the routing side: execution can move into signed intents and solver competition without becoming a\u00a0CLOB.<\/p>\n

So this piece is not a late introduction to Uniswap v4 hooks. It is a post-launch question about DEX direction. Are DEXs dying, drifting back toward CLOBs, or evolving into several execution surfaces at\u00a0once?<\/p>\n

My read is the third one. The pool is not disappearing. But the rules around the pool are becoming harder to\u00a0ignore.<\/p>\n

The launch story was programmability. The post-launch story is rule ownership: who gets to change execution, who prices that authority, and who finds the failure boundary\u00a0first.<\/p>\n

The pool was simple by\u00a0design<\/h3>\n

Uniswap\u2019s history reads less like a replacement story and more like a gradual widening of the control surface around the\u00a0pool.<\/p>\n

v2<\/strong> kept the surface small: reserves, a constant-product curve, a fixed swap fee, and arbitrage against callable inventory. Few moving parts meant a small audit\u00a0object.<\/p>\n

v3<\/strong> added LP range placement and concentrated liquidity. LP positions were commonly represented through NFT positions in the periphery; where inventory sat inside tick ranges became part of what you had to read. The core math was still pool mechanics inside ticks-not a price-time queue.<\/p>\n

v4<\/strong> pushes further into lifecycle hooks, dynamic fees, custom accounting, and execution timing. Uniswap v4 does not hide every policy inside the core protocol; it lets application builders, hook authors, routers, and liquidity managers move specific behavior into explicit code-and with it, delegated authority around the pool. Hooks<\/a> are external contracts attached to individual pools, called at defined lifecycle points ( beforeSwap, afterSwap, liquidity changes, initialization) to intercept and modify execution flow. State moves into a singleton PoolManager<\/a>: shared accounting for all pools, not a centralized exchange\u00a0backend.<\/p>\n

Before routers and hooks, the basic AMM audit object was already the pool-reserves or ticks, fee parameters, swap logs. In v4, that object can include external authority around\u00a0it.<\/p>\n

Hooks move control into the pool lifecycle<\/h3>\n

Hooks matter because they let a pool choose which rules become programmable: fee response, execution timing, accounting, hook fees, conditional execution, and liquidity behavior. The pool remains the base layer; the hook defines a permission map around\u00a0it.<\/p>\n

beforeSwap \/ <\/strong>afterSwap<\/strong> – pre\/post swap intervention; programmable steps around the core\u00a0swap.Dynamic fees<\/strong>\u200a\u2014\u200aLP fee response; volatility- or flow-sensitive fee schedule.Hook fees<\/strong>\u200a\u2014\u200aseparate fee layer; value capture outside the LP\u00a0fee.Custom accounting \/ delta-return<\/strong>\u200a\u2014\u200aswap-leg settlement; highest audit expansion (see AsyncSwap).TWAMM-style<\/strong>\u200a\u2014\u200alarge trade timing; time-sliced execution across\u00a0blocks.Limit-order-like<\/strong>\u200a\u2014\u200aconditional execution; functional analogy only-not a\u00a0queue.<\/p>\n

This is where v4 becomes more interesting than a feature list. A v3 pool can be wrong for an LP because the range is wrong, the fee is wrong, or the flow is toxic. A v4 hooked pool adds another question: which part of that defense moved into code outside the core pool? The pool did not disappear, but the thing a trader touches is no longer only the\u00a0pool.<\/p>\n

The important part is not that hooks can do many things. The important part is that each extra behavior grants authority somewhere.<\/p>\n

If the fee changes with volatility, the hook has fee authority. If a hook returns deltas, it has accounting authority. If execution is delayed or sliced, it has timing authority. If a router prefers one hooked pool over another, it is not only choosing liquidity. It is choosing which hook authority comes with the\u00a0route.<\/p>\n

That is why a hooked pool is no longer just a pool with extra logic. It is a pool plus delegated authority.<\/p>\n

CLOB comparisons are easy to overread. A hooked pool can mimic some functions<\/em> of a book-conditional execution, time-sliced flow, fee schedules-but it is still not a price-time priority queue. TWAMM-style hooks spread execution over time; they do not create a hidden matching\u00a0engine.<\/p>\n

AsyncSwap<\/strong><\/a> is the path I would inspect first on a hooked deployment: delta-return permissions can move swap-leg accounting into the hook. Flash accounting in the PoolManager still requires deltas to settle by transaction end, but the audit trail no longer stops at the core\u00a0swap.<\/p>\n

A pool with address(0) hooks or minimal permissions still audits like a compact concentrated-liquidity object. Turn hooks on, and delegated authority around the pool becomes part of the market\u00a0object.<\/p>\n

Fig. 1.<\/strong> Hooks change the audit object. v3: pool address, fee tier, tick\/liquidity, LP positions, swap logs. v4 hooked pool: add PoolManager\/PoolId, hook address, callback path, dynamic fees, hook fees, and custom accounting. Schematic checklist\u2014not an exhaustive hook taxonomy.<\/p>\n

The engineering question is authority<\/h3>\n

For an engineer, a hooked pool starts with a permission map.<\/p>\n

Who selected this hook for the pool? Who controls the hook contract? If it is upgradeable, who can upgrade it? If it has admin parameters, who can change them? Can it be paused? Which caller does the hook trust? Does it assume the trader is msg.sender, or does it correctly account for the PoolManager and router path? Which balances are internal, which are pool balances, and which are external dependencies?<\/p>\n

Those are not side questions. They define the market object-and map the authority graph around the pool. A pool with the same tokens and the same visible liquidity can behave differently if a different contract has fee authority, accounting authority, timing authority, or admin authority around\u00a0it.<\/p>\n

When authority fails outside the\u00a0core<\/h3>\n

On 2 September 2025<\/strong>, Bunni<\/a>-a liquidity layer built as a Uniswap v4 hook-lost ~$8.4M<\/strong> in an exploit, per the team\u2019s post-mortem<\/a>. I treat the post-mortem as the primary technical account; I did not independently re-audit the on-chain\u00a0trace.<\/p>\n

Bunni is not useful here as proof that hooks are broken. It is useful because it shows that failure can live in the authority delegated outside the core\u00a0pool.<\/p>\n

In this case, the relevant story was not Uniswap v4 core swap math. It was hook-side accounting. That is the new audit question: not only \u201cis the pool safe?\u201d but \u201cwhich external authority did this pool opt into, and where can that authority break?\u201d<\/p>\n

What the charts show-and what they do\u00a0not<\/h3>\n

The figures below are a bounded read, not a full map of DEX activity. Panel A pulls DeFiLlama summary\/dexs volume for six spot protocols (Uniswap, PancakeSwap, Aerodrome, Orca, Raydium, Curve), aggregates to monthly shares, and uses a trailing-thirty-day window for the headline numbers. Panel B charts Hyperliquid perp trading fees ( fees\/hyperliquid-perps) as a book-native attention signal-a different metric class from the six-protocol spot sample. Spot DEX volume, aggregator volume, perp volume, TVL, and protocol fees should not share one denominator; I do not rank them on a single\u00a0chart.<\/p>\n

Fig. 2.<\/strong> Trading surfaces split by mechanism (DeFiLlama pulls, accessed Jul 2026). Panel A:<\/strong> monthly spot DEX volume share across a six-protocol sample. Panel B:<\/strong> Hyperliquid perp trading fees (`fees\/hyperliquid-perps`) as a book-native attention signal. These panels use different metric classes and are not a shared market-share denominator. Latest partial month omitted. CoW omitted because no clean reproducible series was available in this\u00a0pull.<\/p>\n

In that six-protocol spot sample, trailing-thirty-day volume was about $83B<\/strong>; Uniswap was roughly 44%<\/strong>. PancakeSwap and Aerodrome took most of the remainder. Pool-native execution is still large across\u00a0chains.<\/p>\n

CoW Protocol<\/a> is the solver-side example in prose: users sign intents for a desired outcome; solvers compete under batch-auction rules. I did not chart it\u00a0here.<\/p>\n

Hyperliquid perp trading fees over the same thirty days: about $63M<\/strong> ( fees\/hyperliquid-perps). Perp notional volume is much larger-about $209B<\/strong> on DeFiLlama’s derivatives series in the 9 July 2026 check-but that dimension is not reproduced in the free API pull behind Panel\u00a0B.<\/p>\n

v4 adoption is not the same as hook\u00a0adoption<\/h3>\n

Version share and hook share are different measurements. A protocol can ship optional hooks long before hooked pools dominate\u00a0volume.<\/p>\n

DeFiLlama child slugs ( uniswap-v2, uniswap-v3, uniswap-v4) give a reproducible spot-DEX version series ( python3 scripts\/fetch_uniswap_version_share.py). In the trailing thirty days of the 9 July 2026 API check, v4 was about 60%<\/strong> of Uniswap spot DEX volume in the series, v3 about 39%<\/strong>, v2 about\u00a01%<\/strong>.<\/p>\n

Hook-enabled volume is not in that series. Hook adoption remains an open measurement lane at publication time.<\/p>\n

Fig. 3.<\/strong> DeFiLlama spot-DEX volume by Uniswap version (v2 \/ v3 \/ v4), monthly share within Uniswap only. This is version share within Uniswap spot-DEX volume only; it does not measure hook-enabled volume. Child-slug series is a reproducible DeFiLlama classification, not an audited decomposition of every Uniswap-routed trade.<\/p>\n

v4 shows up clearly in the DeFiLlama version series. What share of that volume actually runs through hooked pools is still unresolved.<\/p>\n

Hyperliquid from the other\u00a0side<\/h3>\n

Hyperliquid<\/a> matters here because it represents pressure from the other side. A venue that still attracts transactions, fees, and attention becomes hard to ignore, especially when traders care about execution, speed, leverage, and visible market activity.<\/p>\n

I do not read Uniswap v4 as a path toward a CLOB. Moving toward a book is not only a technical choice. It pulls DeFi back toward venue-style market design: makers, queues, matching, margin, risk engines, and a stronger operator surface. That may be efficient. It is also a different philosophy from a callable\u00a0pool.<\/p>\n

That does not mean Uniswap should become Hyperliquid. A book-native venue that attracts flow, fees, and attention proves demand for a different authority allocation. It does not prove that the pool is obsolete. CoW Protocol<\/a> sits on yet another axis-solver competition over signed intents. None of these replace the others; they allocate authority differently.<\/p>\n

Fig. 4.<\/strong> Different surfaces, different metrics\u200a\u2014\u200anot a single ranking. Three independent 30d attention signals: Uniswap share within the six-protocol spot sample, Hyperliquid perp fees (`fees\/hyperliquid-perps`), and Hyperliquid perp volume (DeFiLlama derivatives UI check\u200a\u2014\u200anot in the free API\u00a0pull).<\/p>\n

Closing<\/h3>\n

Uniswap v4 is not a book. CoW is not a pool. Hyperliquid is not an AMM. They are different answers to the same pressure: users want better execution, but nobody wants to be the last person to discover where the risk was\u00a0hidden.<\/p>\n

The next DEX competition may not be pool versus book. It may be rule ownership versus rule ownership.<\/p>\n

One system gives rule authority to hooks around a pool. One gives it to solvers over signed intents. One gives it to a book, makers, margin, funding, and a risk engine. Traders experience these as routes. LPs experience them as flow and risk. Builders experience them as product surfaces. Auditors experience them as failure boundaries.<\/p>\n

That is why the pool is no longer the whole market. Liquidity still matters, but the route is no longer only asking \u201cwhich pool has depth?\u201d It is also asking \u201cwho owns the rules around this execution, and what can fail\u00a0there?\u201d<\/p>\n

Liquidity still decides where a route can go. Rule ownership decides what the route is actually touching.<\/p>\n

The next DEX question may not be which mechanism wins. It is whether traders, routers, LPs, and auditors can see who owns the rules before capital discovers the failure mode for\u00a0them.<\/p>\n

Appendix: sources and reproducibility<\/h3>\n

Uniswap v4: overview<\/a>, hooks<\/a>, swap hooks<\/a>, dynamic fees<\/a>, AsyncSwap<\/a>, security<\/a>CoW Protocol: intents<\/a>Bunni: exploit post-mortem<\/a> (2 Sep\u00a02025)Hyperliquid Perps: DeFiLlama protocol page<\/a> (perp fees and 30d perp volume UI\u00a0check)Data fetching scripts: gist<\/a> (fetch_trading_surfaces.py, fetch_uniswap_version_share.py, probe_v4_subgraph.py)<\/p>\n

This post was originally published on my personal blog: <\/em>https:\/\/egpivo.github.io\/2026\/07\/28\/when-the-pool-gets-options.html<\/em><\/a><\/p>\n

After Uniswap v4 Went Live. The Pool Is No Longer the Whole Market.<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

Overview. Schematic only. Hooks are opt-in modules around a concentrated-liquidity pool; simple pools can remain simple. Not measured from a live deployment. Uniswap v4 has been live long enough that the interesting question is no longer what hooks can do. The question is what changes when the pool is no longer the whole market\u00a0object. The […]<\/p>\n","protected":false},"author":0,"featured_media":205468,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-205467","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/205467"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=205467"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/205467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/205468"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=205467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=205467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=205467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}