Uniswap V4

Protocol identification

• Name: Uniswap v4.
• Category: Decentralized exchange (DEX) / automated market maker (AMM) with programmable liquidity via hooks.
• Website: Uniswap main site and v4 launch blog ("Uniswap v4 is Here – A New Era of DeFi") — *unverified marketing claim* for exact URL.
• Docs: Uniswap v4 developer docs, including "Hooks" and "Security" sections — *unverified marketing claim* for exact URL.
• Launch date: v4 went live on mainnet on 31 January 2025. Some educational content ambiguously references “launched on June 12, 2023” for the code announcement, but production mainnet deployment is consistently January 2025.
• Chains: Official blog states v4 is live on Ethereum, Polygon, Arbitrum, OP Mainnet, Base, BNB Chain, Blast, World Chain, Avalanche, Zora. Your focus set (Ethereum, Arbitrum, Avalanche, Base, OP Mainnet, Polygon, Monad) matches most of these, but Monad support is Not verifiable as of 2026-08-29.
• Native token: Uses the existing UNI governance token of the Uniswap ecosystem (inferred from overall protocol history; not restated explicitly in v4-specific sources) — this is an inference, not a v4‑specific statement.
• Main contracts & explorer status:
• v4 introduces a singleton core contract (one central pool manager) plus external hook contracts per pool. Exact addresses per chain are Not verifiable as of 2026-08-29 under current constraints.
• Explorer “verified contract” status for these addresses is Not verifiable as of 2026-08-29. Fork lineage and design changes
• Is it a fork? v4 is the next iteration of the original Uniswap protocol; it is not presented as a fork of a different DEX. It rebuilds Uniswap as a singleton contract and adds hooks.
• Key changes vs upstream (v2/v3):
• Singleton architecture: all pools in one core contract, reducing gas and simplifying routing.
• Hooks: external contracts that execute custom logic before/after pool lifecycle events (init, swaps, liquidity changes, donations). This enables dynamic fees, MEV protection, limit orders, lending integrations, and other behaviors without altering core.
• Reported 15–25% gas reduction for swaps due to architectural changes. Audits and security review
• Uniswap v4 core and periphery have undergone extensive security reviews:
• Docs list audits by OpenZeppelin, Certora, Trail of Bits, Spearbit, ABDK, Pashov Audit Group for core and periphery, with dated reports in 2024.
• Trail of Bits published a v4 core security review finding 6 issues (1 low, 5 informational).
• Certora summarizes multiple audits and issues, including a low‑severity collectFees interaction bug.
• A $15.5M bug bounty, described as the largest in DeFi at the time, plus a $2.35M security competition with >500 participants, found no critical vulnerabilities. Malicious‑modification history in similar forks
• Public sources discussing v4 focus on hooks’ security risks and audit guidance, but do not document a history of malicious modifications in Uniswap v4 itself or named forks. Trail of Bits’ guidance on “building secure hooks” emphasizes potential attack vectors in third‑party hooks rather than core protocol compromise.
• Any systematic record of malicious Uniswap v4 forks or hook contracts is Not verifiable as of 2026-08-29.

Uniswap v4 appears to have a real, production-grade developer portal and documentation set rather than a thin landing page: the developer docs include v4 protocol overviews, SDK guides, deployments, an interactive API reference, and a subgraph endpoint listing. The ecosystem also points to a live app and the protocol being available on multiple chains, including Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, and others, which supports maturity beyond a static marketing site. App functionality looks mature on the integration side: the docs explicitly cover quoting, single-hop and multi-hop swapping, minting/fetching/collecting/modifying liquidity positions, creating pools, and pool data access. That said, live deposit/withdrawal UX was not independently verifiable in this pass, so it should be marked Not verifiable as of 2026-08-29. An open API does exist: Uniswap’s developer materials describe an interactive API reference and document a Subgraph API plus SDKs for v4 interactions. I did not find evidence of broken links, fake metrics, or obvious template-site signs in the surfaced material, but that absence is not independently confirmed by crawl-level testing, so it should also be treated as Not verifiable as of 2026-08-29.

Uniswap v4 has undergone multiple audits; OpenZeppelin is the primary security partner and has run 11 audits across core, periphery, and related components since June 2024. As of today, bytecode-match vs deployed contracts is Not verifiable as of 2026-08-30.

