Uniswap

This proposal is part of the protocol fee rollout, following proposals #93, #94, #95, #96, #99, and #100. It uses the expedited governance process approved in UNIfication, where fee parameter update proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote. Since protocol fees went live on Ethereum mainnet in late December last year, the rollout has extended to eleven additional chains: Arbitrum, Base, OP Mainnet, Worldchain, X Layer, Soneium, Zora, Celo, BNB Chain, Polygon, and Robinhood Chain. The burn system is working as designed, with fees accumulating in TokenJars across chains. From there, searchers claim them in exchange for burning UNI by bridging it back to mainnet and sending it to the burn address. Arc is a Layer 1 built by Circle for the world's financial markets, real-time money movement, and agentic economic activity, with mainnet going live September 16, 2026. Uniswap was live on Arc from launch, with v2, v3, v4, and UniswapX all deployed. This proposal: Extends the infrastructure for collecting and burning protocol fees to Arc Enables v2, v3, and v4 protocol fees on Arc Implementation Details Governance path. Cross-chain governance messages are sent from the protocol's Timelock to the UniswapWormholeMessageSender on Ethereum and executed on Arc by UniswapWormholeReceiver. As is the case on Polygon and BNB Chain, the UniswapWormholeMessageReceiver holds the feeToSetter role on the Uniswapv2Factory and the owner role on Uniswapv3Factory and v4's PoolManager prior to turning on fees. Burn path. UNI on Arc is a synthetic token under Wormhole's Native Token Transfer system (NTT). This is a 'lock, mint, and burn' system where canonical UNI is locked on Ethereum so a synthetic UNI can be minted on a foreign chain using Wormhole's NTT infrastructure. More details can be found in the spec here. Protocol fees generated on Arc burn UNI on mainnet using the Tokenjar and Releaser smart contracts. As on other chains, a searcher pays synthetic UNI on Arc to claim the TokenJar's accumulated fees. The releaser, WormholeReleaser, sends that synthetic UNI to be burned by the NttManager on Arc, which emits a Wormhole message. The message is forwarded to the NttManager on Ethereum, which sends the corresponding canonical UNI to the burn address. This is the same releaser and the same path already in production on Polygon and BNB Chain. The AMM and governance message passing contracts have been deployed and are detailed in the table below. The protocol fee infrastructure contracts will be deployed in the coming days and added to the table before the onchain vote goes live. Implementation details for the v4 fee system are in the v4 fee activation temp check. v2 and v3 protocol fee levels are the same as on all other chains where fees are live. See a breakdown here. Proposal Spec If passed, the Arc Fee Activation proposal will execute two sets of calls on Ethereum. The first registers Arc with the existing mainnet NTT system, setting Arc's WormholeTransceiver and NttManager as peers of their Ethereum counterparts. On Polygon and BNB Chain this step was permissionless, because the mainnet NTT contracts were being deployed at the same time and had not yet been handed to the Timelock. Those contracts now exist and are governance owned, so registering a new chain against them requires an onchain vote. `` WORMHOLETRANSCEIVER.setWormholePeer(ARCWORMHOLECHAINID, ARCWORMHOLETRANSCEIVER) NTTMANAGER.setPeer(ARCWORMHOLECHAINID, ARCNTTMANAGER, 18, 0) ` Note that WORMHOLECHAINID is a parameter specific to Wormhole, not to be confused with EVM Chain IDs. More details here. The second call sends the fee activation calls to Arc: ` WORMHOLESENDER.sendMessage(targets, values, datas, UNISWAPWORMHOLERECEIVER, ARCWORMHOLECHAINID) ` encoding: ` V2FACTORY.setFeeTo(TOKENJAR) V3FACTORY.setOwner(V3OPENFEEADAPTER) V4POOLMANAGER.setProtocolFeeController(V4FEEADAPTER) `` Once executed on Arc, these set the fee collector of UniswapV2Factory to TokenJar, transfer ownership of UniswapV3Factory to V3OpenFeeAdapter, and set the v4 PoolManager's protocol fee controller to V4FeeAdapter. RELEVANT ADDRESSES: | Name | Network | Address | Description | |----|----|----|----| | V2_FACTORY | Arc | 0x89e5DB8B5aA49aA85AC63f691524311AEB649eba | Uniswap V2 Factory | | V3_FACTORY | Arc | 0xf0db7b58379503491d857dB50AC9ece64c653918 | Uniswap V3 Factory | | V4POOLMANAGER | Arc | 0x8366a39CC670B4001A1121B8F6A443A643e40951 | Uniswap V4 Pool Manager | | UNISWAPWORMHOLERECEIVER | Arc | 0xbCA30b5429935205037069cF5b8A165F55d05a75 | Governance owned Wormhole receiver | | TOKEN_JAR | Arc | TBD | Fee Collector | | V3OPENFEE_ADAPTER | Arc | TBD | Uniswap V3 Fee Adapter | | V4FEEADAPTER | Arc | TBD | Uniswap V4 Fee Adapter | | V4FEEPOLICY | Arc | TBD | Uniswap V4 Fee Policy | | RELEASER | Arc | TBD | WormholeReleaser | | NTT_MANAGER | Arc | TBD | Wormhole NTT Manager | | WORMHOLE_TRANSCEIVER | Arc | TBD | Wormhole Transceiver | | SYNTHETICNTTUNI | Arc | TBD | Synthetic UNI | | WORMHOLE_SENDER | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | Wormhole Sender | | NTT_MANAGER | Ethereum | 0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44 | Wormhole NTT Manager | | WORMHOLE_TRANSCEIVER | Ethereum | 0x7597C40Fd3df66b750C14ad4D90524e247499011 | Wormhole Transceiver | Next Steps / Timeline Snapshot: Sep 18-23, 2026 Onchain vote: Following successful Snapshot

