[RFC] Hook Manager Framework – On-Chain Policy Orchestration for Uniswap v4

  • Initial Request for Comment. No Governance action required at this time.

Motivation

Uniswap Protocol v4 arrived with a bang—ushering in unprecedented flexibility via hooks, singleton architecture, and flash accounting. It’s a powerful toolkit, opening doors not just for optimized token swaps, but for a universe of on-chain value exchange: complex financial products, Real-World Assets (RWAs), and institutional-grade DeFi.

But with great power comes great complexity.

How do we safely harness v4’s power for sophisticated use cases? How do we implement custom logic—compliance checks, pricing rules, risk controls—without creating a fragmented, unauditable mess of ad-hoc hooks?

This RFC introduces a proposed solution: On-Chain Policy Orchestration Architecture, centered around a new infrastructure layer called the Hook Manager Framework.


:puzzle_piece: The Problem: Raw Power Needs Structure

Imagine building a skyscraper out of LEGO—with no baseplate and no instructions. That’s what raw v4 hook usage feels like when attempting to support RWAs or institutional-grade logic.

While every v4 hook executes atomically (a big leap over off-chain enforcement!), relying solely on ad-hoc, monolithic hook contracts leads to:

  • Fragmentation – Different pools implement similar logic differently.

  • Duplication – Developers continually reinvent the wheel.

  • Security Risk – Larger, multi-purpose hook contracts are harder to audit.

  • Trust Gaps – DAOs and institutions cannot reliably verify or rely on arbitrary hooks deployed permissionlessly.

There’s a need for structure—one that preserves Uniswap’s neutrality while enabling robust pool-specific behavior.


:hammer_and_wrench: The Solution: The Hook Manager Framework

The Hook Manager is a governance-aware orchestration layer attached to Uniswap v4 pools. It coordinates which policy-specific hooks execute, in what order, and under what conditions.

Key Features:

  • Modular Policy Hooks
    Each custom behavior is implemented as a dedicated, single-purpose contract—e.g.,

    • KYC/AML enforcement

    • Dynamic fees

    • MEV protection

    • RWA settlement logic

  • Orchestration Logic
    The Hook Manager attaches at pool creation and manages:

    • Which hooks execute on specific pool operations (before/after swap, mint, burn, etc.)

    • Execution order of hooks

    • Dynamic registration/deregistration (via governance)

  • Standard Interfaces
    Hook contracts conform to a unified spec, making them easier to audit, monitor, and potentially reuse.

  • Controlled Upgrades
    Through a decentralized governance model (proposed: using UNI), policy hooks can be upgraded while pools are paused—no liquidity migration required.

  • Transparency & Observability
    Hooks and managers emit standardized on-chain events for analytics, compliance audits, and real-time monitoring.

Importantly, the Hook Manager does not modify Uniswap v4 core contracts—it builds on top of them, preserving neutrality and permissionlessness.


:white_check_mark: Why This Matters

This isn’t just a better way to manage hooks—it’s a foundational leap forward for Uniswap v4’s real-world adoption, introducing a scalable, modular, governance-aligned framework to extend Uniswap v4’s hook system into a generalized infrastructure for policy-governed liquidity pools.

:locked_with_key: Enhanced Security

  • Modularity enables smaller, auditable hook contracts

  • Bugs are isolated; the blast radius of errors is reduced

:bank: Institutional Readiness

  • Enables auditable KYC/AML enforcement, risk controls, escrow logic, etc.

  • Makes Uniswap pools usable by custodians, banks, and DAOs with specific mandates

:rocket: Developer Efficiency

  • Clear interfaces and modular design reduce complexity, accelerate innovation, and improve testing workflows

:balance_scale: Regulatory Adaptability

  • Need to add a new compliance rule? Deploy a new policy hook without touching other logic

:1st_place_medal: Competitive Agility

  • New features can be rapidly deployed via standalone hooks (e.g., slippage protections, dynamic pricing models)

:balance_scale: Addressing Trade-offs

:fuel_pump: Gas Costs

Yes—each policy hook adds gas. But:

  • For large trades (institutions, RWAs), the cost is trivial compared to the value of guarantees

  • L2 deployments will greatly reduce overhead

  • Selective policy exemption and optimization techniques are possible

:droplet: Liquidity Fragmentation

