Uniswap Governance

TL;DR DUNI owns the three Gauntlet-curated Morpho Vaults V2 behind Uniswap Earn: uniUSDC, uniUSDT and uniETH, all on Ethereum mainnet. Gauntlet has upgraded its signing infrastructure and needs to swap out some wallets configured in the Sentinel role on vault deployment. setIsSentinel, the function used to adjust addresses granted the Sentinel role, is owner-gated and the Owner is Uniswap governance’s mainnet Timelock. Background Uniswap Labs launched Uniswap Earn in July 2026. Consistent with past Uniswap Labs-originated protocol launches, the ownership roles on the smart contracts that power Uniswap Earn were assigned to Uniswap Governance. In Earn, a user deposits USDC, USDT or ETH in the Uniswap app, the deposit flows into a Morpho Vaults V2 instance, and Gauntlet curates the allocation. In the run up to launch, Gauntlet deployed the three vaults and transferred ownership to DUNI’s Timelock address. Morpho Vaults V2 splits control across four roles. | Role | Capabilities | Appointed by | Held on the Earn vaults by | | ----- | ----- | ----- | ----- | | Owner | Appoint the Curator, add and remove Sentinels, transfer ownership, set vault name and symbol. One address only. | Prior Owner, via setOwner | DUNI, via the mainnet Timelock | | Curator | Set caps and risk parameters, enable yield sources, set fees, appoint allocators. Most actions timelocked. One address only. | Owner | Gauntlet | | Allocator | Move capital between enabled yield sources, within the bounds the Curator has set. Multiple addresses allowed. | Curator | Gauntlet | | Sentinel | Lower caps, revoke pending Curator actions, pull assets out of lending markets back into the vault. Takes effect instantly. Multiple addresses allowed. | Owner | Gauntlet | The Owner has no claim on deposits and does not set risk parameters, allocations, or fees directly. Fee management sits with the Curator. Governance's leverage runs through its power to appoint and replace the Curator, which is why ownership was structured this way. Performance fee is currently zero on all three vaults. Motivation Gauntlet has upgraded the signing infrastructure it uses across the vaults it curates. Specific to Uniswap Earn vaults, this has resulted in new addresses for the Sentinel role. Specification The three vaults, all on Ethereum mainnet: | Vault | Address | | ----- | ----- | | Uniswap USDC (uniUSDC) | 0x5B453493D2328E7F747eb2e66446eFe707728be7 | | Uniswap USDT (uniUSDT) | 0xb8274eFADB953FE9ae052D481a3FC5B6A3ceD703 | | Uniswap ETH (uniETH) | 0x98D2b241DA14c5dd848812708Eb8A1F3c5512f9d | The Owner of all three is the Timelock at 0x1a9C8182C09F50C8318d769245beA52c32BE35BC. We propose calling setIsSentinel(address,bool) six times: once to grant the role to each new Gauntlet address, and once to revoke it from each legacy address. | Vault | New Sentinel (grant) | Legacy Sentinel (revoke) | | ----- | ----- | ----- | | uniUSDC | 0xF66b884D1906F37c1692CEa63564316FF975Cd75 | 0xc3FE37DB03B5720D1684bE2e0200E0Af07853Ad9 | | uniUSDT | 0xD9b023059dfD00C2DC68C4d8d0c70BCaA30577Db | 0x2745513325d4Ce5724e5B6Fb663356C427AfdeCc | | uniETH | 0x4Ff315B873d6e5Ad8ff7fF3e17D340862762cc2f | 0xc63A00De30AeB5666a8aC3478a4D119D38058c7E | A vault can hold more than one Sentinel, so the grants and the revocations are independent actions. For every vault, the Curator stays Gauntlet, the Owner stays the Timelock, and all parameters such as caps, adapters and fees are unchanged. Onchain Proposal Spec Six transactions, all sent from the Timelock, all with value = 0. Function selector 0x920ed706. `` // uniUSDC vault: 0x5B453493D2328E7F747eb2e66446eFe707728be7 setIsSentinel(0xF66b884D1906F37c1692CEa63564316FF975Cd75, true); setIsSentinel(0xc3FE37DB03B5720D1684bE2e0200E0Af07853Ad9, false); // uniUSDT vault: 0xb8274eFADB953FE9ae052D481a3FC5B6A3ceD703 setIsSentinel(0xD9b023059dfD00C2DC68C4d8d0c70BCaA30577Db, true); setIsSentinel(0x2745513325d4Ce5724e5B6Fb663356C427AfdeCc, false); // uniETH vault: 0x98D2b241DA14c5dd848812708Eb8A1F3c5512f9d setIsSentinel(0x4Ff315B873d6e5Ad8ff7fF3e17D340862762cc2f, true); setIsSentinel(0xc63A00De30AeB5666a8aC3478a4D119D38058c7E, false); ` Raw calldata: ` 0x920ed706000000000000000000000000f66b884d1906f37c1692cea63564316ff975cd750000000000000000000000000000000000000000000000000000000000000001 0x920ed706000000000000000000000000c3fe37db03b5720d1684be2e0200e0af07853ad90000000000000000000000000000000000000000000000000000000000000000 0x920ed706000000000000000000000000d9b023059dfd00c2dc68c4d8d0c70bcaa30577db0000000000000000000000000000000000000000000000000000000000000001 0x920ed7060000000000000000000000002745513325d4ce5724e5b6fb663356c427afdecc0000000000000000000000000000000000000000000000000000000000000000 0x920ed7060000000000000000000000004ff315b873d6e5ad8ff7ff3e17d340862762cc2f0000000000000000000000000000000000000000000000000000000000000001 0x920ed706000000000000000000000000c63a00de30aeb5666a8ac3478a4d119d38058c7e0000000000000000000000000000000000000000000000000000000000000000 `` A full simulation will be available via Seatbelt alongside the onchain vote. Risks and Considerations Sentinel authority is constraining-only. Per the deployed contracts, a Sentinel can decrease relative and absolute allocation caps, revoke a timelocked Curator action, and deallocate assets. It cannot allocate, raise caps, withdraw from the vault, or change configuration. A compromised Sentinel can constrain the vault or unwind a Curator action. It cannot drain one. Morpho's own documentation rates the impact of a compromised Sentinel as minimal and lists a hot key as an acceptable setup for the role. No coverage gap. The six transactions execute together, so the new addresses are live before the old ones are removed. Precedent. While Gauntlet does not anticipate needing to swap addresses frequently, any future Sentinel rotation will run through the same process, including Gauntlet's confirmation of ownership of the addresses. Next Steps | Stage | Target | | ----- | ----- | | RFC discussion | Week of September 8, 2026 | | Snapshot temperature check | Week of September 15, 2026 | | Onchain vote | Submitted week of September 21, 2026 | | Timelock execution | Early October 2026 | Supporting Documents Morpho Vaults V2 roles and capabilities Morpho Vault V2 concept overview Morpho Vaults V2 contracts

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 |

Summary Secure crosschain messaging is an integral part of Uniswap's governance model. Governance votes like protocol fee adjustments are executed by UNI holders on Ethereum Mainnet and must subsequently be relayed to destination chains. This proposal updates Uniswap's crosschain governance system to accommodate the latest best practices. Specifically, we propose to: Transition ownership of the Uniswap v2 and v4 contracts on Soneium and X Layer to CrossChainAccount contracts, which we consider to be the current best practice for executing messages from Ethereum Mainnet on the OP Stack Migrate the entire messaging system for the Avalanche and MegaETH deployments from LayerZero v1 (part of which is being deprecated) to Wormhole Note that because Uniswap v3 on both Soneium and X Layer is owned by the v3OpenFeeAdapter, which is owned by the CrossChainAccount, we do not need to change the parameter on v3 on these chains. --- Specification Current Configuration - Avalanche and MegaETH Both chains currently use LayerZero v1 for governance messaging. The OmnichainProposalSender contract exists on Ethereum and sends messages to OmnichainGovernanceExecutor on remote chains. Additionally, there exists a second OmnichainGovernanceExecutor on MegaETH which owns the ProxyAdmin contract administering the PositionDescriptor periphery contract responsible for rendering LP positions as NFT's. | Contract | Chain | Address | | :--- | :--- | :--- | | OmnichainProposalSender | Ethereum | 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc | | OmnichainGovernanceExecutor | Avalanche | 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc | | OmnichainGovernanceExecutor | MegaETH | 0x8819b86ddF592c3aaAa6f9ec7cE1A0f99FC4322c | | OmnichainGovernanceExecutor | MegaETH | 0x51F9629C1e75aF07421E662DBEb2B7dc8deDefd9 | Proposed Configuration - Avalanche and MegaETH The LayerZero contracts are replaced with the Wormhole bridge infrastructure from uniswapfoundation/Uniswap-Wormhole-Bridge: UniswapWormholeSender (Ethereum): The existing sender contract already deployed on mainnet will be reused — no new deployment required. UniswapWormholeReceiver (Avalanche and MegaETH): Uniswap Labs has deployed new UniswapWormholeReceiver contracts on both chains. This proposal will authorize them as the trusted governance executors for each chain. Additionally, the ProxyAdmin owned by the second OmnichainGovernanceExecutor will be unified with under the authority of the UniswapWormholeReceiver on MegaETH. | Contract | Chain | Address | | :--- | :--- | :--- | | UniswapWormholeSender | Ethereum | 0xf5F4496219F31CDCBa6130B5402873624585615a | | UniswapWormholeReceiver | Avalanche | 0x47eB0Cf11a1626462Da3C830bCDe64c3F582B5a6 | | UniswapWormholeReceiver | MegaETH | 0xa107580F73BD797Bd8b87Ff24e98346D99F93DdB | For a detailed discussion of how Wormhole works, please see this report by the Uniswap Foundation's Bridge Assessment Committee. Current Configuration - Soneium and X Layer On both chains, the UniswapV2Factory's feeToSetter parameter and the v4 PoolManager's owner parameter are configured as the mainnet Timelock's alias address. | Account | Chain | Address | | :--- | :--- | :--- | | Alias Address | X Layer | 0x2BAD8182C09F50c8318d769245beA52C32Be46CD | | Alias Address | Soneium | 0x2BAD8182C09F50c8318d769245beA52C32Be46CD | Proposed Configuration - Soneium and X Layer This proposal will change those parameters to a CrossChainAccount contract deployed by Uniswap Labs. | Contract | Chain | Address | | :--- | :--- | :--- | | CrossChainAccount | X Layer | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 | | CrossChainAccount | Soneium | 0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7 | Onchain Proposal Spec Pre-proposal (already completed by Uniswap Labs): Deploy UniswapWormholeReceiver on Avalanche C-Chain, configured with the Wormhole Core Bridge address for Avalanche and the address of the existing UniswapWormholeSender. Deploy UniswapWormholeReceiver on MegaETH, configured with the Wormhole Core Bridge address for MegaETH and the address of the existing UniswapWormholeSender. Deploy CrossChainAccount contracts on Soneium and X Layer In this proposal (executed if the vote passes): Execute nine actions: 1. (Ethereum) Set Layer Zero "trusted remote" to the OmnichainGovernanceExecutor on MegaETH 2. (MegaETH) Transfer ownership of the protocol from OmnichainGovernanceExecutor to UniswapWormholeReceiver 3. (Avalanche) Transfer ownership of the protocol from OmnichainGovernanceExecutor to UniswapWormholeReceiver 4. (Soneium) Transfer V2 ownership from the aliased Timelock to CrossChainAccount 5. (Soneium) Transfer V4 ownership from the aliased Timelock to CrossChainAccount 6. (XLayer) Transfer V2 ownership from aliased Timelock to CrossChainAccount 7. (XLayer) Transfer V4 ownership from the aliased Timelock to CrossChainAccount 8. (Ethereum) Set Layer Zero "trusted remote" to the second OmnichainGovernanceExecutor on MegaETH 9. (MegaETH) Consolidate ProxyAdmin ownership from the second OmnichainGovernanceExecutor to UniswapWormholeReceiver Notable Implementation Details: Regarding MegaETH "trusted remote" configurations: The OmnichainProposalSender on Ethereum must be configured to send messages to the OmnichainGovernanceExecutor on MegaETH, but not the OmnichainGovernanceExecutor on Avalanche. This is due to our OmnichainProposalSender's configuration on initial deployment. The "trusted remote" is Layer Zero's means of defining which sender contracts may interact with which receiver contracts. Regarding ProxyAdmin: There exists two ProxyAdmin contracts per chain, one for the NonfungiblePositionDescriptor (V3 NFT renderer) and one for the PositionDescriptor (V4 NFT renderer). Since ProxyAdmin contracts are designed to administer arbitrarily many proxy contracts, we are taking the opportunity to consolidate the proxy admin authority of both position descriptors while performing an ownership transition. Regarding CrossChainAccount: The low level OP-stack chain bridge uses OptimismPortal2. In short, OptimismPortal2's internal details means the protocol on Soneium and X Layer are owned by an "aliased" form of the Timelock address on Ethereum; this alias is derived from adding a standard offset to the Ethereum address. This is an unintuitive system and increases user-error in ownership transitions, so we are migrating to the higher level of abstraction defined by the CrosChainAccount system. This ensures the protocol on Soneium and X Layer are owned by a concrete contract with limits and authority checks from the messages bridged from Ethereum. We already use this system on other OP-stack chains, so this is to update more chains to use it as well. Next Steps / Timeline RFC: Jun 26, 2026 Snapshot: June 29 - July 4 2026 Onchain vote: Following Snapshot, per standard governance cadence --- Supporting Documents Uniswap Foundation Bridge Assessment Report Uniswap-Wormhole-Bridge GitHub LayerZero v1 deprecation announcement Original Avalanche deployment proposal