Summary GFX Labs/Oku Trade proposes deploying Uniswap V4 on four EVM-compatible networks: Sei, Etherlink, Pharos, and 0G. These deployments expand V4's footprint, generate protocol fees across new chains, and give hook developers new environments to build on. With Morpho deployed on these networks, the addition of V4 provides a playground for unique financial applications to be developed. V3 is deployed on all chains and acts as the main liquidity hub for the networks. No treasury spend is requested — GFX Labs covers all costs. --- Background Since 2022, GFX Labs has deployed Uniswap V3 to 30+ EVM chains through Oku Trade, funding and executing the majority of deployments independently. With Oku's V4 interface complete, we are positioned to continue this expansion. This proposal covers four chains where the community, liquidity environment, or emerging technical primitives create meaningful opportunities for the Uniswap DAO. --- Upside for the DAO The four networks in this proposal collectively represent a meaningful and growing source of protocol fee revenue for the DAO. Sei recorded $1.5B in DEX volume in Q1 2026 with TVL holding steadily above $50M. With limited competition outside of Sei's native DEX Saphyre, V4 is well positioned to carve out meaningful market share. Pharos adds further upside — with mainnet recently live and over $100M committed to RWAs on the network, V4 has a clear opportunity to become the primary trading protocol on a chain purpose-built for institutional liquidity. Applying a 5bps protocol fee across anticipated V4 pool activity at common 5bps and 30bps LP fee tiers, even conservative volume assumptions produce meaningful accrual. If V4 captures 15-20% of Sei's quarterly DEX volume, that represents roughly $300M flowing through V4 pools and an estimated $150,000 in quarterly protocol fees from a single chain at current activity levels. With Uniswap's fee switch now active following the UNIfication proposal, every incremental deployment directly contributes to protocol revenue, making low-cost (zero in this case), high-conviction expansions like this the most efficient path to growing the DAO's fee base. !V4draftimage|690x392 Proposed Deployments Sei Sei is a Layer-1 blockchain built specifically for trading and financial applications. With over $300M in minted stablecoins, predominantly through Ondo's multi-chain U.S. treasury product, Sei has established a strong and growing foothold in EVM DeFi. The network's ongoing full EVM migration plan aims to enhance network performance and further position itself as the backbone for institutional-grade onchain infrastructure. Etherlink (Tezos EVM) Etherlink is the EVM-compatible Layer 2 of the Tezos ecosystem, backed by the Tezos Foundation, one of crypto's most established and consistently funded foundations since 2014. Etherlink has developed a notable presence in novel onchain RWA markets, specifically for metals, as exemplified by tokenized uranium (xU308), which can be leveraged as collateral for USDC-backed loans on Morpho. With a focus on bringing unique assets onchain, V4 adds another layer to Etherlink's growing suite of financial markets. Etherlink is currently undergoing a rebranding to TezosX - a consolidation effort to strengthen and reunify the Tezos brand and act as the primary EVM DeFi environment for the network. Pharos Pharos is an EVM Layer 1 focused on RWA tokenization, high-throughput DeFi, and institutional-grade infrastructure. Built and incubated by Ant Group with over $50M in raised capital from investors including Sumitomo, Chainlink, and Flow Traders, Pharos heads into its 2026 mainnet after an exceptional testnet that processed 4.3B transactions across 200 million wallets, with its inaugural RWA vault reaching $50M capacity within days of opening. With Morpho live on the network, combining V4’s programmable liquidity layer gives Pharos the most capable DeFi stack available for institutions looking to move, lend, and trade tokenized assets in a compliant environment at scale. 0G 0G is a modular Layer 1 built for AI and autonomous applications, backed by $290M in funding, with mainnet launching in September 2025. It offers decentralized storage with 2 GB/s throughput and a data availability layer that is significantly faster and cheaper than Ethereum's. As AI agents and autonomous DeFi protocols grow in prevalence, they'll need reliable onchain liquidity infrastructure. V4's hooks to enable dynamic fees, TWAMM, and programmable pool behaviors are a strong fit for AI-driven strategies that require more nuanced market infrastructure than standard AMMs offer. Deploying V4 on 0G positions Uniswap as the default DEX for the emerging agentic economy. 0G is currently incentivizing three V3 pools with $40,000 $0G distributed monthly. --- Benefits to the DAO More protocol fee revenue. Four additional chains means four more sources of fees accruing to the DAO as V4 adoption grows. Expanded V4 footprint. Each deployment grows the total addressable market for Uniswap — more users, more LPs, more developers interacting with V4 infrastructure. No cost. GFX Labs handles all technical deployment, maintenance, and Oku interface support. No treasury expenditure, no token subsidies. --- Requested Action GFX Labs requests that the Uniswap DAO: Grant GFX Labs a Uniswap V4 BSL This proposal continues Oku's role as a reliable execution partner for the DAO — handling the operational lift of the V4 expansion so the DAO can capture the upside without the overhead. More chains, more hooks, more fee generation. We welcome feedback on the networks, deployment process, or integration timelines. — GFX Labs / Oku.Trade