The framework leads to more pools—but fragmentation already exists across fee tiers, versions, and L2s.

  • Aggregators (e.g., 1inch) and smart routers already solve this

  • For policy-sensitive users, verifiability > slippage
    Fit-for-purpose liquidity is the goal—not maximum depth

:person_shrugging: Why Not Use Frontends or Raw Hooks?

  • Frontend rules are easily bypassed

  • Raw hooks lack auditability, standardization, and trust guarantees

  • The Hook Manager introduces curation, policy discovery, and on-chain enforcement—all composable and transparent


:classical_building: Governance & Ecosystem Design

:ballot_box_with_ballot: Decentralized Governance (Proposed)

  • Governance over Hook Managers and registered hooks scoped via UNI token

  • Tiered voting – technical changes weighted toward developers; UX-impacting changes weighted toward users

  • Roles:

    • Hook Developers – permissionless contract authors

    • Curators – recommend and audit hooks for specific verticals (e.g., RWA, stablecoins, MEV)

:money_bag: Licensing & Monetization

  • Business Source License (BSL) for core components, with a permissive license transition after 1 year

  • Commercial Licensing for enterprise usage (e.g., banks, custodians)

  • Shared Deployment Costs among institutions using the same policy set

  • Rebates/Credits for LPs who help bootstrap policy-enabled pools

This model aligns incentives while supporting open experimentation.


:globe_showing_europe_africa: Vision: Beyond Token Swaps

The Hook Manager Framework helps Uniswap v4 evolve from “flexible DEX” into a universal value exchange substrate.

It provides the structure needed to support:

  • Institutional finance

  • Real-world asset settlement

  • Verticalized DeFi use cases

  • Cross-protocol integrations

  • Composable compliance

All without compromising core Uniswap principles of neutrality, modularity, and permissionless innovation.


:speaking_head: Feedback Requested

We invite community feedback on the following:

  • Is the Hook Manager framework directionally aligned with Uniswap v4’s architecture and goals?

  • Are the trade-offs (e.g., gas, fragmentation) acceptable for the benefits?

  • Does the governance model appropriately balance decentralization and practical execution?

  • Are there any blockers, risks, or implementation pitfalls that deserve more attention?


:paperclip: Resources


Author: Mohamed ElBendary
Status: RFC (Request for Comment)
Date: May 2 2025


2 Likes

As a protocol integrating v4 Hooks, fragmentation is a key issue for us. We love what v4 builders do, but are severly bottlenecked in which pools we can integrate due to the overgrowth of custom logic.

Some context: Arcadia is the biggest ALM on Base with $11m TVL, providing management of clAMM pools through self-custodial EOAs. We’re working with L1.co’s biggest asset managers to onboard offchain capital to DeFi.

Currently, most production-ready v4 Hook protocols would require us to do dedicated smart contract work and audits for an integration. It’s basically the same work as integrating a whole new DEX.

A framework to standardize v4 Hooks would drastically increase our capacity to integrate new pools, translating into more exposure for these pools to our users.

Hi @mbendary, We wanted to drop a quick comment to thank you for posting this idea. You have identified a valuable problem and suggested a thoughtful solution.

We’ll follow up once we have had a chance to consider the idea more!

This is exactly the kind of context that makes the pain point real—thank you for surfacing it.

The framework aims to streamline the discoverability of relevant, trusted hook contracts and reduce the DEX-level integration burden. It does this by enabling composable policy logic, shared coordination layers, and modular governance—without requiring duplicative work across similar-profile pools.

Would welcome any feedback as you explore whether this might help Arcadia scale deeper into v4’s design space.

Thanks again for engaging so constructively—it’s a huge boost to see validation from a team actively operating at the edge of what v4 enables.

1 Like

Hi @GFXlabs team, I appreciate you taking the time to acknowledge the proposal and signal interest—thank you.

I’d welcome any feedback once you’ve had a chance to consider it more deeply—especially around how the proposed framework and curation surfaces might align (or not) with the broader governance priorities you’re thinking through. I believe scaling DeFi beyond native crypto depends on solving how v4 hooks are composed, coordinated, and governed.

Happy to go deeper or walk through specific design choices if helpful. Appreciate the thoughtful presence the GFX team brings to the ecosystem.

1 Like

Hey Mohamed, thank you so much for this thoughtful proposal addressing hook development structure in v4. We appreciate the clear identification of challenges around standardization, security, and institutional adoption. As we at the Uniswap Foundation have also been considering how to best ensure the success and growth of Uniswap v4, we wanted to provide some feedback to some of your questions at the end of the post.