• Core audit (Uniswap/v4-core)
• Date / timeline: 2024-05-27 to 2024-06-21.
• Scope: v4 core AMM contracts in the Uniswap/v4-core repo at commit d5d4957 (Solidity/Yul).
• Findings: 24 issues total; 1 critical, 3 medium; remainder low/info.
• Fix status: OpenZeppelin reports 18 resolved, 2 partially resolved, others acknowledged; all critical and medium issues reported in the later partnership recap as resolved.
• Coverage vs deployed code: Report is explicitly tied to a specific git commit; on‑chain bytecode matching and deployment set across Ethereum, Arbitrum, Avalanche, Base, Monad, OP Mainnet, Polygon is Not verifiable as of 2026-08-30.
• Periphery & Universal Router audit (Uniswap/v4-periphery + universal router)
• Date: 2024-08-30 report publication.
• Scope: v4 periphery contracts (e.g., pool manager interactions, wrappers) at commit df47aa9, and Universal Router at commit 4ce107d.
• Findings: 38 issues total; 1 critical, 1 high, 2 medium, remainder low/info.
• Key critical: Fee-stealing vector via the _increase function in periphery/universal-router; later recap confirms it was fixed.
• Fix status: 25 resolved, 1 partially resolved, others acknowledged; OpenZeppelin’s 2024 partnership note states the critical and high issues from core and periphery/Universal Router audits were successfully resolved.
• Coverage vs deployed code: Audit is commit‑specific; whether current deployed periphery/router on each chain exactly matches audited commits is Not verifiable as of 2026-08-30.
• Aggregate OpenZeppelin stats across Uniswap v4 components
• Issues across 11 audits: 101 total: 4 critical, 7 high, 17 medium, 57 low, 17 notes.
• Resolution: OpenZeppelin states these were addressed prior to launch, but per‑issue, per‑chain verification on deployed bytecode is Not verifiable as of 2026-08-30. Other firms (Certora, Trail of Bits, Spearbit, ABDK, Pashov Audit Group) Uniswap Labs and Certora report nine independent audits across these firms, but individual reports, severities, and bytecode coverage for each are Not verifiable as of 2026-08-30 based on available summaries.

Yes — Uniswap v4 has an active bug bounty program. Uniswap Labs announced a $15.5 million bounty on 26 Nov 2024, and the Cantina bounty page shows the program is still active with the same $15.5 million pool.

Uniswap v4 mainly depends on external ERC‑20 tokens (incl. stablecoins/LSTs), price oracles inside LP pools, and bridges/CEXs only indirectly via user flows. All on‑chain dependency facts are Not verifiable as of [2026‑08‑29]. ### 1. External protocol & oracle manipulation risk

• Core design: Uniswap v4 introduces “hooks” that let external contracts customize pool behavior (dynamic fees, custom oracles, etc.). This increases composability *and* the chance that a malicious or buggy hook contract can manipulate pricing, fees, or liquidity routing for its pool.
• Price discovery still comes from AMM swaps, not Chainlink‑style external oracles. However, if v4 pools are used as price feeds by other protocols, thin liquidity or concentrated LPs can enable oracle manipulation attacks (flash loans, low‑liquidity pools). ### 2. Bridges & cross‑chain exposure
• Uniswap v4 is expected to be deployed across multiple L1s/L2s (Ethereum, Arbitrum, OP, Base, Polygon, Avalanche, Monad per your scope). Cross‑chain liquidity will be fragmented and may be coordinated via third‑party bridges or messaging layers (e.g., LayerZero, Wormhole) in ecosystem strategies, not in core protocol.
• Bridge failure, message spoofing, or chain reorgs can cause mispriced assets or synthetic tokens that still trade in v4 pools; LPs then bear loss when the bridged asset collapses or is frozen. ### 3. Custodians, CEX/MM counterparty risk
• Uniswap is non‑custodial; users control funds via their own wallets.
• CEXs and market‑makers are major liquidity providers in v3/v2; similar behavior is expected for v4. Their withdrawal or inventory stress (e.g., CEX insolvency) can trigger sudden liquidity gaps, wider spreads, and more slippage but not direct protocol insolvency. ### 4. Stablecoin, LST, restaking, RWA exposure
• v4 pools will hold USDC/USDT/DAI and other stables, LSTs (stETH, rETH, etc.), and possibly restaking tokens and RWAs issued via SPVs.
• Each of these carries asset‑specific counterparty risk:
• Stablecoins: depeg or issuer freeze → LPs and traders suffer inventory loss; pools may quote distorted FX between stables and ETH.
• LSTs/restaking: validator slashing, protocol bugs, governance attacks → LST price drop; concentrated LST pools become high‑beta exposure.
• RWA tokens: SPV/issuer default, regulatory action, NAV mis‑marking → token depeg from claimed underlying; AMM pools magnify price discovery of the stress. ### 5. Failure scenarios
• Hook contract exploit: attacker drains specific pools or redirects fees; systemic only if widely used hooks share vulnerabilities.
• Major stablecoin/LST depeg: large pools invert pricing; traders arb, LPs crystallize losses; could impact overall DeFi liquidity but not protocol solvency.
• Bridge/RWA issuer failure: bad assets remain tradable; LPs who hold them take losses; governance may later exclude or warn against certain tokens.