This proposal continues the protocol fee rollout, following proposals #92, #93, and #94. 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, the rollout has extended to nine additional chains (Arbitrum, Base, OP Mainnet, Soneium, X Layer, Worldchain, and Zora). 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. This proposal: Extends the infrastructure for collecting and burning protocol fees to BNB Chain and Polygon Enables v2 and v3 protocol fees on these chains Completes Celo's fee activation through a corrected cross-chain governance path, which was approved in a previous proposal but did not execute due to a configuration error Implementation Details Fees on each chain will be routed to the TokenJar on that respective chain. UNI burned on these chains is bridged back to Ethereum mainnet and sent to 0xdead. Celo uses the same architecture as other OP-stack chains. On BNB and Polygon, we make use of Wormhole’s Native Token Transfer (NTT) mechanism for multichain token management. The forum post will be updated early the week of May 18, 2026 with links to the repository containing these contracts and a full description of our implementation. Protocol fee levels are the same on all other chains where fees are live, see breakdown here. Proposal Spec If passed, this proposal will execute three actions: one each for Celo, BNB Chain, and Polygon. Each action contains multiple inner calls. Celo This action sets the fee collector of UniswapV2Factory to TokenJar, transfers ownership of UniswapV2Factory and PoolManager to Optimism CrossChainAccount, and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter. RELEVANT ADDRESSES: |Name|Network|Address|Description| | --- | --- | --- | --- | |V2_FACTORY|Celo|0x114A43DF6C5f54EBB8A9d70Cd1951D3dD68004c7|Uniswap V2 Factory| |V3_FACTORY|Celo|0xAfE208a311B21f13EF87E33A90049fC17A7acDEc|Uniswap V3 Factory| |V4POOLMANAGER|Celo|0x288dc841A52FCA2707c6947B3A777c5E56cd87BC|Uniswap V4 Pool Manager| |TOKEN_JAR|Celo|0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B|Fee Collector| |V3OPENFEE_ADAPTER|Celo|0xB9952C01830306ea2fAAe1505f6539BD260Bfc48|Uniswap V3 Fee Adapter| |UNISWAPWORMHOLEMESSAGE_RECEIVER|Celo|0x0Eb863541278308c3A64F8E908BC646e27BFD071|Governance Owned Wormhole Receiver| |CROSSCHAINACCOUNT|Celo|0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7|Governance-owned OP Bridge Receiver| |WORMHOLE_SENDER|Ethereum|0xf5F4496219F31CDCBa6130B5402873624585615a|Wormhole Sender| `` WORMHOLESENDER.sendMessage(targets, values, datas, UNISWAPWORMHOLEMESSAGERECEIVER, CELOCHAINID) encodes: V2FACTORY.setFeeTo(TOKENJAR) V2FACTORY.setFeeToSetter(CROSSCHAIN_ACCOUNT) V3FACTORY.setOwner(V3OPENFEEADAPTER) V4POOLMANAGER.transferOwnership(CROSSCHAINACCOUNT) ` BNB Chain This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter. RELEVANT ADDRESSES: |Name|Network|Address|Description| | --- | --- | --- | --- | |V2_FACTORY|BNB Chain|0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6|Uniswap V2 Factory| |V3_FACTORY|BNB Chain|0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7|Uniswap V3 Factory| |UNISWAPWORMHOLEMESSAGE_RECEIVER|BNB Chain|0x341c1511141022cf8eE20824Ae0fFA3491F1302b|Governance Owned Wormhole Receiver| |TOKEN_JAR|BNB Chain|0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A|Fee Collector| |V3OPENFEE_ADAPTER|BNB Chain|0x3F07F08b45912dCd6691C5B9412975D5113B2910|Uniswap V3 Fee Adapter| |WORMHOLE_SENDER|Ethereum|0xf5F4496219F31CDCBa6130B5402873624585615a|Wormhole Sender| ` WORMHOLESENDER.sendMessage(targets, values, datas, UNISWAPWORMHOLEMESSAGERECEIVER, BNBCHAINID) encodes: V2FACTORY.setFeeTo(TOKENJAR) V3FACTORY.setOwner(V3OPENFEEADAPTER) ` Polygon This action sets the fee collector of UniswapV2Factory to TokenJar and transfers ownership of UniswapV3Factory to V3OpenFeeAdapter. RELEVANT ADDRESSES: |Name|Network|Address|Description| | --- | --- | --- | --- | |V2_FACTORY|Polygon|0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C|Uniswap V2 Factory| |V3_FACTORY|Polygon|0x1F98431c8aD98523631AE4a59f267346ea31F984|Uniswap V3 Factory| |ETHEREUM_PROXY|Polygon|0x8a1B966aC46F42275860f905dbC75EfBfDC12374|Governance Owned FxChild Receiver| |TOKEN_JAR|Polygon|0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A|Fee Collector| |V3OPENFEE_ADAPTER|Polygon|0x3F07F08b45912dCd6691C5B9412975D5113B2910|Uniswap V3 Fee Adapter| |POLYGONFXROOT|Ethereum|0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2|Polygon's Sender (on Ethereum)| ` POLYGONFXROOT.sendMessageToChild(ETHEREUM_PROXY, abi.encode(targets, values, datas)) encodes: V2FACTORY.setFeeTo(TOKENJAR) V3FACTORY.setOwner(V3OPENFEEADAPTER) ``

Background and Motivation With DUNI unlocking greater governance participation from UNI token holders, this proposal undelegates 12.5M UNI currently deployed via the Franchiser, returning the tokens to the Governance Timelock. These UNI were delegated from the treasury in 2022 and 2023 – 2.5M to the Uniswap Foundation and 10M to a group of active delegates – during periods of low governance participation. The delegations were intended to bootstrap an active delegate base when quorum was at risk and the number of delegates that could meet the proposal threshold was small. Today, Uniswap’s governance environment looks very different. UNI holders have been actively delegating voting power, and since DUNI was established, passed proposals have averaged roughly 75 million votes in turnout, exceeding quorum by approximately 88%. There are now over 50 delegates with greater than 1M UNI of voting power. Undelegating these tokens also resolves a potential incentive misalignment caused by the Franchiser mechanism itself. These delegates were selected by the community for their active participation in governance, but the Franchiser was not designed to ensure structural alignment between voting power and economic exposure. The potential for this misalignment should not persist indefinitely when the original reason for implementing it is no longer a concern.

Author: @Eren_Targ5 (Daoplomats) Summary This proposal seeks to establish a formal "Statute of Limitations" for Uniswap Governance proposals. Specifically, it mandates that any proposal which passes a "Temperature Check" (Snapshot vote) must proceed to an on-chain vote within 90 days. If a proposal fails to move to an on-chain vote within this 90-day window, the Temperature Check is declared "Expired" (or "Dead"). To proceed, the proposer must restart the governance process with a new Temperature Check to ensure community sentiment remains current. 2. Motivation Currently, Uniswap Governance operates on a continuous cycle. Unlike Optimism or Arbitrum, which utilize specific "Governance Seasons" or "Cycles" that naturally flush out stale proposals at the end of a period, Uniswap proposals can technically remain "pending" indefinitely after passing a Snapshot vote. This creates critical risks and inefficiencies: Market Conditions Change: A proposal approved by the community 6 months ago may be financially dangerous or irrelevant today due to changes in market volatility, token prices, or protocol upgrades (e.g., v3 to v4). "Zombie" Proposal Risk: There is currently no rule preventing a delegate from taking a Snapshot vote from 2022 and putting it on-chain today, bypassing current community sentiment. Governance Clutter: It is difficult for delegates to track which initiatives are active versus abandoned. By implementing a 90-day expiration, we align Uniswap with industry best practices (e.g., Sky) and ensure that every on-chain vote reflects the current will of the DAO. 3. Specification We propose adding the following clause to the official Uniswap Community Governance Process: "Validity of Temperature Checks: A successful Temperature Check (Snapshot vote) is valid for a period of 90 days from the date the vote closes. If an on-chain governance proposal is not submitted within this 90-day window, the Temperature Check is considered Expired. The proposer must post a new Temperature Check and receive fresh community approval before proceeding to an on-chain vote." Definition of Proposal States Status | Definition | Action Required --- | --- | --- Live / Active | A proposal that has passed Snapshot within the last 90 days. | Can proceed to On-chain Vote immediately. Dead / Expired | A proposal that passed Snapshot >90 days ago but has not yet been submitted on-chain. | Must re-run the Temperature Check phase to verify current sentiment. Handling Long-Term Initiatives We recognize that major protocol upgrades or large-scale initiatives often require development timelines longer than 90 days. However, governance mandates should not be indefinite. If a proposal has passed a Temperature Check but the technical implementation takes longer than 90 days, the proposer must follow the "Re-affirmation Process": The "Refresh" Vote: The proposer does not need to start from zero with a new RFC. They simply post a "Re-affirmation Snapshot" (Temperature Check) with the final code/parameters. Why this is necessary: In DeFi, 6 months is a long time. A mandate given in January might be dangerous to execute in July if market conditions have shifted (e.g., bridge hacks, new regulation). Result: This ensures that when the final "Publish" button is pressed for the on-chain vote, the community's consent is fresh and current. 4. Rationale & Precedent This change brings Uniswap into alignment with the hygiene standards of other mature DeFi protocols. MakerDAO (Sky): Enforces a strict 30-day expiration on Executive Proposals. Optimism: Utilizes "Governance Seasons." Proposals must be submitted and voted on within a specific seasonal window. Uniswap (Current): Lacks both seasons and expiry rules, leaving the DAO exposed to "Zombie Proposals" indefinitely. 5. Comparison: Old vs. New Structure Feature | Current Uniswap Governance | Proposed New Structure --- | --- | --- Snapshot Validity | Indefinite (Technically valid forever) | 90 Days (Statute of Limitations) Stale Proposal Risk | High. A proposal from 1 year ago could theoretically be executed today despite market changes. | Low. Proposals must have a fresh community signal (within 3 months) to execute. Governance Cycle | Continuous / Unbounded | Continuous, but with a rolling expiration window to ensure freshness. Re-submission | Not defined / Confusing | Clear Process: If >90 days, you must re-post Snapshot. 6. Precedent of Risk We have already seen 'Zombie Proposals' confuse the governance process. The Gnosis Deployment (2022-2023): A deployment passed a vote but sat pending for 11 months. During that time, the bridge provider (Nomad) was hacked. The Fee Switch (2024-2025): The fee switch mandate sat dormant for over 12 months, requiring a community member to manually post a 'Re-Temperature Check' to verify if the will of the DAO had changed. This proposal removes this ambiguity. Instead of relying on the goodwill of authors to 're-check' sentiment, we enforce a hard 90-day expiry to ensure every on-chain execution represents the current will of the DAO. 7. Success Metrics Zero "Zombie" Executions: No proposals older than 90 days are executed on-chain without a fresh check. Delegate Clarity: Delegates can easily view the "active" pipeline without filtering through years of stale posts. Safety: Reduced risk of executing outdated parameters (e.g., fee switches or grant distributions based on old token prices).