Is the Hook Manager framework directionally aligned with Uniswap v4’s architecture and goals?

The challenges you’ve identified are important to address. We believe a governance-managed orchestration layer may not fully align with v4’s architectural philosophy of permissionless innovation. Instead, we see these challenges being addressed by a decentralized ecosystem of builders and participants, competing for the best solutions.

We’re actively working on initiatives that address these same challenges through a decentralized approach:

  1. Security: The Uniswap Foundation Security Fund supports teams building with v4 with their hook audits. This program is a part of a grant from the UF to Areta who facilitate an auditor marketplace for hook teams.
  2. Institutional Readiness: While not live yet, we are excited to share a grant around institutional hooks in the coming weeks, alongside a white paper of strong use cases.
  3. Developer Efficiency: The Uniswap Hook Incubator focuses on growing a diverse and decentralized developer ecosystem in a competitive environment. We have seen really strong teams, like Cork and Tenor Finance, emerge from the UHI.
  4. Adaptability: While upgradeability sounds beneficial, we believe immutability is a core strength, not a limitation.

Looking Forward

We’re excited to see forum discussion about v4’s future through your proposal. Thank you again for kickstarting this conversation. We’d welcome further discussion on:

  • Achieving standardization without centralized coordination
  • Specific institutional requirements needing better documentation
  • Supporting developers in creating secure, reusable hooks without constraining innovation

Hey Porter and UF Team,

Thank you for your thoughtful response to the Hook Manager Framework proposal. I appreciate your recognition of v4 adoption challenges and your commitment to addressing them. After reflecting on your feedback, I’d like to clarify aspects of the proposal and demonstrate its fundamental alignment with Uniswap’s core principles of permissionless innovation.

TL;DR:

  • The Hook Manager Framework (HMF) as an Opt-In Toolkit, Not Central Control: HMF is an optional developer toolkit enabling self-organized permissionlessness for complex use cases. It neither restricts raw v4 hook development nor imposes top-down governance.
  • Addressing Real, Documented Problems: The framework tackles current, evidenced issues of hook fragmentation, security vulnerabilities (e.g., “36% vulnerable” per BlockSec research), and integration bottlenecks impacting builders like Arcadia and institutional onboarding.
  • Aligns with UF’s Signaled Values: The UF’s endorsement of community curation (e.g., “awesome-uniswap-hooks”) shows a shared goal for an organized ecosystem. HMF offers a robust, on-chain mechanism for opt-in achievement.
  • Strategic Imperative for Uniswap v4: Given the competitive landscape (e.g. PancakeSwap Infinity to Uniswap v4 parity) and Uniswap v4’s BSL, HMF provides crucial systemic capabilities to build a stronger, differentiated ecosystem and maintain leadership.
  • Adaptability & Immutability Balanced: HMF respects core protocol immutability while offering controlled, opt-in adaptability for policy layers—vital for global compliance, RWA needs, preventing fragmentation, and reducing fork incentives.
  • Open to Community-Driven Implementation: The proposal’s licensing/monetization details were illustrative; HMF is a public good for long-term ecosystem health, not a business venture. Implementation is open to community-aligned models.

A Public Good for Ecosystem Health, Not a Business Venture

Before delving deeper, I want to address potential misinterpretations regarding licensing. The Hook Manager Framework’s primary goal is ecosystem health and enablement; it is envisioned as a public good for the Uniswap community.

The original whitepaper’s licensing and monetization details are illustrative of sustainability paths, not a rigid business venture. The framework can be implemented under various community-aligned models: as a fully open-source component, through Foundation grants, or via a DAO-governed structure. The suggested BSL approach with eventual open-sourcing mirrors Uniswap v4 itself, ensuring ecosystem benefit with reasonable initial protections. I am committed to finding an implementation path serving Uniswap’s values and governance preferences.

Addressing Market Realities & Evidence of Problem Severity

The need for a more structured hook integration approach isn’t merely theoretical. As Arcadia Finance noted in their response to this RFC:

“As a protocol integrating v4 Hooks, fragmentation is a key issue for us…severely bottlenecked…due to the overgrowth of custom logic… most production-ready v4 Hook protocols would require us to do dedicated smart contract work and audits for an integration. It’s basically the same work as integrating a whole new DEX.”