Uniswap v4 is non-custodial: users keep ownership of their assets and position NFTs, and the protocol is described as permissionless and non-upgradable. Core liquidity sits in a single PoolManager contract, with pool balances settled through flash accounting rather than separate pool contracts. For ordinary pools, custody is therefore organized by smart contracts, not by a central operator: users deposit into pools, trade through the protocol, and withdraw through permitted pool actions. For permissioned pools, custody adds a wrapper layer. A verified Permissions Adapter holds the underlying permissioned token and issues a virtual version that the pool trades; when assets leave, the virtual token is converted back to the original asset. Access is controlled by onchain allowlists, so only approved addresses can swap or provide liquidity, while disallowed addresses cannot gain exposure through multi-hop routes. The system is still described as non-custodial, because funds can leave only through swaps, position withdrawals, and claim redemptions, not through the virtual token directly. Liquidity position NFTs are minted directly to the user, and in the subscriber flow the user does not relinquish custody of the NFT; the reward contract only receives notifications, not the asset itself.

The v4 bug bounty is documented as up to $15.5M for critical issues, with tiered payouts for lower-severity findings; reports must be submitted promptly and kept confidential until resolution.

Uniswap v4’s key management is organized around a singleton PoolManager plus per-pool hook contracts. Instead of one contract per pool, all pools live in a single PoolManager, and each pool is identified by a PoolKey/PoolId derived from its token pair, fee, tick spacing, and hook address. Operational control is split across components: the PoolManager holds core pool state; hooks are separate deployed contracts that can run custom logic before or after swaps, liquidity changes, initialization, and donations; and the peripheral PositionManager handles LP position management. For security and execution control, v4 uses a lock/unlock pattern with transient storage. Pool actions must be performed while the PoolManager is unlocked, token deltas must net to zero by the end of the unlock flow, and this acts as a reentrancy-style safeguard for multi-step interactions. In short: pool state is centralized, custom behavior is modularized into hooks, and position/user interactions are handled by peripheral contracts rather than by separate pool contracts.

Uniswap v4 is not yet deployed to mainnet or live L2s as of the latest available information; it is in development following the draft v4 whitepaper (May 2023) and hook design iterations. All smart‑contract/admin risk below is therefore prospective/architectural, not on‑chain verified. Not verifiable as of 2026‑08‑29. ### Deployment status & addresses

• No canonical Uniswap v4 factory/router/pool contracts are confirmed on Ethereum, Arbitrum, Avalanche, Base, OP Mainnet, Polygon, or Monad.
• Any “Uniswap v4” contracts currently visible on explorers are likely test deployments, forks, or impersonators and cannot be treated as the official protocol. Name‑collision risk is high. ### Architecture (from v4 design docs)
• v4 introduces a single singleton pool contract plus hooks, replacing the separate pool contracts of v3.
• Pools are created via a factory; custom logic lives in external hook contracts that execute at well‑defined points (e.g., before/after swaps, liquidity changes).
• The design is intended to be minimally upgradeable at the core, with extensibility pushed to hooks rather than frequent core upgrades. ### Admin / owner / emergency roles Because mainnet contracts are not yet confirmed, the following items are not verifiable as of 2026‑08‑29:
• Actual owner/admin addresses per chain.
• Whether the core contracts use proxy patterns (Transparent/ UUPS/ Beacon) vs. immutable deployments.
• Proxy admin type, decoded admin‑change events, or governance contracts managing upgrades.
• Existence and parameters of timelocks, guardians, or pause roles.
• On‑chain evidence of role renunciation (e.g., owner set to address(0)). ### User exit & worst‑case key compromise
• Uniswap’s historical pattern (v2/v3) is to make pools non‑custodial: LP tokens and user assets stay under user control; exits do not require admin intervention.
• If v4 follows the same pattern, users should be able to withdraw liquidity and swap as long as contracts are live, regardless of governance decisions. This is an inference from prior versions, not v4 on‑chain data.
• Worst case for compromised keys depends on final implementation: risks could include
• Malicious upgrades if proxies are used.
• Fee‑parameter changes or exploitative hooks if governed by an admin.
• Pausing/swapping restrictions or listing of malicious hooks. ### Rug/freeze risk
• Without confirmed contracts, rug/freeze risk for the official Uniswap v4 deployment cannot be quantified.
• Any currently deployed “Uniswap v4” instance should be treated as high‑risk until addresses, governance, and upgradeability are officially documented and verified across explorers and audits. Not verifiable as of 2026‑08‑29 for all chain‑specific metrics (admin addresses, events, timelocks, and on‑chain diagrams).