[Temp Check] Protocol Fee Expansion: Eight More Chains and Remaining Mainnet v3 Pools This is the first proposal to use the new governance process approved in UNIfication. The new process only applies to fee parameter updates, where proposals can bypass the RFC stage and go directly to a five-day Snapshot followed by an onchain vote. This allows for faster updates to protocol fees, while retaining the security of onchain governance. Since UNIfication went live in late December we have been monitoring protocol fees, which were rolled out gradually to ensure protocol health. This started with v2 and select v3 pools on Ethereum mainnet. This rollout has gone well, with market-adjusted TVL up on Ethereum mainnet since December. The burn system is working as expected, permissionlessly converting fees in many different tokens into UNI burns. Now, we propose to: Expand protocol fees on v2 and v3 to Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, and Zora Enable protocol fees on all v3 pools via a new tier-based v3OpenFeeAdapter on mainnet and the above L2s Implementation Details Expand protocol fees to L2s and burn UNI on mainnet This proposal introduces v2 and v3 protocol fees on eight chains. Fees on each chain will be routed to the TokenJar on that respective chain. UNI burned on L2s doesn't stay on L2s - it is bridged back to mainnet and sent to 0xdead. This uses the same infrastructure used for burning Unichain sequencer fees (OptimismBridgedResourceFirepit for OP Stack chains, and ArbitrumBridgedResourceFirepit for Arbitrum). Enable fees on all v3 pools The current v3FeeAdapter manages protocol fees pool by pool and governance maintains a list of individual pools and their fee levels. Today, those pools account for a significant majority of v3 volume on Ethereum mainnet. v3OpenFeeAdapter replaces this with a tier-based system. Protocol fees are set uniformly across all pools sharing the same LP fee tier. For example, all 1bps LP fee pools could have protocol fees set to 25%. Any pool automatically gets the default protocol fee for its tier, no governance action is needed. This means if this proposal passes, protocol fees will be active on every v3 pool. Governance retains the ability to override fees on individual pools. Proposal Spec Pre-proposal - complete before onchain vote: ``ts /// For each L2: /// Deploy the TokenJar TokenJar tokenJar = new TokenJar{salt: SALTTOKENJAR}(); /// Deploy the chain-specific Releaser /// OP Stack (Optimism, Base, Zora, Worldchain, etc.): OptimismBridgedResourceFirepit releaser = new OptimismBridgedResourceFirepit{salt: SALT_RELEASER}(RESOURCE, THRESHOLD, address(tokenJar)); /// Arbitrum: ArbitrumBridgedResourceFirepit releaser = new ArbitrumBridgedResourceFirepit{salt: SALTRELEASER}(RESOURCE, L1RESOURCE, THRESHOLD, address(tokenJar)); /// Set the releaser on the TokenJar (must be before ownership transfer) tokenJar.setReleaser(address(releaser)); /// Set the thresholdSetter on the Releaser (must be before ownership transfer) releaser.setThresholdSetter(TIMELOCK_ALIAS); /// Transfer ownership of the TokenJar and Releaser to governance tokenJar.transferOwnership(TIMELOCK_ALIAS); releaser.transferOwnership(TIMELOCK_ALIAS); /// For each L2 and Mainnet: /// Deploy the V3OpenFeeAdapter V3OpenFeeAdapter v3OpenFeeAdapter = new V3OpenFeeAdapter{salt: SALTFEEADAPTER}(address(V3_FACTORY), address(tokenJar)); /// Set the feeSetter (must be before ownership transfer) v3OpenFeeAdapter.setFeeSetter(TIMELOCK_ALIAS); // L2 v3OpenFeeAdapter.setFeeSetter(TIMELOCK); // Mainnet /// Transfer ownership to governance v3OpenFeeAdapter.transferOwnership(TIMELOCK_ALIAS); // L2 v3OpenFeeAdapter.transferOwnership(TIMELOCK); // Mainnet /// For Mainnet only: /// Deploy the Firepit (mainnet-only releaser, burns directly) Firepit releaser = new Firepit{salt: SALT_RELEASER}(RESOURCE, THRESHOLD, address(tokenJar)); /// Set the releaser on the TokenJar (must be before ownership transfer) tokenJar.setReleaser(address(releaser)); /// Set the thresholdSetter on the Releaser (must be before ownership transfer) releaser.setThresholdSetter(TIMELOCK); /// Transfer ownership of the TokenJar and Releaser to governance tokenJar.transferOwnership(TIMELOCK); releaser.transferOwnership(TIMELOCK); ` In this proposal, if passed: `ts /// For each L2: /// Set the owner of the V3 Factory to the V3OpenFeeAdapter V3_FACTORY.setOwner(address(v3OpenFeeAdapter)); /// Set the recipient of V2 protocol fees to the TokenJar V2_FACTORY.setFeeTo(address(tokenJar)); /// For Mainnet: /// Transfer V3 Factory ownership through the V3OpenFeeAdapter v3OpenFeeAdapter.setFactoryOwner(address(v3OpenFeeAdapter)); `` Governance Process Please note that because of GovernorBravo’s limit of 10 actions per proposal, there will be two separate onchain votes posted in parallel. One proposal will include the change to mainnet’s fee controller and turn on fees on Base, OP Mainnet, and Arbitrum, the other will turn on fees on Celo, Soneium, Worldchain, X Layer, and Zora.

GFX Labs initially posted this proposal on the forum this summer and has been hoping that the quorum/delegation situation would improve. It seems to have improved thanks to the Unification initiative. Based on recent feedback from delegates, we propose renewing the Linea deployments (lapsed in May), Mantle (lapsed in August), and Gnosis (lapsed in September). The high-level reasoning to continue with these three deployments is the following: Mantle - High level of TVL ($325M), upcoming Aave deployment, and relatively high amount of activity onchain. Gnosis - Uniswap v3 is the primary DEX on Gnosis with $25M TVL. Linea - Although Consensys’ Linea has had a volatile TVL, the opportunity for Uniswap on Linea is still strong, and the potential for Aerodrome or another fork to win over the domain if Uniswap steps out is likely. Additionally, none of these deployments are available on app.uniswap.org. We already deprecated Blast and Polygon zkEVM from Oku. Both offboardings went smoothly, and we have built a tool for users to close their lingering positions on deprecated chains so they do not need to do so manually. The DAO also sponsored Taiko, but based on the activity and some delegate feedback, we will move to deprecate it. Separate from the DAO, Oku has been supporting Scroll unpaid for nearly two years. Given the limited activity, we will also deprecate the deployment in our interface. In line with historical pricing, Uniswap v3 deployments carry a $5K/month maintenance cost to cover the cloud hosting, indexing, RPC costs, support, and general maintenance. If this proposal is approved $180K from UNI will be transferred to the UAC, and the UAC will process the payment.

!image (4).png By voting “For” on this Snapshot, you are signaling support for the proposal summarized below and detailed in the forum. TL;DR Uniswap Labs and the Uniswap Foundation have created a joint proposal that activates the protocol fee and aligns incentives across the Uniswap ecosystem. We propose: 1. Turning on Uniswap protocol fees and using these fees to burn UNI 2. Sending Unichain sequencer fees to this same UNI burn mechanism 3. Building Protocol Fee Discount Auctions (PFDA) to increase LP returns and allow the protocol to internalize MEV 4. Developing aggregator hooks, turning Uniswap v4 into an onchain aggregator that collects fees on external liquidity 5. Burning 100 million UNI from the treasury, representing the approximate amount of UNI that would have been burned if fees were on from the beginning 6. Focusing Labs on driving protocol development and growth, including turning off Labs’ interface, wallet, and API fees, and contractually committing to only pursue initiatives that align with DUNI interests 7. Moving ecosystem teams from the Foundation to Labs, with a shared goal of protocol success, with growth and development funded from the treasury 8. Migrating governance-owned Unisocks liquidity from Uniswap v1 on mainnet to v4 on Unichain and burning the LP position, locking in the supply curve forever Legal Disclaimer Labs’ focus on driving protocol development and growth along with other contractual commitments will be outlined under the service provider agreement (SPA) between DUNI and Uniswap Labs. If this Snapshot vote is successful, it explicitly authorizes a special independent committee of the Uniswap Foundation, as Ministerial Agent to DUNI, to negotiate the full SPA based on the draft letter of intent. This independent committee composed of Ben Jones, co-founder of Optimism and Chief Scientist of the Optimism Foundation (disclosure: Unichain is built on the OP Stack and a part of the Optimism Superchain), and Hart Lambur, co-founder of the Across Protocol and UMA Protocol, will be appointed by the Foundation to lead negotiations on behalf of DUNI. The final negotiated agreement will be provided prior to the full onchain vote and executed by DUNI upon its passing. A successful onchain vote would also constitute DUNI’s agreement to indemnify the independent committee and its members. An indemnification agreement would be provided at the time of the onchain vote for DUNI review and approval, along with the fully negotiated SPA. We recommend everyone read the proposal in full. The summary above is intended to provide a high-level overview of key points in the proposal, and is not a substitute for reading the full proposal.