This feedback from a protocol “working with L1.co’s biggest asset managers to onboard off-chain capital to DeFi” highlights significant existing integration barriers. For institutions and asset managers, particularly those Arcadia helps onboard, a standardized policy-aware pool framework is a prerequisite for confident engagement.

The “awesome-uniswap-hooks” github repository (ora-io/awesome-uniswap-hooks), a community-maintained resource, details hook security vulnerabilities. Crucially, research highlighted there (by BlockSec) shows “36% of the hooks in this repository in one specific commit hash may be vulnerable to attacks.” This repository also catalogues dozens of specialized hook implementations—from oracle integration to compliance systems to cross-chain functionality. Such rapid, unstandardized proliferation exemplifies the fragmentation challenge HMF addresses. The community’s focus on educational resources and security best practices demonstrates recognition of complexity that standardized interfaces and curation could mitigate.

Further widespread challenges include:

  • Proliferation of Incompatible Hooks: Over 150 developed hooks (per Uniswap’s Jan 2025 blog) create a complex integration landscape.

  • Institutional Integration Complexity: The Uniswap Labs/Fireblocks collaboration highlighted integration challenges HMF would directly address.

  • Acknowledged Hook Risks by Uniswap Labs: Uniswap Labs officially cautions users about third-party hooks, underscoring the need for solutions aiding standardization and trust.

This is not an isolated concern. Extensive community-documented security issues underscore the urgency for strategic solutions. The HMF proposal provides a foundational step, and we anticipate it will be complemented by other community-driven innovations.

Permissionless Innovation Enhanced: Enabling Self-Organized Permissionlessness at Scale

The Hook Manager Framework is an opt-in toolkit augmenting v4’s permissionless foundation, enabling self-organized permissionlessness, not replacing core freedom:

  1. Parallel Paths Preserved: Developers remain free to build directly against v4 core; HMF offers optional structure, similar to how OpenZeppelin contracts empower developers without restricting them.

  2. Developer-Driven Standards: Implementations emerge organically through developer adoption: similar to how npm packages become standards through utility, not mandate.

  3. Competitive Framework Marketplace: The proposal envisions multiple Hook Manager implementations competing in an open marketplace, each with potentially different features, governance models, and focus areas—the very definition of permissionless competition.

The framework aims to reduce the coordination costs that inherently limit permissionless growth in complex systems, thereby preserving and even amplifying the innovation freedom that makes Uniswap powerful.

Why Now? Timing Considerations for Systemic Capabilities

Some suggest it’s too early for structure. However, this early stage is precisely why a framework offering systemic capabilities for coordination and composability is timely:

  1. Standards are more effective early: Lightweight standardization now prevents incompatible approaches from becoming entrenched, avoiding costly retroactive fixes later, or being cornered into sub-optimal choices. The longer we wait, the more costly coordination becomes.

  2. Existing Integration Bottlenecks: Evidenced integration challenges due to fragmentation are already constraining growth today.

  3. Competitive Window: PancakeSwap Infinity’s release (GPL 2.0) with v4 feature parity underscores Uniswap’s window to establish deeper, differentiated ecosystem advantages. Uniswap v4 BSL expires in June 2027. Uniswap’s sustainable leadership will depend on fostering superior developer experience, composability, and ecosystem cohesion. Addressing structural challenges now prevents ceding ground to competitors who might create more builder-friendly environments.

Retroactively imposing structure is significantly harder. HMF provides just enough structure for cohesion to address scaling challenges without restricting innovation. It also provides a strong foundation for enduring competitiveness beyond protocol primitives through a thriving, composable, and efficient ecosystem.

Global Compliance Reality: Building for Uniswap’s Actual User Base

Given that 90% of Uniswap users are based outside the U.S. (per Hayden Adams, Nov 2024), and with diverse global crypto regulations emerging (e.g., MENA), adaptable compliance is crucial. HMF provides the necessary systemic capabilities for pools to implement jurisdiction-specific compliance. Supporting global participation requires localized, adaptable policy enforcement. HMF allows DAOs and institutions to build and manage these solutions without fragmenting Uniswap’s core or incentivizing forks. Crucially, this enhances agility at the ecosystem level, which is essential for Uniswap’s continued global growth.

Immutability and Adaptability: A Nuanced Balance