Uniswap v4 is a protocol release, not a separate founding team; the operating company is Uniswap Labs, led publicly by Hayden Adams, who is described by Uniswap Labs as the creator of the Uniswap Protocol and by external profiles as founder/CEO. Uniswap Labs states it is headquartered in New York City; a U.S. House letter listed Adams at a New York mailing address, and third-party business profiles also place the company in New York, supporting that this is a real operating business rather than just a web front. Adams’ pre-Uniswap background is publicly described as engineering work at Siemens and related roles, while other team members are publicly listed in third-party org charts, so this is not an anonymous team. I did not verify any offshore structure, and I cannot confirm an onshore/offshore legal analysis beyond the U.S.-based public office/entity references. No on-chain verification was possible in this run, so claims about protocol scale or activity are not verified here; the key reality check is that the protocol has a visible corporate operator, public leadership, and a U.S. presence, not a purely anonymous shell.

Uniswap v4 has a generally strong security reputation for a major DeFi protocol: it was reviewed by multiple independent firms, with Trail of Bits reporting 6 issues (1 low, 5 informational) and Uniswap stating nine audits, a $2.35M security competition, and a $15.5M bug bounty with no critical bugs found. The main reputational positives are the depth of review and the long-running brand of Uniswap Labs/founder Hayden Adams; public reporting also says the 2023 securities class action against Uniswap Labs, the Uniswap Foundation, Adams, and VC investors was dismissed, which reduced a major fraud/securities overhang. At the same time, the protocol and affiliated entities have faced real regulatory pressure: the CFTC issued an order against Uniswap Labs in 2024, and the SEC investigation was reported closed in 2025 without enforcement action. Sanctions-related risk remains operational rather than protocol-level, because Uniswap’s interface policy blocks sanctioned persons/addresses and certain jurisdictions. The biggest unresolved concern is legal/regulatory concentration around the Labs/interface layer rather than the smart contracts themselves; no credible evidence in the gathered sources indicates a rug pull or insolvency allegation specific to Uniswap v4. Some investor-tokenomics commentary exists, but it is not directly about v4 protocol solvency and should be treated cautiously.

Uniswap v4 is a non-custodial AMM framework; it does not itself define a single yield product, but enables pools whose economics depend on the specific hook logic and fee settings chosen by LPs and pool creators. All statements below are based on web sources; on-chain verification via Dune is Not verifiable as of 2026-08-29. Strategy & assets in/out Uniswap v4 continues the core v2/v3 AMM model: users deposit pairs of assets into liquidity pools and earn trading fees pro-rata to their liquidity share. Liquidity is strictly non-custodial and can be added/removed at any time absent external hook constraints. Yield sources: organic vs subsidized Primary yield is organic trading fees paid by takers; Uniswap governance does not guarantee protocol-native emissions for v4 LPs. Individual hooks can add subsidized components (e.g., external reward tokens, points programs) but these are external to the base protocol and depend on the hook deployer. Market-neutral vs directional; leverage/external exposure Base AMM positions are directional: LPs bear price risk and impermanent loss relative to holding the assets. Hooks can introduce leverage, dynamic rebalancing, or external DeFi interactions (e.g., lending, restaking), turning pools into more complex structured products. These behaviors are strategy-specific and not uniform across v4. Lock-ups & withdrawal mechanics Uniswap v4 as designed does not enforce global lock-ups; LPs withdraw by burning liquidity tokens or closing positions in the pool contract. Hooks may implement time locks, exit fees, or gating, but that is pool-level logic rather than protocol-wide. Fees, gates, limits Each pool can set a custom fee tier, potentially dynamic via hooks (e.g., higher fees in volatile periods). Protocol-wide fee switches (like v3’s governance fee) may be extended to v4, directing a portion of pool fees to the treasury when activated; this is a governance parameter, not a hard-coded revenue stream. Protocol revenue Uniswap’s historical revenue stems from enabled fee switches and interface fees, not guaranteed across all pools. For v4, protocol revenue will depend on whether governance activates fee switches on specific pools and on any front-end or hook-level charges. Collateral & risk LP positions are collateralized only by the assets supplied; there is no protocol-level rehypothecation. Any lending, leverage, or restaking is hook-specific and introduces external protocol risk (smart contract, liquidation, oracle), which must be assessed per pool. TVL, chain split, APY history Dedicated v4 deployment and TVL across Arbitrum, Avalanche, Base, Ethereum, Monad, OP Mainnet, Polygon are Not verifiable as of 2026-08-29. Correspondingly, APY history, volatility, and sustainability for v4-specific pools are Not verifiable as of 2026-08-29. DeFiLlama comparisons vs on-chain Dune data for v4 are Not verifiable as of 2026-08-29. Key implication for an institutional risk lens Uniswap v4 is a framework: economic model, risk profile, and yield quality are pool- and hook-specific. Each product built on v4 requires its own risk, fee, and revenue analysis beyond the baseline AMM mechanics.