This proposal is part of the protocol fee rollout, following proposals #93, #94, #95, and #96. It uses the expedited governance process approved in UNIfication, where fee parameter update proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote. Since protocol fees went live on Ethereum mainnet in late December last year, the rollout has extended to ten additional chains: Arbitrum, Base, OP Mainnet, Worldchain, X Layer, Soneium, Zora, Celo, BNB Chain, and Polygon. The burn system is working as designed, with fees accumulating in TokenJars across chains. From there, searchers claim them in exchange for burning UNI by bridging it back to mainnet and sending it to the burn address. Uniswap launched on Robinhood Chain at the chain's July 1, 2026 mainnet debut, with v2, v3, and v4 all live. As of July 10, the deployments have crossed $1b of cumulative swap volume. This proposal: Extends the infrastructure for collecting and burning protocol fees to Robinhood Chain Enables v2, v3, and v4 protocol fees on Robinhood Chain Implementation Details Fees on Robinhood Chain will be routed to the TokenJar on that chain. UNI burned on Robinhood Chain is bridged back to Ethereum mainnet and sent to the burn address. Robinhood Chain is an Arbitrum Orbit chain, so this proposal reuses the pattern from the Arbitrum One activation in proposal 94. Governance path. Same as Arbitrum One: cross-chain governance messages are delivered as retryable tickets through Robinhood Chain's Inbox contract on Ethereum and executed on Robinhood Chain by the L2 alias of the governance Timelock. The aliased Timelock already controls both factories and the v4 PoolManager on Robinhood Chain (it is the v2 factory's feeToSetter and the owner of the v3 factory and the PoolManager), so no ownership migration is required. Burn path. The releaser, ArbitrumOrbitResourceFirepit, is the Arbitrum One firepit generalized for Orbit chains. A searcher pays bridged UNI on Robinhood Chain to claim the TokenJar's accumulated fees, and the contract withdraws that UNI to the burn address on mainnet through the canonical gateway. As on Arbitrum One, the withdrawal finalizes on mainnet after Robinhood Chain's challenge period. The TokenJar, Releaser, V3OpenFeeAdapter, V4FeeAdapter, and V4FeePolicy will be deployed ahead of the onchain votes, with ownership verified against the aliased Timelock. This post will be updated with those addresses when they've been deployed and a link to the repo containing the contracts and deployment scripts once it has been merged. Implementation details for the v4 fee system are in the v4 fee activation temp check. v2 and v3 protocol fee levels are the same as on all other chains where fees are live, see breakdown here. Proposal Spec If passed, the Robinhood Fee Activation proposal will execute two calls, each creating a retryable ticket in Robinhood Chain's Inbox on Ethereum. RH_INBOX.createRetryableTicket(...) x2 One call will encode: V2FACTORY.setFeeTo(TOKENJAR) The other will encode: V3FACTORY.setOwner(V3OPENFEEADAPTER) Once executed on Robinhood Chain, they set the fee collector of UniswapV2Factory to TokenJar and transfer ownership of UniswapV3Factory to V3OpenFeeAdapter. Robinhood's v4 activation will be included in the V4 Fee Activation (Part 1) proposal described below. Matching the spec of the v4 fee activation temp check, and delivered through the same retryable ticket path, it will encode: V4POOLMANAGER.setProtocolFeeController(V4FEEADAPTER) RELEVANT ADDRESSES: | Name | Network | Address | Description | | :--- | :--- | :--- | :--- | | V2_FACTORY | Robinhood Chain | 0x8bcEaA40B9AcdfAedF85AdF4FF01F5Ad6517937f | Uniswap V2 Factory | | V3_FACTORY | Robinhood Chain | 0x1f7d7550B1b028f7571E69A784071F0205FD2EfA | Uniswap V3 Factory | | V4POOLMANAGER | Robinhood Chain | 0x8366a39cc670b4001a1121b8f6a443a643e40951 | Uniswap V4 Pool Manager | | L2GATEWAYROUTER | Robinhood Chain | 0x1E324B9316138CA9a73F960213621AD1aaf01B89 | Canonical L2 Gateway Router | | ALIASED_TIMELOCK | Robinhood Chain | 0x2BAD8182C09F50c8318d769245beA52C32BE46CD | L2 alias of the governance Timelock | | RH_INBOX | Ethereum | 0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D | Robinhood Chain Delayed Inbox | | TOKEN_JAR | Robinhood Chain | TBD | Fee Collector | | V3OPENFEE_ADAPTER | Robinhood Chain | TBD | Uniswap V3 Fee Adapter | | V4FEEADAPTER | Robinhood Chain | TBD | Uniswap V4 Fee Adapter (protocolFeeController) | | V4FEEPOLICY | Robinhood Chain | TBD | Uniswap V4 Fee Policy | | RELEASER | Robinhood Chain | TBD | ArbitrumOrbitResourceFirepit (searcher burn) | | UNI | Robinhood Chain | TBD | Bridged UNI | Onchain Execution This Snapshot covers v2, v3, and v4 fees on Robinhood Chain, but onchain execution will be split across three proposals. A separate Snapshot to enable v4 fees on the eleven chains where v2/v3 fees are already live concludes this weekend. The v4 activation is the same call on every chain (set the PoolManager's protocolFeeController to the V4FeeAdapter), so it is faster and safer to batch the v4 activations together and keep Robinhood's v2/v3 calls on their own: 1. Robinhood Fee Activation: the two calls specced above 2. V4 Fee Activation (Part 1): Ethereum, Base, Robinhood, BNB Chain, Arbitrum, Optimism, Polygon 3. V4 Fee Activation (Part 2): Celo, Soneium, X Layer, World Chain, Zora Robinhood Fee Activation and V4 Part 1 will go onchain first, with Part 2 following once a proposer wallet frees up. Robinhood's v4 fees will be enabled through Part 1, contingent on both Snapshots passing. Next Steps / Timeline Snapshot begins: Jul 10, 2026 Snapshot ends: Jul 15, 2026 Onchain votes: Robinhood Fee Activation and V4 Fee Activation (Part 1) following the Snapshots, per standard governance cadence; V4 Fee Activation (Part 2) to follow