Summary & Motivation GFX Labs and its team have participated in protocol governance for over four years. In fact, Getty’s first governance proposal was a Compound Crowd Proposal, also known as a Compound Autonomous Proposal (CAP), in September 2020. At the time, to make a Compound Proposal a contributor needed 100k COMP (~$14m) votes. While that was unattainable for most contributors, CAPs allowed anyone with 100 COMP ($14k) to make an Autonomous Proposal. At its core, a CAP allowed smaller users a path to make a proposal through the primary governance contract by first proposing it to the CAP. Once the CAP was created, the creator needed to lobby community members to delegate their voting power to the CAP, and once that voting weight reached 100k, it was eligible to become a proposal for the DAO. In concept, CAPs were a great solution to get small, intelligent, and valuable participants engaged in protocol governance. Most delegates, however, could not delegate their COMP tokens to a CAP. Unfortunately, because delegations cannot be re-delegated except by the token holder, CAPs only democratized proposal power at the margins. We’ve also seen this at Uniswap for those who remember fish.vote. To solve this problem, we are introducing the Community Proposal Factory (CPF), the modern version of a CAP, which can propose, and then support by voting upon, a proposal by first clearing a lower-level vote. Overview The CPF is effectively a subDAO of a larger protocol with a significantly lower proposal threshold. Anyone who meets the proposal threshold can create a Community Proposal. This can be thought of as a proposal seeking to attract and pool the voting power of multiple UNI holders and delegates to meet the proposal threshold. If the Community Proposal receives a sufficient number of votes to initiate a standard proposal, the CPF pushes the proposal to the primary governance contract as a standard proposal, and at that point, governance proceeds as it does today. This structure removes the need for new delegations to be made for each CAP, and instead, governance token holders may leave their delegation on the CPF. Community Proposal Factories effectively lower the proposal threshold without an increase in security risks to the DAO. In doing so, we feel Community Proposals will represent a big step in democratizing proposal power. Once deployed, anyone can craft a proposal with executable code without needing a large amount of capital (or commanding the delegated votes of a large amount of capital), and the broader governance tokenholder community can judge whether the proposal should advance to a full vote. It also filters spam proposals before hitting the main voting venue, since it is optional for UNI holders and delegates to vote on a Community Proposal. The Community Proposal Factory is compatible with Governor Bravo-based DAOs and can be easily deployed by anyone. Each deployer can configure the factory to their DAO, requiring only minor configurations. In addition, this concept could be applied to other common governance frameworks such as OpenZeppelin’s Governor. Deployed CPFs can spin up an interface easily using Tally. !Screenshot 2025-09-29 at 7.51.09 PM.png The above diagram is an example of how a Community Proposal Factory could be applied to Uniswap. In this example, the factory is deployed with the Uniswap Governor Bravo contract as the parent DAO contract, the UNI token as the governance token for the factory, a proposal threshold of 100 UNI votes, and a quorum of 10M UNI. Anyone with 100 UNI can create a Community Proposal within the CPF. Similar to a regular vote, if the proposal reaches the necessary quorum (10M UNI), then the proposal is deemed successful. If the proposal is successful and if the Uniswap CPF has the required voting power delegated to it, the execute function will create the proposal on the Uniswap Governor Bravo contract, and then vote in favor of it when the voting begins. At this point, the governance process is identical to any other vote. The proposal will go through the standard review, voting – and, if successful – timelock before execution. Because the CPF is self-contained and cannot pass a standard proposal more easily than a human delegate, funds & protocol functions are not believed to be at increased risk. As a result, we do not believe the expense of an audit is required, but we can add additional funding to the proposal to cover one if delegates are strongly in favor. Initial parameters (review period, voting period, timelock) within the CPF will be within standard governance practices, and can be fine-tuned for the final Tally vote if delegates have strong opinions. Multiple proposals are queued for submission to Governor Bravo in order of their passage at the CPF level. Should a backlog of proposals by the CPF to Governor Bravo be expected, multiple CPFs could be deployed, requiring additional treasury delegation. Deployment 1. Configure CPF and deploy. Anyone can do this, and you only need to do it once. Parameters such as the proposal threshold and quorum can be changed by the CPF’s voters. 2. Delegate 20M UNI from the DAO treasury to the CPF to ensure not only the ability to propose, but also end quorum failures due to low active voting supply. Proposal Process 1. Anyone with 100 UNI votes can post a Community Proposal to the CPF. 2. UNI voters can vote on CPF proposals if they wish. If the For votes cast meet or exceed the 10M UNI quorum and outnumber the Against votes, then the proposal can be proposed by the CPF to the Uniswap governance contract. At this point, the CPF must have the sufficient votes delegated to it to make the proposal on the parent contract and must maintain the voting power for the duration of the standard proposal. 3. After the standard proposal is made, it is up to the DAO’s standard process to determine if the proposal is executed. Specification 1. GFX Labs or another contributor will deploy a Community Proposal Factory for Uniswap. 2. Uniswap governance delegates 20M UNI from the DAO treasury to the CPF via the franchiser. 3. Uniswap governance provides $75,000 in UNI to gfxlabs.eth to cover the expense of development and testing. The Community Proposal Factory will safeguard the ability to continue protocol governance while maintaining the security and integrity of the DAO. By streamlining the process for smaller token holders to introduce executable proposals and aggregate support, the CPF empowers a broader range of contributors without requiring prohibitive amounts of capital or delegation. Ultimately, the CPF strengthens community engagement, filters low-quality proposals, and provides lubricant to the gears of Uniswap governance, helping to mitigate the ongoing attrition amongst active voting supply.

Voting Options: Allocate $250k, Don’t Allocate, Abstain —-------------------------------------- This post intends to accomplish two purposes: Publicly signal the UAC’s intent to eventually allocate $250k from the incentives discretionary budget to the Plasma deployment. This is tranche 1. Collaborate with Plasma to request an additional $250k from the treasury via the customary governance path (RFC, Snapshot, Onchain vote). This vote pertains to tranche 2. READ THE FULL PROPOSAL ON THE FORUM. Incentive Structure & Timing: Goal: Plasma allocates $3-5M in XPL incentives over 6 months, while Uniswap co-incentivizes with $500k UNI. Plasma’s commitment: Deploy up to $5M in incentives over six months, tied to the XPL token price. A minimum of $500k/month is guaranteed, ensuring at least $3 million total if XPL declines. Uniswap’s discretionary tranche ($250k): Allocated from the UAC’s incentives discretionary budget. Currently unallocated due to pending legal review. Catch-up mechanism: Once the UAC is able, it will “catch up” to Plasma by distributing the full $250k within the remaining months (e.g. if legal review takes 1 month, the UAC will allocate $50k/month over 5 months instead of $41.6k/month over 6). Parallel Plasma incentives: Plasma agreed to begin allocating incentives on day-one, before the DAO is able to allocate capital on its end. XPL incentives have been live since September 25 and can be viewed here. TVL has currently reached $56M, with over $1B in volume since launch. Second tranche ($250k): The discretionary budget has a $250k cap, so we are requesting a $250k match from the DAO treasury. This snapshot pertains to the second tranche. Allocation Breakdown: Once able, Uniswap will begin abiding by the following allocation: XPL/USD₮0 - 20% of incentives USDe/USD₮0 - 25% of incentives ETH/USD₮0 - 25% of incentives weETH/USD₮0 - 20% of incentives XAUT/USD₮0 - 10% of incentives Uniswap's allocation will differ from that of Plasma, which has a heavy focus on XPL/USD₮0: XPL/USD₮0 - 70% of incentives ETH/USD₮0 - 10% of incentives weETH/USD₮0 - 10% of incentives XAUT/USD₮0 - 10% of incentives Some of the Plasma incentives may also be allocated to pools focused on ecosystem-native assets such as Axis, Daylight, Uranium Digital, and other unannounced issuers.

This proposal (Link Here) represents the second of two phases of the Treasury Delegation Round 2 application process, the election. The following nominees have been validated as eligible for inclusion during the first application phase. Voting Process: The DAO will allocate voting power to each candidate as it sees fit. At the end of the voting period, all delegates will be ranked in order from the most to the least votes received. Sequentially from the top of the list to the bottom, each delegate will receive delegated voting power up to the point at which they individually hold 2.5M total VP. Then, the process repeats for the next delegate, and the next, until all VP has been allocated. Self-Voting Policy: Because this election is not for a finite number of seats, and it is best to encourage broader distribution of votes, self-voting will not leverage the max-matching model seen during committee elections. Instead, each voter will be eligible to commit a maximum of 25% to himself or herself and distribute the remainder as they see fit. Violation Policy: If a delegate violates the self-voting policy, the portion of their voting power allocated to themself will be considered void. Any portion allocated toward other delegates will persist. Ranking and Distribution Calculations: After election closure, all nominees will be ranked in order of most to least votes received, and the waterfall voting power distribution discussed in the GLI forum post will be calculated. Dispute Window: The UAC will share the distribution results and provide a 3-day dispute window. On-chain Vote: Shortly following the closure of the dispute window, the UAC will publish the final on-chain proposal.