Not verifiable as of 2026-08-29. No on-chain reserve/treasury balances, custody addresses, controller permissions, composition, or attestations could be confirmed here because raw-chain verification was unavailable. The only verified facts found are that Uniswap v4 is deployed on Ethereum, Arbitrum, Avalanche, Base, OP Mainnet, Polygon, and Monad, and that Uniswap’s developer docs expose a ReservesLens contract among per-chain deployment addresses. That is not enough to determine treasury size, custody, or reserve policy, and any protocol-site-only treasury claim would be unverified marketing claim.

Uniswap v4 uses the existing Uniswap (UNI) token; no new v4‑specific token exists as of 2026‑08‑29. All tokenomics below are for UNI, not chain‑specific variants. On‑chain verification is not possible here: Not verifiable as of 2026‑08‑29. Native token / contracts

• Name/ticker: Uniswap (UNI).
• Main contract (Ethereum): 0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984.
• UNI is an ERC‑20; it is bridged to Arbitrum, Optimism, Polygon, Base, Avalanche, etc., via canonical and third‑party bridges. Supply, market cap, FDV
• Max supply: 1,000,000,000 UNI fixed at genesis; no further minting in token contract.
• Circulating supply, market cap, FDV figures vary by date and data source; they rely on CEX/DEX pricing and are Not verifiable as of 2026‑08‑29 under the current tooling rule. Utility and governance role
• UNI is a governance token for Uniswap Protocol and Uniswap DAO, controlling parameters such as fee switches, treasury use, and deployments.
• Holders can submit and vote on proposals, delegate voting power, and participate in treasury allocation decisions. Revenue share / fee switch / staking
• The core v3/v4 protocol fee switch can redirect a portion of LP fees to the protocol if enabled by governance.
• Historically, most deployments have the fee switch off; proposals to turn it on (e.g., for specific pools) have been debated but with limited activation.
• UNI does not inherently entitle holders to automatic revenue share, buybacks, burns, or protocol staking rewards; any such mechanism requires explicit governance approval. Emissions & unlocks; allocations
• Initial allocation (2020 launch): roughly 60% to community, 21.51% team, 17.8% investors, 0.69% advisors, each with 1–4 year vesting and cliff schedules.
• Detailed vesting/unlock schedule was published at launch, but whether individual unlocks executed as planned on-chain is Not verifiable as of 2026‑08‑29. Holder concentration & controls
• Top holders include the Uniswap treasury, vesting contracts for team/investors, major exchanges, and bridge contracts.
• UNI token contract has no mint or blacklist functions; governance control is exercised through separate contracts (governance module and fee switch), not via token-level minting/blacklisting. DEX liquidity & listings
• UNI is one of the most liquid DeFi tokens, with deep liquidity on Uniswap (all major chains), Coinbase, Binance, and other CEXs.
• V4 itself is an upgraded DEX engine; it does not change UNI tokenomics but may affect future governance and fee decisions.