Summary This proposal continues the protocol fee rollout approved in UNIfication, following proposals #93, #94, #95, and #96. It uses the expedited governance process where fee parameter update proposals go directly to a five-day Snapshot followed by an onchain vote. Protocol fees are now live across all v2 and v3 pools on 11 chains - Ethereum, Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, Zora, BNB Chain, and Polygon. Last month, the protocol set a record burning 186,000 UNI in one day. Below we introduce a system for v4 protocol fees and propose to activate it on a subset of v4 pools on these same chains. --- Implementation Details v4's hook architecture requires a different approach to fee activation than v2 or v3. v2 pools have a single LP fee tier and are charged a static fee. v3 has several LP fee tiers, each charged a static fee. Hooks mean v4 has potentially infinite distinct LP fee tiers, and a pool's fees can change dynamically from one block to the next. To manage this, we propose a V4 Fee Controller system where governance sets rules that let a dedicated contract compute the fee for any pool on demand, rather than setting a fee on each individual pool. The system splits across two contracts: V4FeePolicy. Given any pool, it computes the fee from rules defined by governance. This is the contract governance calls to enable and adjust the protocol fee, and it can be swapped out later if the logic for setting fees needs to evolve. V4FeeAdapter. Enforces governance overrides, so if governance has set a per-pool override, that override wins and the policy is skipped. Otherwise the adapter applies the policy's fee, pushes it to the pool, and collects the proceeds to the TokenJar. V4FeePolicy determines a pool’s fee in two steps. First it sorts the pool into a family. A pool’s family is determined by its characteristics, e.g. whether it has a hook, whether it uses the PoolManager’s native swap math, whether it charges dynamic swap fees, et cetera. A pool’s family is identified by a flag, which is stored on the hook smart contract. Hook developers can opt their pools into a family via assigning it a specific flag. Governance can also assign a hook to a family directly via a vote. Once it determines the pool's family, the policy then resolves the fee, applying the rules below, going in order from most specific to least: 1. a per-pair fee, if governance has set one for that token pair in that family 2. otherwise the family's own fee (defined by governance as a default or curve) 3. otherwise a global default for anything still unclassified With this system, governance manages a handful of rules and overrides instead of an unbounded list of pools, any fee is computed deterministically and can be inspected onchain, and the policy itself is replaceable if governance later wants to change how pools are categorized. This proposal activates fees on three pool families: Static fee pools: These are pools without hooks. The protocol fee for these pools is set via a curve targeting a proportion of each pool's LP fee. For a description of this curve, please see the appendix below. CCA Pools: These are pools launched after a Continuous Clearing Auction. The LBPHook and pools resulting from previous auctions will be opted into the same curve as static pools. Aggregator hook pools: These are pools whose hooks integrate external liquidity venues into the v4 routing graph. The protocol fee for the aggregator hook family is a flat fee with overrides for specific pair types. To maintain the option of charging more on this external flow than the v4 PoolManager’s hard cap of 10bps, aggregator hooks will multiply their assigned fees by 25, allowing for a cap of 250bps. After the multiplier is applied, the resulting fee for aggregator hooks will be: - For all chains other than Base: - Family Default: 10bp - Select Stable Pairs: 3bp - For Base: - Family Default: 3bp - Select Stable Pairs: 1bp This proposal does not enable the protocol fee for any pools other than those in the Families mentioned above. Fees will flow to TokenJar on each chain. UNI burned on L2s and alt-L1s will be bridged back to Ethereum mainnet and sent to 0xdead. --- Onchain Proposal Spec Pre-proposal (to be completed by Uniswap Labs prior to an onchain vote) Deploy V4FeeAdapter and V4FeePolicy contracts on all chains where the v2 and v3 protocol fees are currently enabled (Ethereum, Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, Zora, BNB Chain, and Polygon). Configure V4FeePolicy contracts with the native math protocol fee curve, CCA Hook and aggregator hook family fee logic described above These contracts can be found here, and this post will be updated with addresses and explorer links when they have been deployed. In this proposal (executed if the vote passes): Set the V4FeeAdapter as the ProtocolFeeController on the PoolManager on each chain --- Next Steps / Timeline Snapshot: July 7-12, 2026 Onchain vote: Starting the week of July 13, 2026 Please note that because of GovernorBravo’s limit of 10 actions per proposal, there will be two separate onchain votes posted in parallel to accommodate all chains. --- Appendix - Static Fee Curve The V4 Fee Controller allows fee setting using discrete LP fee tier ranges. Each range has a floor, and the next range sets the ceiling. For each range, governance sets two inputs: alpha which is the constant. This is the starting fee for that range. beta which is the scaling factor. This is how fast the fee grows within that range. The growth always starts from the floor of the range. Inside any range, the fee is: alpha + beta \* (lpFee - floor).The output is floored to the nearest 0.01bp increment, consistent with v4's minimum fee resolution. | Range (bps) | Floor | Alpha (bps) | Beta (bps) | | :--- | :--- | :--- | :--- | | 0 - 0.03 | 0 | 0.01 | 0 | | 0.03 - 0.75 | 0.03 | 0.01 | 19/72 | | 0.75 - 1 | 0.75 | 0.2 | 0.2 | | 1 - 3.75 | 1 | 0.25 | 3/11 | | 3.75 - 5 | 3.75 | 1 | 0.2 | | 5 - 25 | 5 | 1.25 | 11/80 | | 25 - 55 | 25 | 4 | 0.2 | | > 55 | 55 | 10 | 0 | This results in the following fees at the following points. | LP Fee (bps) | Protocol Fee (bps) | | :--- | :--- | | 0.03 | 0.01 | | .75 | 0.20 | | 1 | 0.25 | | 3.75 | 1 | | 5 | 1.25 | | 25 | 4 | | 30 | 5 | | 83.34 | 10 | | 100 | 10 |