Uniswap Seeks DAO Approval to Activate Protocol Fees on Select v4 Pool Families

Governance timeline

The measure was introduced as a temperature check and sent to a five-day Snapshot vote running from July 7 to July 12. Uniswap Labs said onchain voting is expected to start during the week of July 13.

That next step will not fit into a single onchain proposal. According to Uniswap Labs, Uniswap’s GovernorBravo contract allows only 10 actions per proposal, so two parallel onchain votes will be needed to cover all of the relevant chains.

The v4 proposal follows the broader UNIfication governance package approved by DAO members in December with near-unanimous support. That earlier overhaul enabled protocol fees and directed the proceeds toward burning UNI. Uniswap Labs said the new plan builds on four prior fee proposals, numbered 93 through 96, and uses the same expedited governance path established for them.

How v4 changes fee administration

Uniswap Labs said v4 requires a different fee system from v2 and v3. In v2, pools use a single fixed fee tier, while v3 pools use a set of fee tiers. By contrast, v4 pools can rely on hooks that allow potentially unlimited fee tiers, and a pool’s fee can change from block to block.

Because of that flexibility, the proposal does not attempt to configure fees pool by pool. Instead, it introduces what Uniswap Labs describes as a V4 Fee Controller made up of two contracts. A V4FeePolicy contract would calculate fees for pools according to governance-defined rules and could be replaced if that logic later needs to change. A V4FeeAdapter contract would apply any governance-set overrides for individual pools, otherwise use the policy fee, push it to the pool, and route the proceeds to a TokenJar contract on each chain.

Under the design described in the proposal, the policy classifies pools into families based on their characteristics and then determines the fee using the most specific applicable rule before falling back to a global default. Uniswap Labs said the contracts have been published in its protocol-fees repository.

Which v4 pools would be covered

The current proposal would switch on fees only for three v4 pool families: static fee pools without hooks, pools launched through Continuous Clearing Auctions, and aggregator hook pools that route external liquidity into v4.

Uniswap Labs said static and CCA pools would use a fee curve pegged to a share of each pool’s LP fee. Aggregator hook pools would carry a flat fee and use a 25x multiplier that raises the cap to 250 basis points. Those pools would have a 10 bps family default and a 3 bps setting for selected stable pairs on most chains, while on Base the corresponding figures would be 3 bps and 1 bps.

The company stressed that the proposal would not enable protocol fees for v4 pools outside those three families. As with the earlier fee rollout on v2 and v3, collected fees would be used for UNI burns, with tokens gathered on layer-2 networks and alternative layer-1 chains then bridged back to Ethereum and sent to the 0xdead address.

Earlier rollout and community reaction

Protocol fees are already active across all v2 and v3 pools on 11 chains: Ethereum, Arbitrum, Base, Celo, OP Mainnet, Soneium, X Layer, Worldchain, Zora, BNB Chain and Polygon. Uniswap Labs said the protocol recorded a monthly high point last month, citing the UNIBurnBot account’s report that 186,000 UNI were burned in a single day.

The new proposal quickly drew differing reactions. Guillaume Lambert, founder of options protocol Panoptic, said he had abstained on the December UNIfication vote and argued that the fee switch should not be extended to v4. He wrote that taxing v4 pools without compensating liquidity providers could push them toward other AMMs or Uniswap v3 forks, and said he would support the move only if LPs received direct, long-running UNI incentives.

Other early feedback was more supportive. A forum participant identified as Abel189 said a deterministic onchain fee policy appeared more scalable than setting fees one pool at a time, and backed the narrower rollout across selected pool families.

Context: The proposal would extend a fee-and-burn model already active on Uniswap’s older pool versions into v4, but only through a more rules-based system designed for the new architecture’s greater flexibility. UNI holders are first weighing the idea in Snapshot voting before the expected pair of onchain governance proposals.