Proposal #100
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.
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:
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:
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.
Pre-proposal (to be completed by Uniswap Labs prior to an onchain vote)
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):
V4FeeAdapter as the ProtocolFeeController on the PoolManager on each chainSnapshot: July 11-16, 2026
Onchain vote: July 19-26, 2026
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.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 |
Strongly against activating fees on v4. See our reasoning here: https://gov.uniswap.org/t/temp-check-activate-v4-protocol-fees/26162/10?u=gammastrategies Basically we believe it's too early to be activating protocol fees on v4 prior to achieving market dominance.
I support Uniswap capturing sustainable value from v4, but not without clear protections for the liquidity providers on whom the protocol depends. Before activating fees broadly, governance should establish transparent measurements of LP profitability, liquidity depth, spreads, volume, and market share, along with predefined review and rollback thresholds. Fees can then be activated selectively where the evidence shows that pools can support them without weakening Uniswap’s competitiveness. I am voting AGAINST this implementation, not against protocol fees in principle. Build the measurement and rollback mechanism first, then activate fees responsibly.
I support this proposal because it introduces a governance-driven framework for activating protocol fees in Uniswap v4 that is compatible with the protocol's flexible hook architecture. Rather than managing fees on individual pools, the proposed V4 Fee Controller applies transparent, deterministic rules while remaining upgradeable through governance if future adjustments become necessary. The phased rollout across multiple chains, combined with the use of policy-based fee management and on-chain governance oversight, provides a measured approach to expanding protocol revenue while preserving the ability to refine the system as real-world data becomes available.
**Voting For.** Uniswap is running the experiment the rest of this industry keeps arguing about in theory. Protocol fees have been live across v2 and v3 on eleven chains, Labs has taken its interface, wallet and API fees to zero, and Uniswap is still the largest venue. If volumes hold through this extension, that is an empirical answer to the claim that a protocol must give its service away to defend market share. Extending fees to v4 tests it on the most competitive surface we have. That alone is worth the vote. Three reasons I support this proposal, and one distinction I want on the record. **It restores the link between protocol activity and the asset.** This is the property most infrastructure in this space has lost: usage grows and the token does not notice. Uniswap is rebuilding that link rather than deferring it indefinitely. **It is a credible commitment, not a promise.** Routing revenue to a treasury is a policy any future governance can reverse and any well-organised cons