Background: Beginning in June, the UAC internally recognized votable supply, which at the time stood at ~41M UNI (relative to the 40M UNI quorum), as a potentially imminent and systemic risk to the DAO. In response, and in efforts to protect the DAO, the UAC proactively began the first Governance Logistics Improvement research report and RFC. The report sought to identify the greatest issues Uniswap governance faces, with particular emphasis on votable supply as it pertains to quorum… To address this mounting issue, the UAC invoked an open call for community-sourced solutions. This call resulted in five potential pathways, which were then aggregated and presented to the community. Of those five proposed solutions, two have emerged with majority support within the forum discussions: Treasury Delegations and Incentivized Delegation Vaults. (Governance Logistics Improvement) This proposal addresses Incentivized Delegation Vaults. UAC Next Steps: UAC: With regards to IDVs, the UAC will serve under the DAO’s guidance as the program manager of the Incentivized Delegation Vault initiative, should it pass (detailed below). Author: Event Horizon Proposal Summary: Incentivized Delegation Vaults: Multiple delegates recognized that it is not healthy for the governance ecosystem if the entirety of the votable supply is sustained by treasury delegations alone. As such, encouraging community delegations is essential. The most direct and intuitive approach is to incentivize participation. IDVs offer a low-touch, plug-and-play approach to facilitate this. Each eligible delegate will receive their own IDV. Delegators to each vault will receive emissions passively once delegated. The objective of IDVs is to, at a minimum, close the 9M UNI shortfall. !i1.png Proposal Configuration: Unique Vaults for Every Delegate: Each eligible delegate will receive their own branded vault. Once created, these vaults will allow UNI token holders to earn reward emissions for delegating voting power to any branded delegate vault. No cost or obligations will be incurred by the delegates. Eligibility: Treasury Delegation Candidates: Any delegate who qualifies for treasury delegations (regardless of whether they ultimately receive treasury delegations). Delegate Compensation Applicants: Any delegate who applied for the Delegate Reward Initiative cycle 4. Application Process: There will be an additional vault application thread where eligible applicants will be able to express their interest. User Experience: IDVs simply track delegation activity on-chain, specifically who delegated to whom and how much, and emit weekly airdropped rewards to participants in exchange for delegating to eligible delegates. There is no transfer of assets, depositing or contract interactions necessary for claims. Flat Rate Emissions: A flat rate emission will be provided to depositors into any vault. Ex. Assuming an APR of 2%, if there are 10 delegate vaults, with 1,000 UNI delegates across them in any distribution, each UNI delegated will earn 0.02 UNI per year, regardless of which vault it is held in. Security: Tokens never leave the users’ wallets. Delegation through IDVs is fully non-custodial. Users maintain complete control over their assets and are rewarded solely for delegating, not for transferring or locking tokens. Delegation is executed via a signature-based function call on the Uniswap token contract. Starting Program Configuration: Target Delegations: 9,000,000 UNI Starting APR: 2% APR Rationale: Assuming Treasury Delegations pass, the shortfall in delegated UNI is projected at ~9M UNI. At present, UNI has few, if any, single-sided, low-risk yield opportunities. A 2% APR is therefore considered sufficient to incentivize participation without excessive emissions. At 2%, the one-year value of a single delegated UNI is 0.02 UNI per annum. Note: Because delegations will not materialize immediately at full scale, actual emissions may grow gradually, extending the budget’s effective duration beyond one year. KPI: Emissions operate on a flat-rate model: every UNI emitted definitionally secures the exact amount of delegation value the DAO seeks. This design and commitment to flat vs variable APR eliminates the risk of “overspend” or “underspend”: If more UNI is delegated, emissions scale up. If fewer UNI are delegated, fewer UNI are emitted. The sole KPI for program management is therefore to maintain an average APR at the DAO-approved target rate (e.g., 2%). This is achieved through straightforward accounting and strict adherence to the DAO mandate. In short, performance to emissions is guaranteed by design; the program succeeds whenever the agreed APR is consistently maintained. Budget: 18,200 UNI Initial Build: 5,000 UNI – A one-time allocation that covers the full build and instantiation of the product. This is released by the UAC at the point at which the product is functioning as noted by the launch of the first, or first batch, of delegate-branded IDVs. Year 1 Development and 2 Years of Maintenance: 13,200 UNI provides for one year of ongoing development and maintenance. Event Horizon will guarantee active development during the first 12 months. This may include, as reasonable, the incorporation of on-chain delegate metrics and requirements, integrations with approved third-party products, adjustments to the emissions model, and other DAO-requested improvements deemed beneficial. Event Horizon further commits to up to an additional 12 months of general product operation and maintenance beyond the 1-year payment term. Note: The Event Horizon team aims to serve as a transparent, consistent, and reliable builder for the Uniswap community alongside other recognized names, such as Oku, for years to come. In that spirit, we approached valuation in an effort to both allow for operational viability and continued future work/value provision for the DAO and to be respectful and reasonable in what we ask of the DAO. Our reasoning landed as follows: From the DAO’s perspective, there is clear value in expanding the votable supply. This is abundantly evident by the current >$200m quorum deficit. But it also strengthens Uniswap’s governance by reducing vulnerability and prevents future bottlenecks in decision-making. From the individual delegate’s perspective, IDVs create tangible value by supporting their community involvement and in directly expanding their delegation through incentives. To ground the valuation of governance participation, we looked at existing precedent: the delegate reward initiative. At current UNI prices, each compensated delegate receives ~600 UNI/month, while the average compensated delegate maintains ~1M UNI in delegations. In other words, consistent participation of ~1M UNI is currently valued by the DRI at ~600 UNI/month. The IDV program is designed to mobilize up to 9M UNI. If even 10% of this target is reached (900K UNI), the mobilized voting power is equivalent to that of a compensated delegate presently valued at 600 UNI per month. At full capacity, IDVs nearly match the voting power of every compensated delegate combined, which currently represents a cumulative value of ~9,000 UNI per month. Importantly, this added voting power also improves the cost efficiency of the reward initiative itself, since every compensated delegate will be eligible for their own vault and therefore become the direct recipients of the delegations driven by IDVs. The same delegates, being paid the same amount from DRI, are now mobilizing a much more impactful benefit to the DAO. The entire program’s total cost nets to ~750 UNI/month, or approximately the cost of a single compensated delegate. This is factoring in not just mobilized voting power but also upfront build costs, benefits to individual delegates, and ongoing maintenance and evolution. Treasury Earmarked for Possible Emissions: 180,000 UNI The UAC will custody 180,000 UNI for potential future emissions. This amount represents the maximum reserve required to support up to 9M UNI delegated for one year at a 2% APR. !i2.png Proportional Scale !i3.png Re-Scaled Key points on Emissions: Flat-Rate Emissions: Each UNI emitted has a consistent marginal value. For example, at a 2% APR, every 1 UNI emitted secures 50 UNI in delegation for at least one year. Not a Committed Expense: The 180,000 UNI is an earmark, not a guaranteed outlay. Actual emissions will depend on delegation uptake, which is expected to ramp gradually rather than begin at full scale. The UAC only emits an amount of UNI directly proportional to the amount of value (in the form of delegations) that the delegates, and thereby the DAO, have gained through the vaults. As depicted above, it is a direct trade-off between delegations and UNI emissions at the exact value exchange rate determined and managed by the DAO. Conservative Buffer: While it is unlikely the full 9M will be delegated immediately, holding the full earmark avoids the need for a risky “top-up” proposal under sub-quorum conditions. Non-Dilutive: It is important to distinguish these emissions from other programs, such as LP incentives, in that the emissions are exclusively dedicated to UNI token holders. Any token holder who helps secure the DAO receives their share of emissions. As such, dilution is fully avoidable. And, contextualized at scale, even at its fullest emission rate, it represents ~0.034% in completely avoidable dilution annually. DAO Flexibility: Any unused portion remains in UAC custody and ultimately under DAO control, to be reallocated or repurposed as the community decides. (See Forum For Full Proposal…)

Background: Beginning in June, the UAC internally recognized votable supply, which at the time stood at ~41M UNI (relative to the 40M UNI quorum), as a potentially imminent and systemic risk to the DAO. In response, and in efforts to protect the DAO, the UAC proactively began the first Governance Logistics Improvement research report and RFC. The report sought to identify the greatest issues Uniswap governance faces, with particular emphasis on votable supply as it pertains to quorum. Notably, the report emphasized that “the DAO operates under an unspoken dependency: that nearly all of its top delegates will participate in every vote, without exception. Put plainly, the exit of even a single large voter could bring governance to a standstill. Further, the risk of delegate removal from the voter body is not hypothetical; we’ve already seen this dynamic unfold as several institutional actors have scaled back participation in response to regulatory pressures.” Incidentally, during the initial weeks of research, that dependency risk became a material reality as changes in the token custody process led to A16Z’s removal of ~20M UNI from delegation. As it stands today, the consistently active votable supply stands at just 21M UNI. This is just 52.5% of the required 40M UNI quorum, or approximately a $209 million vote deficit. While the UAC strongly believes that, for now, critical proposals will pass through the direct support of large, less active voters, such as A16Z, broader community governance risks grinding to a complete halt. To address this mounting issue, the UAC invoked an open call for community-sourced solutions. This call resulted in five potential pathways, which were then aggregated and presented to the community. Of those five proposed solutions, two have emerged with majority support within the forum discussions: Treasury Delegations and Incentivized Delegation Vaults. (Governance Logistics Improvement) This proposal addresses Treasury Delegations. UAC Next Steps: UAC: The UAC has reviewed and endorsed the above research and RFC, as well as the conceptual solutions which the community generally agreed upon (Treasury Delegations + Incentivized Delegation Vaults). Given there is no counterparty to do so, the UAC will directly champion the push forward of the Treasury Delegations proposal and its implementation should it pass. With regards to IDVs, the UAC will serve under the DAO’s guidance as the program manager of the Incentivized Delegation Vault initiative, should it pass (detailed below). Author: UAC ( Doo Wan Nam (@Doo_StableLab) | Jordan Karstadt (@DonOfDAOs) | @AbdullahUmar | PGov (@Juanbug) | @alicecorsini ) Co-Author: Tane Proposal Configuration: Temperature Checks: Following the posting of this proposal draft, the UAC will publish the TD temperature. Event Horizon will publish the IDV forum draft shortly, and eventually, the temperature check. On-Chain Vote: Should TD pass, the UAC will publish the on-chain vote. Should IDVs pass, Event Horizon will publish the on-chain vote. Proposal Summary: Treasury delegations have received nearly universal support, given their direct method of addressing the votable supply shortfall and proven historical precedent and track record. In fact, today, half of the remaining votable supply is directly sourced by the previous treasury delegation round (Governance Logistics Improvement) . The UAC recommends the following configuration: Delegation Amount: 10M UNI This proposal will instantiate an additional 10M UNI in delegations from the treasury to community delegates. This will bring the resulting votable supply to ~31M UNI, or just ~25% below the required quorum. Relationship to Treasury Delegation Round 1: Additive This round will not revoke, supersede, change, or otherwise impact the continuation of the 10M UNI previously delegated during the last treasury delegation round. As a result, the cumulative treasury delegated UNI will stand at 20M UNI. Delegation Cap: 2.5M To avoid excessive consolidation of voting power, no round 2 applicant may accrue greater than 2.5M UNI in total voting power (be it from the treasury or otherwise) as a result of this round. Ex. if an applicant holds 1M UNI in delegations, the most they stand to receive from this program is an additional 1.5M UNI in delegations. The remainder will waterfall to the next most eligible candidate. Eligibility: Objective Metrics for Nomination + Election for Distribution Application-based: Delegates will submit an application demonstrating their interest in being included in the treasury delegation round. The UAC will submit a forum post soliciting applications from eligible entities. Eligibility to Apply: Look Back Window: 3 Months On-chain Voting Participation: 75% minimum Off-chain Voting Participation: 75% minimum Final Selection Process: Election The DAO will vote for its preferred delegates from the pool of eligible candidates. Technical Implementation: Franchiser An identical approach to round one. A full review by Chainsecurity on the Franchiser contracts can be found here. Distribution Model: Waterfall Each eligible candidate will be listed on the election snapshot vote. The DAO will allocate voting power to each candidate as it sees fit. At the end of the voting period, all delegates will be ranked in order from the most to the least votes received. Sequentially from the top of the list to the bottom, each delegate will receive delegated voting power up to the point at which they individually hold 2.5M total VP. Then, the process repeats for the next delegate, and the next, until all VP has been allocated. Self-Voting: Because this election is not for a finite number of seats, and it is best to encourage broader distribution of votes, self-voting will not leverage the max-matching model seen during committee elections. Instead, each voter will be eligible to commit a maximum of 25% to himself or herself and distribute the remainder as they see fit. Selected Delegates’ Responsibilities: Each delegate elected by the DAO, who will receive the treasury delegation, should maintain the following requirements: Maintain a minimum 80% voting participation rate over the past 3 months. Includes: both Snapshot and on-chain proposals Excludes: cancelled proposals Measured from the date of Snapshot approval Program Management: The UAC will post a report every 3 months detailing the participation record of each delegation recipient, along with other relevant program information. Delegates who fail to meet the minimum participation requirements will have their delegations revoked via an on-chain voting. In the event of a revocation, the removed delegation will then be distributed in the same fashion as the initial waterfall design. The next highest scoring candidate will receive an increase in delegation up to the point at which they reach the 2.5M cap. If there is still voting power to distribute, it will then go to the next candidate. If all candidates have already met their 2.5M cap, the UAC will contact the first runner-up from the original election for inclusion into the program. If the first runner-up declines, cannot be contacted, or meets their 2.5M cap before the redelegated amount has been exhausted, the process continues sequentially through the following runner-ups. Delegate Principles: All delegation recipients will be expected to review and uphold the delegate principles as ratified here: https://www.tally.xyz/gov/uniswap/proposal/78

