Uniswap V4
Stage 1Risk Assessment
Uniswap V4 Risk Assessment
Overview
Uniswap V4 launched on January 30, 2025, introducing a revolutionary “hooks” system that allows developers to customize pool behavior through external contracts. While the core protocol remains immutable, hooks introduce new trust assumptions and risks that vary by pool.
V4 represents a shift toward modular, customizable AMM functionality with the singleton contract pattern reducing gas costs by up to 99% compared to V3. The protocol has achieved $100B+ in cumulative volume and over $700M in TVL within its first year.
Smart Contract Risk
Contract Architecture:
- Core “singleton” contract is immutable (no upgrade mechanisms)
- Singleton manages all pools in a single contract for gas efficiency
- Hooks are external contracts that can customize pool behavior
- Hooks may be upgradeable, centrally controlled, or have privileged roles
- Flash accounting system for efficient multi-hop swaps
- Native ETH support
Code Quality:
- Underwent 9 independent audits (most audited Uniswap version)
- $2.35M security competition with 500+ participants
- $15.5M bug bounty (largest in DeFi history)
- Codebase frozen at v0.5.6 for final security hardening
- Open source and extensively reviewed
Attack Surface:
- Core protocol has minimal attack surface (immutable)
- Hooks introduce variable risk - each hook is a separate contract
- Hook risks include: reentrancy, oracle manipulation, admin access, upgradeability
- Users must evaluate each pool’s hook individually
- Malicious hooks could steal funds, manipulate prices, or censor users
- Flash accounting adds complexity but has been thoroughly audited
Admin/Governance Risk
Governance Structure:
- UNI token holders control governance
- DUNA framework adopted (legal recognition for DAO)
- Governance can activate protocol fees
- Cannot modify core singleton contract
- Cannot access funds in the core protocol
- Hooks may have independent governance/admin controls
Key Controls:
- Core protocol: no pause, no emergency withdrawal, no upgrade
- Individual hooks: may have pause, upgrade, or admin functions
- Protocol fee activation possible through governance
- Hook permissions set during pool creation (immutable per pool)
Trust Assumptions:
- Core protocol requires no trust
- Each pool’s risk depends entirely on its hook implementation
- Hook admin keys could be EOA, multisig, or governance-controlled
- Hooks could be upgradeable with instant or timelock delays
- Hook code must be reviewed separately for each pool
Oracle Risk
TWAP Oracle:
- Improved TWAP oracle inherited from V3
- Self-contained within pool contracts
- More capital-efficient observations than V3
- No external dependencies for core oracle
- Hooks could introduce external oracle dependencies
Oracle Security:
- Core oracle maintains V3 security properties
- Manipulation cost scales with liquidity
- Flash loan resistant for TWAP calculations
- Custom hooks may add oracle risk (Chainlink, Pyth, etc.)
Economic Risk
Liquidity Risk:
- $700M+ TVL across 10+ chains
- Rapid growth since January 2025 launch
- Over 150 hooks deployed by community
- 5,000+ hooks initialized
- Liquidity fragmented across different hook implementations
Operational History:
- Launched January 30, 2025
- $100B+ cumulative volume in first year
- Zero exploits of core singleton contract
- Hook-specific incidents may occur (requires monitoring)
- Significant improvement in gas efficiency driving adoption
Hook Ecosystem Risks:
- Hook quality varies significantly
- Some hooks may be experimental or unaudited
- Users must verify hook code before using pools
- Rug pull risk from malicious hook developers
- Centralization risk if hooks have admin keys
Stage Assessment
Stage 1 Criteria Met: ✓ Immutable core contract (singleton) ✓ Governance with DUNA framework ✓ Extensive audits (9 audits + $2.35M competition + $15.5M bounty) ✓ Self-contained core oracle ⚠ Fund access possible through malicious hooks
Why Not Stage 2: ✗ Hooks can be upgradeable (varies by implementation) ✗ Hooks may have centralized admin control ✗ Hooks could access user funds in pools ✗ Limited track record (1 year since launch) ✗ Hook security depends on individual developers
Why Not Stage 0: ✓ Core protocol is immutable and trustless ✓ Hook risks are opt-in (users choose which pools to use) ✓ Extensive security measures and audits ✓ Governance has limited scope over core protocol
Justification: Uniswap V4 achieves Stage 1 (Assisted) status due to the variable trust assumptions introduced by the hooks system. While the core singleton contract is immutable and trustless (Stage 2 quality), the protocol’s defining feature—customizable hooks—introduces risks that depend entirely on each hook’s implementation.
Hooks may be:
- Upgradeable (instant or timelocked)
- Admin-controlled (EOA, multisig, or governance)
- Capable of accessing funds in their pools
- Unaudited or experimental
Users must evaluate each pool independently, treating it as a separate protocol with its own risk profile. The core protocol achieves Stage 2 standards, but the ecosystem as a whole requires assisted trust due to hook variability.
As the ecosystem matures and best practices emerge (standardized hook audits, hook registries, reputation systems), individual pools using well-audited, immutable hooks could be evaluated separately for Stage 2 classification.