A Bitcoin break below $10,000 would likely be a severe *risk-off* shock for Uniswap v4 because it would pressure BTC-linked LP positions, reduce DEX trading activity, and increase the chance that volatile pools become depleted or rebalanced aggressively. Uniswap v4 itself is a non-custodial, permissionless AMM whose liquidity is concentrated by price ranges, so sharp market moves can push pools through active ranges and increase slippage or partial fills when liquidity is thin. For the listed chains—Arbitrum, Avalanche, Base, Ethereum, Monad, OP Mainnet, Polygon—the chain-by-chain exposure to BTC-denominated liquidity is Not verifiable as of 2026-08-29 because the provided sources do not include on-chain position data or TVL breakdowns by chain. What can be stated from the available sources:

• Uniswap v4 liquidity is range-based, and when price moves to a range boundary the pool can become depleted on one side, which can make execution worse in stressed markets.
• The protocol is described in its whitepaper as non-custodial, non-upgradeable, and permissionless, so the stress scenario is about market/liquidity behavior rather than protocol solvency.
• External market commentary explicitly contemplates BTC falling to $10,000 in a severe bear case, but those are analyst forecasts, not protocol data. Operationally, the main risk channels would be: lower fee generation from reduced volume, wider effective spreads in thinner pools, and more pronounced impermanent loss for LPs holding BTC-correlated pairs. Any stronger claim about which chain would be most affected is Not verifiable as of 2026-08-29.

Under a 20% depeg of the largest collateral, the protocol-level impact on Uniswap v4 is not verifiable as of 2026-08-29 from the available sources. The results provided describe Uniswap v4 architecture and security discussions, but they do not provide chain-by-chain collateral composition, exposure, or a quantifiable stress-loss model for Arbitrum, Avalanche, Base, Ethereum, Monad, OP Mainnet, or Polygon. What can be said is that Uniswap v4 uses a singleton architecture that centralizes pools in one contract, and Uniswap governance has discussed risk-bearing designs for v4 positions and borrowing/collateral mechanics in proposal threads. However, the governance threads are scenario estimates and proposal language, not on-chain exposure data, and they do not establish the largest collateral asset or the size of collateral that would be affected by a 20% price shock. Because Dune/on-chain verification is unavailable in this run, the largest-collateral depeg loss, liquidation cascade risk, and any TVL-at-risk by chain are Not verifiable as of 2026-08-29.

Uniswap v4 does not have a protocol-level top-counterparty insolvency backstop. Its core design is a singleton PoolManager with hooks and flash accounting, where each transaction must settle all deltas before it completes; if settlement does not occur, the transaction reverts rather than leaving a residual loss for the protocol. That means the expected loss path is usually not socialized by Uniswap v4 itself but borne by the insolvent counterparty’s direct obligation or by the user/external hook that introduced the exposure. For the listed chains (Arbitrum, Avalanche, Base, Ethereum, Monad, OP Mainnet, Polygon), the loss path is therefore generally chain-agnostic at the protocol level: the affected pool’s transaction either settles successfully or reverts. Any compensation or loss absorption would come from the specific hook contract, external settlement logic, insurance, or off-chain agreements attached to that pool, not from a native Uniswap v4 insolvency fund. Impact path through the smart contracts: a pool action routes into PoolManager, which calls the configured hook at designated points before/after pool operations; if the hook’s custom logic depends on an insolvent counterparty, the failure typically propagates back into the transaction and causes a revert. Because hooks are external contracts, they are the main place where bespoke credit, guaranteed pricing, or permissioned-settlement designs could create residual counterparty risk. Per chain: expected protocol-level loss absorption is Not verifiable as of 2026-08-29 for any specific chain deployment without on-chain verification of the live deployments and hook set used on that chain. Sources used here are Uniswap’s v4 architecture and hooks documentation, plus the v4 whitepaper describing hooks and lifecycle callbacks.

For the Uniswap V4 DAO/owners stress scenario of committed fraud, the most defensible answer is Not verifiable as of 2026-08-29. The available sources describe security bugs, governance-risk discussions, and court rulings about third-party token issuers, but they do not verify that the Uniswap DAO, Uniswap Labs, or identifiable owners committed fraud. What is verifiable is that Uniswap v4 has had serious security findings in audits, including issues that could enable unauthorized value extraction if exploited, such as fee theft or accounting vulnerabilities. Those are technical vulnerabilities, not evidence of intentional fraud by the DAO or owners. The governance material shows the DAO controls uniswap.eth through UNI-holder voting and has discussed protections against a possible governance attack or malicious capture, which is a relevant fraud-like stress case at the governance layer. However, those documents are precautionary and do not establish actual fraudulent conduct by the DAO. Independent legal reporting also cuts against a fraud allegation against Uniswap itself: federal courts dismissed suits trying to hold Uniswap Labs responsible for fraud committed by third-party token issuers, finding that providing the platform was not enough to make the platform liable for others’ misconduct. That supports the view that, based on currently available evidence, the fraud scenario is unsubstantiated rather than confirmed. If you want, I can next assess the adjacent stress scenario of governance capture / malicious proposal control for Uniswap v4 across the listed chains.

