Activate v4 Protocol Fees (Part 1/2)

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. This onchain vote will specifically activate v4 fees on Ethereum, Arbitrum, Base, BNB Chain, Polygon, Optimism, and Robinhood Chain. Please note that because of GovernorBravo's limit of 10 actions per proposal, there will be two separate onchain votes to accommodate all chains. The remaining five chains (Celo, Soneium, Worldchain, X Layer, Zora) will be addressed in a subsequent proposal.

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 the 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 11-16, 2026

Onchain vote: July 19-26, 2026

---

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.

This results in the following fees at the following points.