Overview This proposal advocates for an official UniswapV3 deployment on Ronin along with a co-incentivization campaign to establish UniswapV3 as a primary DEX in the Ronin Ecosystem. All contracts necessary for Uniswap v3 deployment will be managed under Uniswap’s governance control. To bootstrap liquidity, in combination with the migration of POL and chain-owned liquidity from the Katana DEX to Uniswap v3, Ronin proposes a $1M contribution in RON tokens, matched by $500K in UNI tokens from the Uniswap DAO. Historically, Ronin has prioritized Katana DEX as its primary trading venue but is now shifting its focus towards making Uniswap v3 its canonical DEX. Further details on the Ronin chain and its refreshed 2026 roadmap can be found in the RFC: https://gov.uniswap.org/t/rfc-deploying-uniswap-v3-on-ronin-with-co-incentives/25810 --- Key Mutual Benefits of Deployment 1. Ecosystem Expansion (Gaming x DeFi) Bringing Uniswap v3 to Ronin strengthens the DeFi offering within the largest Web3 gaming ecosystem. Ronin is actively innovating on new game loops that plug directly into DeFi primitives to seamlessly onboard the millions of active gamers into DeFi. 2. High Demand and Engagement With 700K+ Discord members, 2,500+ content creators, and 300K newsletter subscribers, Ronin’s hyper-engaged community presents fertile grounds for rapid liquidity bootstrapping. 3. Bootstrapping Uniswap v3 Ronin looks to position Uniswap as the chain’s primary trading hub. Sky Mavis is in-favor of migrating chain-owned liquidity, incentive provisions, and heavy marketing support. 4. Historical Success with Uniswap In 2021, prior to the launch of Ronin’s homegrown Katana DEX, Ronin gaming tokens such as AXS and SLP had staggering trading volumes on Uniswap generating millions in LP fees while attracting over a million unique wallets to Uniswap. 5. Access to Unique Assets Ronin’s unique edge is fostering the development of massive player-owned economies, With an average of 500K DAU across dozens of titles, Uniswap’s v3 will be the trading hub of these game tokens. 6. Aligned Incentives The proposed matching structure ($1M in RON + $500K in UNI) ensures both parties share risk and reward, following proven co-incentive models used in previous network expansions. 7. DeFi on Ronin As the Ronin ecosystem opens its doors to DeFi, Uniswap v3 work in synergy with other blue chip dApps and platforms such as Compound Finance, Morpho, Merkl, Impossible Finance, Steer, and Liquity v2 - with more on the way. 8. The DeFi Home of the Philippine Peso Stablecoin (PHPC) In collaboration with coins.ph, Ronin looks to position itself as the DeFi hub of PHPC. Multiple in-game integrations, lending market listings, incentivized DEX pools, and real-world payment integrations are in the works. Ronin will be the most exciting chain for PHPC token utility. --- Proposal Stakeholders Proposer: Sky Mavis Deployer: GFX Labs Bridge Provider: Wormhole Target Chain: Ronin Front-end: Oku Proposal Sponsor: PGov --- ⏱ Proposal Plan / Timeline 1. Request for Comment – 1 week (22nd Aug 2025) 2. Community Snapshot Check – Gauge community support in deploying Uniswap v3 on Ronin with $500k of UNI incentives to match Ronin’s $1m commitment (Aug 2025) 3. Deployment: GFX will deploy Uniswap v3 on Ronin on the Oku frontend (Sept 2025) 4. On-chain Vote – If Snapshot passes, an on-chain proposal will be created (Aug 2025) 5. Deployment & Incentive Distribution – Should the on-chain vote pass, we will work with the Accountability Committee to distribute the $500k if matched UNI and the Uniswap Growth Program to allocate the $1m of RON --- Incentive Plan Uniswap DAO Match: 500K in UNI tokens distributed via liquidity mining over 6 months from the date of launch Ronin Contribution: $1M in RON tokens Monitoring Metrics: TVL, trading volume, LP retention, wallet activity — tracked via public Dune dashboards and posted monthly on the UEII thread. UNI Incentive Allocations: 75% of the 500K in UNI tokens will be distributed to token pairs that include BTC, ETH, Stablecoins, and their derivatives. 25% of UNI incentives will be allocated to top-performing gaming token pools. This ensures that depth is created for blue chip asset pairs, while simultaneously strengthening trading experiences for gamers and speculators. We will work with the Uniswap Growth Program to iterate on distribution details as the program progresses, collaborating with necessary partners like Merkl and various ALMs. --- Governance and Oversight Deployment oversight will be managed by the Uniswap Accountability Committee, along with escrow of DAO-owned funds intended for incentivization purposes. The incentives proposal is being presented to the DAO prior to the deployment of the v3 contracts by the Oku team due to strategic timing purposes. Ronin would like to align efforts around marketing the v3 deployment with simultaneous incentive opportunities for LPs via the Ronin’s DeFi Blitz incentive program. Having $UNI and $RON incentives live at the same time as the v3 contract deployment will send a strong signal of unity to the community and supercharge the incentive program to bootstrap the Uniswap v3 pools with greater efficacy. If this incentives proposal were to fail, the v3 deployment will still take place, however, incentive allocation on the Ronin side will not be guaranteed.

Summary The Uniswap Foundation (“UF”) proposes that Uniswap Governance adopt a Wyoming-registered Decentralized Unincorporated Nonprofit Association (“DUNA”) as the legal structure for the Uniswap Governance Protocol. This new legal entity, called “DUNI”, will be purpose-built to preserve Uniswap’s decentralized governance structure while enabling engagement with the offchain world (e.g., entering into contracts, retaining service providers, and fulfilling any potential regulatory and tax responsibilities). If adopted, DUNI will be a legal entity for Uniswap Governance that recognizes the binding validity of onchain Governance Proposals with the intention of providing certainty regarding its legal structure and intended liability protections for members of DUNI. Adopting DUNI does not, in any way, alter the Uniswap Protocol, the UNI token, or the core mechanics of onchain governance. Rather, it represents a significant step in equipping Uniswap Governance for the future. Importantly, establishing Uniswap Governance as a DUNA would bolster critical limited liability protections for governance participants. This step is intended to protect governance participants from potential personal exposure to possible legal or tax liabilities stemming from the collective action taken by Uniswap Governance. This is a critical step in de-risking engagement in Uniswap Governance without compromising decentralization. Background & Motivation In the Uniswap Unleashed roadmap, we described a vision for evolving Uniswap Governance. In this vision, Governance can turn on the protocol fee, fund innovation, form partnerships, and navigate legal obligations with confidence. While onchain governance is integral to Uniswap’s credible neutrality, it has historically lacked the corresponding infrastructure for basic offchain coordination and formalized protection for its collective actions. To execute on our vision, we need something more. To that end, over the past two years, the Uniswap Foundation has explored options for establishing a legal structure that is intended to: Provide more clarity regarding liability protection for Uniswap Governance participants; Maintain the primary authority of the Uniswap Governance protocol; and Enable execution of offchain operations without introducing centralized points of control. After significant research, legal consultation, and community engagement, the Wyoming DUNA (passed into law in 2024) emerged as a credibly neutral and transparent option. It has been explicitly designed for decentralized protocol governance systems to gain legal legitimacy without compromising their core ethos. In our research, we have worked closely with a firm called Cowrie, founded by David Kerr. Based in Cheyenne, Wyoming, Cowrie is composed of a team of regulatory and technical experts that provides legal, financial, and administrative support to decentralized protocols. David was instrumental in writing Wyoming’s DUNA statute, and has worked directly with legislators to educate them on the intricacies of the DUNA, what it enables DAOs to accomplish, what DAOs are, why decentralization is important, etc. Cowrie’s role in the context of DUNI is to act as an Administrator of DUNI - facilitating regulatory and tax compliance, tax filings, informational reporting, and operational infrastructure within the constructs of its authorizations. Specification If this proposal passes, the resulting onchain transaction will adopt a DUNA for Uniswap Governance. Specifically, it will: Ratify the DUNA’s Association Agreement establishing the rules of DUNI; Execute a Ministerial Agent Agreement with the Uniswap Foundation; and Execute an Administrator Agreement with Cowrie - Administrator Services; This includes the execution of a separate Administrator Agreement with David Kerr (CEO of Cowrie) for specific authorizations. Additionally, the transaction will execute two transfers of UNI from the treasury, specifically: $16.5m worth of UNI to a DUNI-owned wallet to prefund a legal defense budget and a tax compliance budget; $75k worth of UNI to Cowrie for their services as compliance administrator. All supporting documentation can be found on the UF's website here.

Uniswap Delegate Reward Initiative - Cycle 4 Authors: @Doo_StableLab @PGov @AranaDigital @seedgov !AD4nXds4EPLs4TfuPYDacVihDk88smRJZ58HQ0PyvIaHWm4VbLsJjjU7460oYFufJTRY8LV-R2GqSeshizBT1duYUdfMdsjNYglNg96LyQ73qHZwLL2SzlOE6fq7Yz67heGZmLqPcZYA.png Summary This proposal outlines the Uniswap Delegate Reward Initiative—Cycle 4, a compensation program designed to improve and sustain the participation quality and dedication among Uniswap delegates following the conclusion of Cycle 1, 2, and 3. Due to character limit on snapshot, background has been removed. Please check on the forum for the background. ... The significant change for Cycle 3 is an introduction of Delegate owned UNI token to reflect on requests from several Uniswap DAO members during the Cycle 3 debate (the debate on this topic) for experimentation. For this cycle, the basis will be 1,000 UNI token (<$10k of August 2nd price). Delegates who hold 1,000 UNI or more would be able to get a small additional point on the application and will be the basis for getting 100% of the Uniswap Delegate reward once accepted. Details on how UNI ownership is determined is explained below in “Uniswap Delegate Reward Cycle 4 Metrics.” We believe experimenting with such can potentially address the question of delegates having more “skin in the game.” ... Cycle 4 Proposal Details Application Eligibility There will be a week-long period for candidates to submit their applications. The top 15 delegates will be determined based on a point system outlined below. Delegates from Cycle 3 must apply again for Cycle 4–they will not be automatically included. Only delegates who have participated in onchain voting for at least three months prior to the application post are eligible for Cycle 4. Uniswap Delegate Reward Cycle 4 Metrics In case there are more than 15 eligible applicants, the top 15 will be chosen by the following objective metrics. The highest number of available points will be 13. There will only be one wallet used for tracking for such metrics unless a Delegate has communicated on their delegate platform on the forum that the voting address will be changed at the time of change. In case of if the Delegate did not communicate such change on the delegate platform on the forum, the Delegate applicant can only choose one wallet to be used for evaluating for the metrics. Applicants will also need to agree to follow Principles for Uniswap DAOto be eligible. 1. Voting Participation Since a delegate’s primary role is to utilize voting power from delegators and vote in Uniswap’s best interest, active participation is essential to ensuring quorums are met and malicious proposals are thwarted. This category carries a total of 7 points, with onchain voting weighted more heavily due to its ability to directly impact governance contracts and direct treasury funds. The voting rate is evaluated based on the past six months. Offchain Voting (Snapshot) 90% and above: 3 80% to 90% : 2 70% till 80% : 1.5 60% till 70%: 1 50% till 60%: 0.5 50% or below: 0 Onchain Voting 90% and above : 4 80% till 90% : 2.5 70% till 80%: 1.5 60% till 70%: 1 50% till 60%: 0.5 Below 50%: 0 2. Proposal Authorship Contributing to proposal drafting for Uniswap DAO is valuable, but maintaining quality and preventing malicious proposals is equally important. As a result, only successfully passed votes are counted. This category is worth a total of 3 points, with onchain proposals receiving greater weight once again. For non-binary proposals, if a “No” equivalent option was available and the final voting outcome was a choice other than “No,” the proposal qualifies for points in this category. For example, the Uniswap Treasury Working Group (UTWG) Election would not be eligible, as there was no “No” vote option. However, the [Temp] Uni Onboarding Package - BSC would qualify, since an “Against” option was present, and the final outcome was “$1M.” Only the sole author or co-authors explicitly mentioned on the proposal will receive credit. Authored or Co-authored a proposal that passed offchain (Snapshot) vote before. Yes, 2 or more: 1 Yes, 1: 0.5 No: 0 Authored or Co authored a proposal that passed onchain vote before Yes, 2 or more: 2 Yes, 1: 1 No: 0 3. Community Participation The full point for this category is 1. Community Calls (March - August 2025) Attended at least 80% of calls: 1 Attended at least 50% of calls: 0.5 Attended less than 50% of calls: 0 4. Delegate Owned UNI Token The full point for this category is 1. Blockchain signatures are required so Delegate can prove that Delegate has ownership of UNI Token. In addition, UNI token delegate claims to own must be delegated to the applicant delegate. One needs to have 1,000 UNI or more and have blockchain signature that verifies ownership from the wallet that holds 1,000 UNI or more by the time the applicant applies to gain extra 1 point in applications. Ex) If StableLab wants to receive full point for this category, StableLab needs to hold at least 1,000 UNI, share in the application the wallet address where 1,000 UNI is being held, sign blockchain signature that confirms that the wallet belongs to StableLab and from that wallet address must delegate to StableLab. To qualify for this 1 point, the delegated owned 1,000 UNI must remain at least until the verification process is completed and the application results are announced. Delegate owns 1,000 UNI and is delegated to Delegate applying Yes: 1 No: 0 5. Perfect Participation The full point for this category is 1. Delegates with participation over the past 6 months: Voted in 100% of the proposals (both on Snapshot and on-chain), submitted rationale for 100% of their votes in time (7 days from the end of each vote), attended 100% of the community calls. Yes: 1 No: 0 Tie Breaker Ties will be decided by the date of the first onchain vote that these applicants cast in order to reward delegates who have been contributing to Uniswap governance for an extended period. The tie-breaking value will be determined based on the end date of the vote in which the delegates participated, not the onchain date when the vote was cast. In the event of a tie with the first tie-breaker criterion, priority will be given to the delegate who has cast the most votes in the last 6 months. In the event that the tie persists further, the final decision will favor the delegate who was first to present their delegation platform—hence, priority will be given to the individual/entity who first publicly declared their intention to become a delegate. Delegate Reward Eligibility Once delegates have passed the application process, they must fulfill the following requirements to be eligible for up to $6,000 USD worth of $UNI reward per month. Requirements Maintain a minimum of 80% participation in onchain and off-chain voting during the last 3 months to be eligible to receive up to $3,000 worth of $UNI per month, with the proportional payment based on each delegate’s participation in the total votes cast during the last 3 months (number of votes cast x 100 / total votes cast during the last 3 months). For example, if there were 10 votes cast in the last 3 months and a delegate voted on 8 of them, that delegate will receive 80% of the $3,000 USD, i.e. the delegate will be eligible to receive $2,400. If another delegate voted on 7 of those votes, that delegate will not be eligible to receive any rewards as their participation was 70% of the votes, below the 80% minimum. Additional Rewards (the below are only available if the above Requirement of Voting Participation is fulfilled) 2a. Write rationale for the voting on their delegate profile. -Deadline for writing rationale would be 7 days from the end of each vote. 2b. Attend Uniswap Community Calls. 2c. Maintain ownership of 1,000 UNI or more and delegated to the Delegate Achieving these above will provide an additional up to $3,000 USD worth of $UNI. 2c must be met, meaning ownership of 1,000 or more UNI must be maintained and delegated to the delegate to be eligible. If 2c is met, for 2a, 2b, there will also be proportional payment. For example, if 2c is met, and if there were 4 votings and 1 community call, and a delegate missed writing a rationale of 2 of the votes, the delegate would be eligible to receive $1800 [3/5 * $3000]. Regarding 2c, once again, in case of less than 1,000 UNI, This proportion will NOT be applied. For example, even if a Delegate has 500 UNI and fulfill all of 2a and 2b, the additional rewards would be $0 worth of UNI. The Uniswap Accountability Committee will periodically check qualified Delegates’ wallets for their UNI amount. Budget We are requesting 540,000 [6000 USD 6 Months 15 Delegates ] USD worth of UNI for cycle 4 of the Uniswap Delegate Reward Initiative. The total amount, once approved, will be sent to the Accountability Committee, which will be responsible for the monthly distribution of rewards to eligible delegates. Since the total budget of the Delegate Reward WG has not been fully used, administration of this reward program–including the creation of this proposal and the admin work behind verifying monthly delegate participation–will be allotted from that account, with no additional costs to the DAO. Therefore, the total budget request will be solely for the delegate pay.