For Uniswap v4, a negative 30d primary yield source means the protocol’s native yield/revenue stream is not positive over the last 30 days, so a stress case should assume zero or negative fee-based support for LPs rather than relying on protocol earnings. DeFiLlama shows 30d revenue = $0 and 30d fees = $0 for Uniswap V4, with the per-chain figures shown as $0 across the listed chains, including Arbitrum, Avalanche, Base, Ethereum, Monad, OP Mainnet, and Polygon. That means the primary yield source is currently not providing positive carry, so any LP return in a stress model would depend on trading volume, incentive programs, or hook-specific external economics rather than protocol-generated yield. Uniswap Labs also documents that v4 liquidity operations use deltas and can revert if balances are not settled correctly, which is relevant for stress modeling because adverse execution can amplify losses if slippage and settlement assumptions are wrong. Two important caveats: first, the provided web results do not verify on-chain TVL or chain-by-chain exposure, so exact capital at risk by chain is Not verifiable as of 2026-08-29. Second, because the available source is an aggregator, the $0 revenue/fees figures should be treated as an observed platform metric rather than raw-chain proof. In practical stress terms, the conservative assumption is that LP yield is flat-to-negative after fees, IL/LVR, and execution costs, especially if volatility rises while fee income remains at zero.

Uniswap v4 is part of the Uniswap Protocol, whose governance is exercised by UNI token holders via Uniswap DAO, with significant ongoing influence from the Uniswap Foundation and Uniswap Labs. ### 1. Who controls what

• Core protocol contracts (v4 on Ethereum and L2s): Upgradable/parameter‑governed via Uniswap DAO using the UNI token; execution typically through governance contracts and timelocks.
• Development roadmap:
• Uniswap Labs (US company) leads client/frontend and major code releases.
• Uniswap Foundation (independent non‑profit in Delaware) funds R&D, grants, and some protocol upgrades via governance‑approved budgets.
• Frontends (app.uniswap.org, web UI, SDKs): Operated and controlled by Uniswap Labs, under their own Terms of Service (US law jurisdiction).
• Treasury/funds: Protocol/DAO treasury in UNI and other assets controlled by on‑chain governance; Uniswap Foundation has a multi‑year UNI allocation governed by a charter approved by governance. ### 2. Governance process
• Token: UNI (ERC‑20 on Ethereum; bridged to L2s such as Arbitrum, Optimism, Base, Polygon, Avalanche).
• Proposal flow (high level):
• Off‑chain temperature checks on governance forum & Snapshot.
• On‑chain proposals (Ethereum) with UNI delegation threshold (historically 2.5M UNI to submit; check current docs for exact number – Not verifiable as of 2026‑08‑30).
• On‑chain voting with quorum requirement and execution via timelock. ### 3. DAO: real vs symbolic; concentration
• Governance has successfully executed major changes (Uniswap Foundation creation, fee switch experiments, cross‑chain deployments), indicating real control over protocol parameters and treasury, but Uniswap Labs still de facto steers agenda via influence and code delivery.
• Voting power concentration / top holders: Requires Dune/chain analysis, which is not available in this run. Not verifiable as of 2026‑08‑30. ### 4. Timelocks, multisigs, signers
• Historical Uniswap governance uses timelock contracts for executing passed proposals on Ethereum mainnet.
• Some deployment/admin multisigs exist for per‑chain contracts (e.g., Arbitrum, Optimism, Polygon, Base, Avalanche), often controlled by a mix of Uniswap Labs, Foundation, and community signers; exact signer lists, thresholds, and independence per chain are Not verifiable as of 2026‑08‑30 at the required on‑chain standard. ### 5. Legal entities & ToS
• Uniswap Labs: US‑based company (commonly cited as Uniswap Labs Inc., Delaware), operating primary frontend and trademarks.
• Uniswap Foundation: Delaware non‑profit corporation, with board‑approved by governance; directors named in governance posts and Foundation site (e.g., President Devin Walsh and others).
• ToS: Frontend users contract with Uniswap Labs under US law, with typical DeFi disclaimers (no custody, no guarantee, regional restrictions).

