.jpg?table=block&id=3e52d44d-39b0-800d-9447-df948fd86100&cache=v2)
Table of Contents
- Why Uniswap v4 Hooks and Modular AMMs Matter
- Uniswap's Permissionless Approach Isn't Safe by Default: What 0x Found When It Analyzed 84,000+ v4 Hooks
- How to Solve It: a List of "Good" Hooks, or a Different Model Like Algebra's Trust Layer
- Examples of How This Works, and Why It's Cool: Teams Innovating While Guaranteeing Safety
- How Governed Plugins Change the AMM Security Model
- Bottom Line
Do not index
Programmable AMM pools – Uniswap v4 hooks, Algebra Integral plugins, Balancer v3 hooks, Ekubo extensions – are a convergent, correct architectural direction, not a single vendor's gimmick. But a recent research piece by 0x on malicious Uniswap v4 hooks raised an important question about the design itself: is Uniswap’s fully permissionless approach really the right model for production liquidity?
The real fight isn't "modularity vs. no modularity." It's whether the surrounding trust infrastructure (registries, vetting, governance, aggregator-side filtering) matures fast enough to keep permissionless extensibility from being abused. Read in full, even 0x's own critique argues for better vetting of modularity, not against modularity itself.
Why Uniswap v4 Hooks and Modular AMMs Matter
Modular AMM logic isn't a side experiment anymore – it's carrying more capital and volume than the fixed-fee designs that came before it, and every major "next-gen AMM" now ships some version of the same idea: a pool exposes lifecycle callback points, and an external contract plugs into them to alter behavior.
- Uniswap v4: $1.197B TVL, $131.4M in 30d fees, $42.34B in 30d volume — annualized fees/TVL of 131.7%, ~3.2x its own non-hooked predecessor Uniswap V3 (41.2%) .
- v4's 30d TVL is up +24.1%, with fees and TVL growing together – consistent with real adoption, not a price effect.
- The aggregator layer routing into hooked pools is scaling right alongside it: 0x routed $10.10B in 30d volume (+76.2%), KyberSwap $8.81B (+69.9%), 1inch $2.81B .
The demand for this functionality is genuinely ecosystem-wide, not one vendor's feature list:
Category | What it does | Confirmed live example |
Limit orders / TWAMM | Adds order types not native to a plain AMM curve | Uniswap Labs' own official TWAMM hook: breaks large orders into small per-block fills to reduce price impact and front-running, cited as a canonical use case in both Uniswap and Algebra docs |
Dynamic fees | Adjusts swap fee in real time based on volatility, volume, or inventory | Nest (Hyperliquid) – dynamic-fee plugin correlated with rising effective fee rate; SparkDEX's Dynamic Fees module;
Algebra’s OG Dynamic Fee plugin |
MEV internalization | Captures arbitrage/sandwich value at the pool level instead of leaking it to searchers | SparkDEX’s "MEV-X Homelander" – internalizes arbitrage via afterSwap |
Fee-tier discounts by governance token | Reduces fees for token-locked/voting users | Balancer's own reference veBAL discount hook |
RWA price-awareness | Repositions liquidity around an external NAV oracle instead of relying on arbitrage | Hydrex (Base) – NAV Plugin for tokenized treasuries/private credit powered by Algebra |
Custom accounting / non-x*y=k curves | Lets a pool run a different pricing function than constant-product | Native to both v4 hooks and Algebra plugins by design |
Token-issuer LP protection | Shields project-owned liquidity from arbitrage-driven MEV using dynamic fees | Arrakis Pro Hook: the first hook whitelisted by Uniswap's own routing allowlist for dynamic fees, built specifically to protect token-issuer LPs |
And it goes far beyond that.
This list is exactly the same shape whether you start from Uniswap's docs or Algebra's – which is the point: the demand for this functionality is ecosystem-wide, not just Algebra and its powered DEXs.
Uniswap's Permissionless Approach Isn't Safe by Default: What 0x Found When It Analyzed 84,000+ v4 Hooks
“Hooks enable a huge amount of useful innovation. The tradeoff is they also introduce a real complexity tax which can harm users through bad execution quality. The answer isn’t to go back to a world without hooks; it’s to build better infrastructure for identifying what’s safe to interact with and keeping users protected.” – Amir Bandeali, CEO of 0x
0x's Sept 14, 2026 post ("Uniswap v4 hooks were a mistake") is real and undisputed by Uniswap on the numbers:
- 84,163 v4 hooks scanned across 6 chains (as of Sept 11, 2026): 19.4% safe, 54.2% malicious, 26.4% likely malicious.
- The mechanism: a malicious hook quotes one price to an aggregator and settles a different one on-chain – some routes delivered up to 50% less than quoted.
- Concrete examples from 0x's data: a Base ETH/NVDAc hook skimmed $143,037 across 6,516 fills (up to 18% fee); a BNB USDT/WBNB hook skimmed ~$18.6K on 33.2% of fills.
- Real production losses can be attributed to custom logic from hooks: Cork Protocol lost $12.0M (May 28, 2025 – a missing caller-check inside hook logic) and Bunni lost $8.4M (Sept 2, 2025 – a rounding bug in hook-adjacent accounting) .
- Hayden Adams' "skill issue" response agreed on the facts, disagreeing only on where the fix belongs — router-side allowlisting vs. hook-side restriction. Both sides are pro-modularity; the disagreement is about who owns the vetting layer.
The general engineering lesson here isn't Uniswap-specific. Balancer's own reference hook implementation explicitly checks params.router!= _trustedRouter before trusting a caller-supplied user address, because "getSender() may be manipulated by a malicious router" – that's the exact same bug class that enabled Cork's exploit. Missing caller-validation is a general modular-AMM discipline problem, not something baked into Uniswap's permission model specifically.
How to Solve It: a List of "Good" Hooks, or a Different Model Like Algebra's Trust Layer
Two real, currently-deployed answers exist side by side, and they aren't rivals – they're different layers of the same trust stack: build → review → audit → govern → deploy → route → monitor.
Option A: Curate a registry of "good" hooks, keep the permissionless base layer:
- Uniswap hooklist – a public registry of known v4 hooks (address, permission flags, upgradeability, custom-swap-data requirements), with submissions going through automated code triage before human review.
- Uniswap's routing allowlist – a separate, stricter layer determining which hooks actually get surfaced through Uniswap's own routing (upgradeable hooks and hooks needing custom data are explicitly excluded).
- Uniswap Foundation security framework – a self-assessment rubric mapping hook complexity/risk to recommended audits, monitoring, and bug bounties.
- Trail of Bits' hook checklist – a catalogue of recurring real-world failure patterns (missing caller checks, accounting edge cases) for builders and auditors to check against.
- 0x's own routing layer – detection and due diligence applied before a pool becomes eligible for routing at all.
Option B: Change who can attach logic to a pool in the first place (Algebra Integral's governed model):
- The AMM Core handles fundamental pool/liquidity logic; plugins extend it through the same kind of callback points, but only the DEX operator/DAO – via AlgebraFactory's POOLS_ADMINISTRATOR role – can call setPlugin to attach one to a live pool.
- Plugin deployment is governed by the DEX admin – plugins can be combined and multiple pools can exist for the same pair, but only the authorized admin can attach plugin logic to a pool. The key security advantage is therefore not limiting extensibility, but making the DEX operator explicitly responsible for what reaches production.
- Governance turns the trust boundary into an explicit checklist before anything reaches production: Who built it? Has it been reviewed/audited? What capabilities does it have? Which version is deployed? Who can upgrade it? How is it monitored? What happens if it misbehaves?
- Honest caveat: this doesn't eliminate risk, it relocates it – we stress that an admin could swap in a malicious plugin. It also ships an optional permissionless path (EntryPoint) a DEX can enable, so "governed" is a configuration choice, not an absolute guarantee.
Neither model alone would have stopped Cork or Bunni – both were bugs inside already-approved code, not deployment-gating failures. A registry or a governance gate controls who attaches logic; catching what's inside that logic still needs real audits.
Examples of How This Works, and Why It's Cool: Teams Innovating While Guaranteeing Safety
The efficiency numbers back this up – governed plugins aren't automatically "better," they're one credible tool among several, and results depend on product-market fit as much as architecture:
Hydrex (55.7% annualized fees/TVL) and Blackhole (43.1%) beat every permissionless AMM in this comparison except Uniswap v4 itself; Ekubo – a fully independent singleton+extensions design, not a Uniswap or Algebra fork – posts the highest 30-day turnover of the entire field (45.5x) on a permissionless model. Governance style alone doesn't decide who wins .
Here's what teams running real liquidity say about it, in their own words:
SparkDEX:
"For us, the lesson isn't that modularity is dangerous – modularity is what lets DEX infrastructure evolve without constantly rebuilding the core. The important question is how that modular logic reaches production. There's a big difference between allowing anyone to build an extension and allowing arbitrary extensions to immediately inherit production liquidity and user flow. As a DEX operator, we want to understand what's running on our pools, have confidence it's been properly reviewed and tested, and retain the ability to respond if something behaves unexpectedly. Open innovation and production-grade controls don't have to be opposites."
THENA:
"Modularity is a huge advantage for us because it gives us much more room to innovate, from liquidity and execution to security and RWAs. The key difference is that plugins can't just be permissionlessly deployed on THENA. We decide what goes into production, so we get the flexibility without giving up control over what users interact with."
Hydrex:
"Modularity is one of the most essential aspects of DeFi, allowing us to build the 'Money Legos' that will ultimately operate the global financial systems. But it's very clear that modularity, coupled with permissionlessness, creates opportunities for rogue actors. Ultimately 3rd parties must come in and help determine what's a good vs bad use of the open environment. Hydrex, via Algebra plugins, leapfrogs this concern – we're able to provide the modularity of hooks, while pre-vetting the code that goes in front of our users, routers, and aggregators."
QuickSwap:
"We utilize Algebra's modular infrastructure and believe protocols should retain control over which plugins and extensions reach users, with rigorous review, testing, and clear security expectations before anything is enabled. Innovation should expand what DeFi can do without compromising the security and trust users place in the protocol. This is critical for the industry to grow and reach greater adoption."
The pattern across every one of these teams: modularity + a trust layer, not modularity vs safety. Algebra implements this at the point of deployment with governance over what reaches production; Uniswap’s hooklist, the routing allowlist, and 0x’s own vetting layer, addresses the same problem at a different point in the stack.
How Governed Plugins Change the AMM Security Model
Algebra Integral was designed around a separation between the AMM Core and the functionality built around it.
The Core handles the fundamental pool and liquidity logic. Plugins extend that core through defined callback points, adding functionality such as dynamic fees, incentives, specialized execution logic, RWA mechanics, or security controls. This approach has already been tested by dozens of DEXs – Algebra ranks 9th across all forks & 2nd across AMM models.
Integral answers the same "who's accountable for what runs on a pool" question differently: instead of a registry that vets after deployment, it restricts who can attach a plugin to a live pool in the first place – only the DEX operator/DAO via AlgebraFactory's POOLS_ADMINISTRATOR role can call setPlugin, and only one plugin runs per pool at a time.
The genuine structural advantage: capping each pool at exactly one active plugin mechanically reduces cross-extension state-interference risk (multiple pieces of external logic touching the same pool state) – a real, governance-independent benefit versus letting arbitrarily many hooks compose.
That creates a distinction we think matters:
Anyone can build.
The protocol decides what it is willing to run in production.
Instead of relying only on a registry that vets extensions after deployment, Algebra can place a governance checkpoint before new logic reaches a live pool.
What governance does is make the trust boundary more explicit and actionable.
Before deploying a plugin, a DEX can ask:
- Who built it?
- Has the code been reviewed and audited?
- What capabilities does it have?
- Which version is being deployed?
- Who can replace or upgrade it?
- How will its behavior be monitored?
- What happens if something behaves unexpectedly?
Bottom Line
The real story isn't "hooks were a mistake." It's that modularity evolved faster than the trust infrastructure around it, and the industry – aggregators, registries, auditors, and governed-plugin DEXs alike – is now actively catching up. There's no comparable public census of malicious plugins across Algebra, Balancer, or Ekubo the way 0x built for Uniswap v4, so the absence of a known incident on those platforms is evidence of less scrutiny, not proven greater safety. What's genuinely established: permissionless extensibility needs some trust layer, and every serious team in this space – regardless of which governance model they picked – is actively building one.