TL;DR: Etherlink, an EVM-compatible Layer 2 blockchain secured by Tezos Smart Rollup technology, proposes a co-incentive program to bootstrap liquidity on Uniswap v3. The Tezos Foundation commits $300K to incentivize strategic pools and requests a $150K co-incentive from the Uniswap DAO. This initiative will drive long-term liquidity, support ecosystem growth, and position Uniswap as the default AMM for uncorrelated asset pairs on Etherlink. About Etherlink Etherlink is an EVM-compatible, non-custodial Layer 2 blockchain powered by Tezos Smart Rollup technology. It enables seamless integration with existing Ethereum tools, including wallets and indexers, and facilitates asset transfers to and from other EVM-compatible chains. Built upon the secure foundation of Tezos Layer 1, Etherlink delivers a fast, fair, and (nearly) free experience. Developed by the same core teams behind Tezos and fully supported by the Tezos Foundation, Etherlink offers a permissionless and censorship-resistant environment that empowers developers to actively build and participate in the next generation of decentralized applications. Officially launched in early 2025, Etherlink has seen strong TVL growth \- rising from approximately $1.5 million to \~$45 million within a few months \- driven primarily by the Apple Farm incentive program. With the launch of Season 2 and the onboarding of new protocols, we expect this growth to continue, targeting a minimum of $100 million in TVL by the end of the year. Etherlink is developing its ecosystem by onboarding new categories of assets such as Physical Uranium; Treasury bills and DeFi strategies tokenized by Midas; licensed on-chain money market funds; and is looking to onboard new permissionless RWA tokens. The goal is to establish Uniswap as the primary AMM for uncorrelated asset pairs on Etherlink. All future Tezos Foundation–supported project tokens \- particularly in Gaming and Art \- will deploy their primary liquidity pools on Uniswap. The Foundation is currently in the process of investing in several strategic projects within the Etherlink ecosystem, which will result in new tokens launching in the coming months. These tokens will be paired on Uniswap from day one, further cementing its role as the default venue for liquidity. Apple Farm Apple Farm is an incentive program \- powered by Merkl \- designed to bootstrap DeFi on Etherlink by rewarding users who provide liquidity on DEXs, supply capital on lending markets, and trade on selected DeFi protocols. In season one, the participating protocols are Superlend, Hanji, Uniswap, IguanaDEX, & Uranium.io. As the first AMM deployed on Etherlink (a PancakeSwap v3 fork), IguanaDEX saw significant growth in both trading volume and TVL, largely driven by incentives from Apple Farm. Since Thursday, June 19th and through July 3rd, incentives are already being distributed to initial Uniswap v3 pools as part of Apple Farm Season 1\. A total of $37,500 in rewards (not included in this proposal) will be allocated during this period, marking the beginning of Uniswap’s long-term role in Etherlink’s DeFi stack. The Etherlink team is coordinating with the Uniswap Growth Program on this proposal and will transparently share the terms and outcomes of the Season 1 distribution with the DAO. In Season 2 \- running approximately from July 15th to October 25th \- at least $300K in incentives will be allocated to core blue-chip pairs, especially WETH/USDC, WBTC/USDC, and LBTC/USDC. Uniswap will become the primary liquidity venue for all uncorrelated and ecosystem-native tokens, while IguanaDEX will continue to specialize in efficient stablecoin trading using its stableswap bonding curve. Etherlink and Uniswap Proposed Plan: Etherlink and the Tezos Foundation are committed to allocating a minimum of $300K in incentives to Uniswap pools over 3 months \- starting mid-July \- as part of Apple Farm season two. We propose a co-incentive of $150K from the Uniswap DAO to further enhance liquidity and foster a collaborative growth environment. The Tezos Foundation will also provide initial liquidity in each pool to facilitate efficient deployment and trading. Proposed incentive distribution 1. WETH/USDC \- ⅓ 2. LBTC/USDC \- ⅓ 3. WBTC/USDC \- ⅓ While the $300k allotment provided by the Tezos Foundation and the $UNI rewards will follow this distribution, the Etherlink team may choose to allocate additional incentives to blue chip/XTZ pairs in the future over the course of Apple Farm Season 2\. Uniswap TVL Analysis (Jul 6 2025\) Uniswap V3 TVL on Etherlink: $2.5M, Current Pools on Uniswap \- Etherlink: https://oku.trade/info/etherlink/overview Uniswap is already deployed on Etherlink. By collaborating with the Uniswap DAO, Etherlink aims to strengthen its DeFi ecosystem and provide mutual benefits to both platforms. We look forward to your support and a fruitful partnership.

!175016851880796415 (1).jpg Summary Unichain is currently the main focus of Uniswap’s growth strategy, presenting a significant opportunity for collaborative growth. The launch of USDS and sUSDS opens doors for close collaboration among two of the premier DeFi protocols Uniswap and Sky Ecosystem. Following the launch of USDS and sUSDS on Unichain, this proposal aims to boost growth on Unichain through a combination of partnerships and matched incentives, driven by aligned KPIs related to USDS and sUSDS growth on Unichain. Motivation Unichain is currently growing almost exclusively in Uniswap pools. Growth in other DeFi protocols on Unichain is growing but still behind. The introduction of USDS and sUSDS creates opportunities for enhanced collaboration among DeFi protocols. sUSDS provides yield, which itself is paid for by the Sky ecosystem. For example, if Unichain sUSDS TVL grows to 100 million, and at the current 4.5% of sUSDS yield, that would cost Sky 4.5 million USD per year. sUSDS can be a crucial part of the growth of the Unichain DeFi ecosystem, as it allows a stable and scalable yield source. For example, just examining Euler, removing Euler’s extra incentive, the lending APY is 3.19% for USDC and 2.05% for USDT as of June 4th 2025. However, if Euler were to integrate sUSDS yield and also provide its own incentive on top of incentive from Unichain, it could make it much more competitive yield compared to all other chains. !AD4nXdDAsTBvjSMYKLpQqYxma3UBpuhPVGBwQFv0jL56JSnRyOIaZuXc2ix3QykUGYeJ-KMXu9aui5TjGr_fsoeeE1w2-YcfZLIGsnGj5YZ4N4uev90mJb6QANvKLSYmCdfx4qVk3Akw.png Source: DeFillama - Unichain May 16,2025 !AD4nXcAs0uY8jLQwOsEN4o7kTQfMREhiSSyGBqDr43PW8x5l9qtk1laRm5dlVUGhYKD5gGJZxXZ3WuXFBRG1LhvkD6NH6rp3wuULi5zn3mDFRNiCnc12pQdfdk4TiSr8N7t6p_yrZA.png Source: DeFillama - Unichain June 4,2025 In addition, we strongly believe in Uniswap DAO having guidance and decision over the incentives distribution. Once per month, the strategy will be suggested to UniswapDAO where they can vote via snapshot to support the monthly incentive distribution or not. Goal / Growth Strategy The strategy involves coordinating with key protocols to expand the Unichain ecosystem such as by utilizing Sky ecosystem’s competitive base savings rate, which with the incentive from Uniswap DAO along with relevant DeFi partner can amplify it further. This can be done via three main ways: Collaboration with protocols to Increase TVL and Users StableLab will onboard protocols and, where applicable, negotiate co-incentive plans. For example, it could be that co-incentives are discussed with Euler and/or Compound to provide even additional incentives on top of sUSDS yield and co-incentives from Unichain. Focus on optimizing incentive programs All co-incentive programs will be data-driven to ensure effective growth. Co-incentives will be spent with strategic reasoning and analytical support. The program update will be shared once per month to communicate with the community. Continuous improvement and optimization In addition to the monthly program updates, we’ll refine the strategy in real-time, allowing for continuous improvement and optimization. KPI-driven growth will enable ongoing adjustment of both partnership targets and co-incentives distribution to ensure maximum ROI on spending. Budget and Duration As mentioned above, sUSDS provides yield, paid for by the Sky ecosystem. For example, if sUSDS grows to 100 million, at the current yield rate of 4.5%, that would cost Sky 4.5 million USD cost per year. And various DeFi protocols’ contributions would be added to further grow Unichain. We believe in Uniswap DAO having guidance and decision over the incentives distribution. Once per month, the strategy will be suggested to UniswapDAO where they can vote via snapshot to support the monthly incentive distribution or not. We also strongly believe the majority of the budget that Uniswap DAO provides should be tied to objective KPIs like USDS and sUSDS supply on Unichain, which is inherently tied to TVL on Unichain. Therefore, we propose a $1,000,000 USD budget over the course of a year with an additional $3,000,000 USD based on KPIs. In other words, only one fourth of the budget will be fixed, while the remaining part will be performance-based. The initial fixed payment will be paid in monthly installments while the performance based part will be paid at a time when the agreed upon KPIs are reached and we request the unlock by submitting on-chain proof. In addition, 80% of the budget will be directly spent on co-incentives that focus on USDS and sUSDS growth to boost Unichain TVL and usage. For instance, additional yield for sUSDS to make sUSDS yield on Unichain more attractive or an incentivized USDS and/or sUSDS pool such as UNI-USDS on Unichain. The remaining 20% of the budget, would be used for operations and logistics - such as coordinating with partners and also optimizing and reporting on the incentive program KPIs KPIs are intentionally set high to align with the DAO’s interests. Currently stablecoin market in Unichain is 279.4 million, with around 60% being USDC. The aim is to grow USDS / sUSDS to at least 100 million, which will help to increase Stablecoin market by close to 35%. !AD4nXeJ32UaElVjEX1NmfsNV0gF4ml5USrLuSzNwhVWfIp3XT0IV1y2nKDtSvRtPnueHtiFZhVoLYNaMgFY3uPM4wyTjG8xVftZwakiYcWB7OpL2ng_YHvQ2we7kYWLk981jO63B.png Source: DeFillama - Unichain June 4,2025 Out of $3,000,000 USD potential incentive based payment: USDS and sUSDS combined supply grow its TVL above 20 million USD on Unichain $1,000,000 USD Unlock. 80% will be used for co-incentives. USDS and sUSDS combined supply grow its TVL above 50 million USD on Unichain Additional $1,000,000 USD Unlock. 80% will be used for co-incentives. USDS and sUSDS combined supply grow its TVL above 100 million USD on Unichain -Additional $1,000,000 USD Unlock. 80% will be used for co-incentives. But for this specifically, the 20% will be able to claim only in case of 90-day TVL retention after the incentives from Unichain with the 40% or above compared to the peak. Additional Accountability and Alignment regarding KPIs We will share monthly updates on the distribution and use of co-incentives and relevant metrics such as: -90-day TVL retention, with the goal of 40 % each of peak -Net new liquidity provider addresses, with the goal of more than 1200 addresses by the end of the program -Δ TVL / $ incentive (ROI), ≥ $12 TVL gain per $1 variable spend, measured 30 d after each unlock The total payment will first go to UAC, with the fixed payment disbursed monthly. Co-incentives will be distributed based on the monthly snapshot voting. Once a KPI is achieved in terms of reaching KPI, we will submit a request to UAC with proof.