We respect immutability as the cornerstone preventing protocol stewards from creating walled gardens. The proposal has been misinterpreted as challenging this principle. In fact, it carefully preserves it while enabling controlled adaptability for opt-in policy layers:

  1. Core Protocol Immutability Preserved: HMF maintains Uniswap v4 core contract immutability and v4 hook attachment semantics.

  2. Scoped and Governed Pausing: Pausing applies only to pools opt-in to a specific Hook Manager and requires governance by that scope—preserving broader protocol immutability.

  3. Protected Policy Evolution: When regulatory requirements change, opted-in policy hooks can adapt without requiring liquidity migration from those specific pools or protocol.

This nuanced approach recognizes that while immutability is invaluable for core logic, its universal application to dynamic policy enforcement can be a practical limitation, unnecessarily lowering the ceiling for ecosystem growth.

Market Selection with Purpose

Market forces drive adoption. However, they operate most efficiently within some structural baseline. HMF enhances market selection, by preserving competition on innovation while removing unnecessary integration friction:

  • By lowering integration barriers, the Hook Manager ensures a level playing field where developers compete on functionality, security, and value—accelerating adoption and expanding Uniswap’s composable ecosystem.

  • It accelerates organic standardization, reducing economic inefficiency, akin to Web3 token standards or oracle interfaces. HMF is a minimal coordination layer, much like standardized shipping containers revolutionized trade by making the process efficient, not dictating the cargo.

Interestingly, the Uniswap Foundation has implicitly acknowledged the value of such organization. The “awesome-uniswap-hooks” repository notes: “Special thanks to Uniswap Foundation for including this resource in the official doc and mentioning this work in the blog!” This Foundation-endorsed community curation serves HMF’s fundamental purpose: organization, standardization, and quality guidance. HMF proposes formalizing and strengthening this with opt-in robust on-chain mechanisms, not just off-chain curation. This alignment suggests a shared goal for an organized, accessible hook ecosystem; we propose a more comprehensive technical implementation of what the Foundation already supports in principle.

Aligning with and Amplifying Foundation Initiatives

The Hook Manager Framework is designed not to compete with, but to synergize with and amplify the impact of the Uniswap Foundation’s valuable initiatives:

  1. Security Fund Enhancement: HMF promotes modular, single-purpose hooks adhering to the Single Responsibility Principle. Such hooks are inherently more cost-effective to audit, thereby multiplying the impact of the UF Security Fund and Areta’s marketplace by allowing resources to cover more ground or deeper analyses.

  2. Institutional Hook Development: As the Foundation explores institutional hooks and use cases, HMF offers a robust, opt-in technical foundation and standardized patterns for their on-chain implementation. This provides the prerequisite structure for confident engagement by institutions requiring auditable and governable policy enforcement.

  3. Hook Incubator Acceleration: For innovative teams emerging from the Hook Incubator, such as Cork and Tenor Finance, HMF can serve as an optional accelerator. By providing battle-tested patterns for orchestration and policy management, it allows these teams to focus on their unique value propositions rather than expending resources on rebuilding foundational infrastructure.

Moving Forward: A Developer Toolkit, Not a Governance Layer

The Hook Manager Framework is fundamentally aligned with the Foundation’s goals for Uniswap v4: scaling permissionless innovation, strengthening ecosystem composability, and supporting sustainable growth. To bring clarity to the alignment with the Foundation’s vision for the ecosystem, I reframe the Hook Manager as:

  1. A Developer Toolkit: Simplifying complex orchestration, reducing duplication, enabling developers to focus on unique value, fostering self-organized permissionlessness.

  2. A Building Block for DAOs: Enabling DAOs to implement and govern their own policy enforcement without protocol-level changes.

  3. An Ecosystem Protection Mechanism: Standardized interfaces reduce fork incentives, enrich the ecosystem with differentiated systemic capabilities, preserving Uniswap’s network effects and long-term growth.

To further these goals collaboratively, I would welcome the opportunity to:

  1. Explore how modular HMF components could directly support and enhance your initiatives without requiring wholesale adoption.

  2. I am particularly keen on identifying targeted institutional requirements where standardized interfaces would unlock more innovation, providing the prerequisite for confident engagement. I look forward to your upcoming whitepaper and am happy to serve as a reviewer.

  3. Develop a simplified version focused on developer tooling aligned with your current approach.

Thank you for engaging with this proposal. It is a privilege to be part of the Uniswap community. I remain committed to Uniswap’s success and finding solutions balancing permissionless innovation with the maturing ecosystem’s practical needs.