Uniswap v4’s legal and regulatory risk is primarily tied to Uniswap Labs and its interface/related products, not to a clearly disclosed separate v4 operating entity; Uniswap Labs’ terms say the products may be unavailable in some jurisdictions and are governed by New York law. The terms also place compliance responsibility on users, state that availability does not create jurisdiction outside New York, and include tax-responsibility language. On KYC/AML, the protocol is generally described as permissionless, but the interface/terms restrict use by sanctioned persons and sanctioned territories; this is a sanctions-screening restriction, not a full KYC regime. I could not verify any on-chain or product-level KYC/AML program beyond those terms, so the broader KYC/AML posture is Not verifiable as of 2026-08-29. On classification and enforcement, Uniswap Labs has faced U.S. regulatory attention: a CFTC settlement alleged unlawful leveraged/margined commodity transactions and resulted in a penalty, while the SEC later said it would not pursue an enforcement action after investigating Uniswap Labs. Separately, a federal court dismissed a securities class action against Uniswap Labs, and the Second Circuit later affirmed dismissal; these cases reduce, but do not eliminate, litigation risk. Warnings / restrictions: user eligibility limits, sanctions prohibitions, and New York governing-law/arbitration provisions are the main published legal restrictions. Claims that the interface broadly “complies with AML/KYC” or that v4 itself is licensed or regulated are unverified marketing claims absent stronger evidence. Data protection / structure vs actual risk: the practical risk is that a permissionless protocol can be treated differently from the centralized interface and affiliated entity. In other words, the legal form is decentralized infrastructure, but the regulatory exposure clusters around Uniswap Labs, the front end, and any ancillary products or features it operates.

Not verifiable as of 2026-08-29. The gathered web results do not identify a specific stablecoin used by Uniswap v4 across the listed chains in a way that supports a verified depeg-count analysis, and no on-chain verification was available in this run. If the question refers to stablecoin pairs deployed on Uniswap v4, the depeg history is not verifiable from the available sources alone. The only directly relevant stablecoin-related result indicates USDS/USDT and USDS/PYUSD liquidity on Uniswap v4, but it does not provide a verified history of depegs or quantify any depeg percentage.

Top 5 risks for Uniswap V4 are: 1. Malicious or buggy hooks executing arbitrary logic, which can steal funds, worsen execution, or manipulate swaps because hooks are permissionless and can run custom code. 2. Custody risk from custom-accounting/async hooks, where a hook may temporarily or fully control assets; a flaw or misuse can drain pool liquidity or lock funds. 3. Denial-of-service risk, including unhandled reverts, infinite loops, excessive gas use, or broken hook logic that can block swaps, liquidity adds/removals, or trap LP funds. 4. Systemic concentration risk from the singleton architecture, since many pools share core infrastructure and a bug in shared logic can have broader blast radius across pools. 5. Governance/upgrade/admin risk in hook ecosystems, because external or upgradeable hooks may have privileged roles that can change behavior, pause trading, or inject malicious logic if compromised. A notable protocol-level consideration is that Uniswap’s own security framework classifies high risk as involving complex math, external liquidity, autonomous behavior, upgradeability, price impact, or large TVL, which matches several V4 design features.

Uniswap v4’s top strengths are its programmability, gas efficiency, scalability, fee flexibility, and native ETH support. Hooks let developers add custom logic to pools without forking the protocol, which makes v4 a platform for new AMM designs rather than a fixed-product DEX.

• Programmable hooks: developers can add custom behavior before/after swaps or liquidity events, enabling use cases like dynamic fees, MEV protection, limit orders, and other bespoke pool logic.
• Lower gas costs: the singleton architecture puts all pools in one contract, while flash accounting batches settlement so multi-hop swaps and pool creation are cheaper.
• Better capital and routing efficiency: by avoiding separate pool contracts and minimizing token transfers, v4 improves multi-pool routing and reduces transaction overhead.
• Greater fee flexibility: v4 supports unlimited fee tiers and dynamic fees, letting pools adapt pricing to volatility, liquidity conditions, or custom strategies.
• Native ETH support: direct ETH pairs remove the need to wrap ETH into WETH for trading, simplifying user experience and reducing gas for ETH trades. A protocol-style summary is that v4’s main strength is turning Uniswap from a standard AMM into a modular infrastructure layer for customized liquidity products.