Summary This proposal seeks to establish a Technical Advisory Board (TAB) within the Uniswap DAO for a 12-month trial to provide expert technical insights on governance proposals. The TAB will be supported by a Professional Delegate (PD) to facilitate operations and communication. A total of 2.5 million UNI tokens will be delegated to expiring Franchiser contracts to empower the TAB’s governance participation. Motivation The Uniswap DAO governs the protocol’s evolution but often lacks consistent technical expertise. While some delegates offer valuable insights, few possess deep technical knowledge of Uniswap’s codebase or ecosystem dynamics (e.g., partnerships, integrations, routers, aggregators). Developers and builders, who have direct experience, often find the governance process opaque or inaccessible, limiting their ability to contribute meaningfully. Conversations with Uniswap ecosystem teams revealed that developers want to provide input but need a structured pathway. They believe their expertise could enhance proposals by assessing technical feasibility, estimating timelines, identifying risks, and evaluating costs. Improved governance participation would align ecosystem upgrades with builders’ needs. The TAB aims to bridge this gap by offering structured technical guidance, improving proposal quality, mitigating risks, and strengthening Uniswap’s decentralized governance. It will provide a clear pathway for builders to engage, fostering inclusivity and technical rigor. Background Technical expertise is critical for effective protocol governance but is underrepresented in Uniswap DAO. Inspired by Optimism’s Developer Advisory Board, we propose a TAB tailored to Uniswap’s governance model and market position. Key findings from research and interviews with builders include: Developers want governance roles but need structured engagement. Proposals often lack technical feasibility assessments, causing inefficiencies. Builders can offer critical feedback on risks, timelines, and ecosystem impact. A dedicated advisory group would enhance transparency and sustainability. The TAB will deliver expert evaluations, working with a Professional Delegate to integrate insights into governance. This structure aims to foster a more inclusive, technically sound governance process for Uniswap’s growth. Specification Technical Advisory Board (TAB) Composition The TAB will consist of 6 seasoned professionals with expertise in smart contracts, Uniswap’s protocol, and related fields (e.g., builders, security researchers). Its diversity and commitment to comprehensive support will ensure informed governance decisions. This structure addresses the lack of technical expertise in governance, inspired by Optimism’s model but adapted for Uniswap. The TAB balances technical evaluation with community education to improve proposal quality and transparency while preserving DAO control through iterative feedback. Proposed TAB Members (based on Uniswap Foundation and ecosystem feedback): 1. Akshat Mittal - Senior Protocol Engineer at Reserve, Founder of Metacrypt. 10+ years in technology, 6 in Web3, with deep DeFi expertise in protocol design. 2. Alex Netto - Founder/CEO at Blockful, focused on DAO security and governance. Experienced in smart contracts, Uniswap V4 hackathon winner, ENS metagov steward. 3. Ben DiFrancesco - Founder/CEO at ScopeLift, contributor to Uniswap smart contracts, with expertise in EVM and DAO governance engineering. 4. Dakotah Moses - Growth lead at Bunni, a Uniswap V4-native DEX. Bridges engineering and strategy to drive adoption. 5. Haardik H - 7+ years as a developer/consultant in DeFi, Identity, and Privacy. Built technical education programs at LearnWeb3 and Atrium Academy. 6. Kris O’Shea - Blockchain developer at Olas Protocol, former Sumero Finance developer. Uniswap ambassador, V4 hackathon winner, co-authored V4 documentation. Responsibilities Analyze all governance proposals from inception, evaluating the feasibility and impact of proposals which are technical in nature throughout the voting process, while providing timely and insightful feedback. Proactively identify and address potential risks or unintended consequences within proposal design Vote on all proposals during the 12-month term and provide a brief overview of the TAB’s rationale. Translate complex technical concepts into clear and accessible language for non-technical delegates. Develop educational resources and explanations to enhance understanding of proposal implications. This could include publishing reports, hosting webinars, and generally simplifying technical concepts to foster community understanding Professional Delegate (PD) Role Create an onboarding package (documents, info sessions) for TAB members. Support TAB operations, ensuring recommendations are represented in governance forums. Manage governance interactions and community communication. Develop a communication plan with TAB to share findings and recommendations. Facilitate logistics (e.g., meetings, public documentation). Support educational initiatives (e.g., workshops, webinars). Identify expertise gaps in TAB and coordinate with external experts. Act as a liaison with the Uniswap Foundation and ecosystem stakeholders. Positioning The PD serves as an operational extension of the TAB, not an independent actor. The role will be performed by DAOplomats. Voting Power Delegation 2.5 million UNI tokens delegated to a 4-of-6 TAB multi-sig wallet for 1 year. TAB wallet must vote on every proposal. Uniswap Governance retains control and can revoke delegation via a proposal. Transparency All TAB discussions, recommendations, and PD actions will be publicly documented in governance forums. Timeline Month 1: Select initial TAB cohort based on Uniswap Foundation feedback (done). Month 2: Put proposal to vote, deploy Franchiser contracts for token delegation. Month 3: Onboard TAB with PD resources, begin proposal review and governance participation. Month 6: Conduct first performance review, gather community feedback. Month 12: Evaluate TAB performance, open positions for replacement if needed. Month 14: Conduct elections if members need replacement. Budget TAB members and the PD will be compensated in UNI (and USDC for TAB) via continuous streams over 12 months. A buffer is allocated for educational materials and external expertise, with unused funds returned to the DAO treasury. | Role | Monthly Compensation | Number of Members | Duration (Months) | Total (UNI) | |-----------------------|-----------------------------|-------------------|-------------------|-------------| | Technical Advisor | 400 UNI | 6 | 12 | 28,800 UNI | | Professional Delegate | 800 UNI | 1 | 12 | 9,600 UNI | | Buffer | | | | 1,000 UNI | | Total | | | | 39,400 UNI | Compensation Structure TAB Members: 200 UNI/month via Superfluid stream + 1,000 USDC/month via UAC wallet. Professional Delegate: 800 UNI/month via Superfluid stream, accepting price volatility and shall perform their duties regardless Buffer: 1,000 UNI for educational materials and external expertise, sent to TAB multi-sig. Proposal Call Data Set up 8 Superfluid payment streams for 12 months: - 6 for TAB members (200 UNI/month each). - 1 for PD (800 UNI/month). - 1 to UAC wallet (1,200 UNI/month for USDC payments). Transfer 1,000 UNI buffer to TAB multi-sig. Transfer 2.5M UNI to Franchiser contract, delegating to TAB multi-sig. Uniswap Governance retains control to revoke streams and delegation.

The onchain vote to renew the UAC S4 recently passed. We will commence with the election of two new committee members. For a detailed account of the type of work that the UAC conducts and will plan on undertaking during Season 4, please read the Season 3 Report on the forums here. The members below have applied on the forums. The top two winners will be part of the committee. Each member's pitch can be found on this forum thread: https://gov.uniswap.org/t/uac-season-4-application/25580/7 Please note this rule from the forum post with respect to voting fairplay: If you or anyone from your organization is applying for a UAC position, you are not allowed to designate 100% of your voting power to the candidate in question. The maximum self-voting % allowed is 50%, and this amount must be at least evenly distributed among other candidates. The maximum self-vote percentage in any scenario must be matched equally with at least one other candidate. - Example: if you self-vote with 50% of your voting power, you must give one more candidate the other 50% (max matching 50%). If you self-vote with 25% of your voting power, you may divide the remaining 75% among as many candidates as you like, as long as one other candidate also receives 25% (max matching 25%). The self-vote % is simply your own voting cap that must be matched at least once with another applicant. This setup introduces a cap to self-voting, while simultaneously giving a degree of priority to yourself, as we understand that you would not be applying if you didn’t feel like a qualified candidate. This is something that was “soft consensus” decided when some issues arose with the treasury working group vote a few months ago. Eligibility Criteria As specified on the forums, you are only allowed to apply as an individual—not as an organization, using your DAO-recognized name and identity. The applicants are shown in the order by which they applied with their individual listed DAO-recognized name.

This Proposal is for chain selection feedback for the ongoing proposal https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x675c9697cc6c8d1cab27e1cffab3fdc7740b3e978eb37d8b6dcce76d1726670f so it depends on whether the proposal Analytics Hub for Uniswap’s Revitalization and Growth Program passes. For Unichain option, as the incentive is ongoing but as there’s a lot of interest, it’s listed as an option so that the community can see level of interest but from ranking for Forse for this proposal, it won’t be counted. So even if Unichain is among the top 4, it will skip it to include the next one into top 4. But Unichain related proposal could become its own RFC in the future if it's highly in demand.