[Temp Check] Activate v4 Protocol Fees

[UniswapLabs]

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

[guil-lambert]

TLDR: Only turn on the protocol fee when LPs are consistently earning enough to absorb the 10-25% cut. For v2/v3, the fee switch may be defensible as a migration tool toward v4. But applying it to v4 without compensating LPs, for example with sustained UNI incentives to boost revenues/implied volatility, risks killing the LP base and the protocol.

Disclosure: I am the founder of Panoptic, an options protocol built on top of Uniswap v3/v4 and I voted “Abstain” on the UNIfication proposal.

---

Turning on the fee switch may make sense as a way to deprecate v2+v3 in favor of v4. If you take a full 25% cut of all LP revenue for all v2+v3 pools, it will drive away LPs to v4.

But turning on the fee switch for v4 pools as well means there will be nowhere for the LPs to go except to other AMMs/UniV3-forks.

Turning on the v4 fee switch risks killing the protocol.

It favors short-term interests of token holders at the detriment of real stakeholders (LPs) who ultimately are the ones keeping the protocol alive.

What is LPing?

Every liquidity provider is structurally short convexity: the value of a LP position follows a ~√price for Uniswap v2 and a covered-call-like payoff for Uniswap v3

Any short convexity position is structurally underperforming simply holding the assets: as the price moves up or down, it earns less than a strategy that consists of linear holding positions --eg. the dreaded impermanent loss.

How to make LPs profitable?

The inherent structural imbalance of convex positions has to be matched with an external cash flow.

In TradFi, a convex position like a covered call will receive an upfront payment when created. The tradeoff is that a covered call seller gives up unlimited upside in exchange for a small upfront compensation. If that compensation is not high enough, covered call sellers are structurally in a -EV position.

In Uniswap, that fee is not paid upfront but is streaming to the LP position holder over time. But that fee stream acts as a compensation for giving up future (and potentially unlimited) gains due to holding that short convexity position.

Pay LPs a high enough fee, their position will be +EV. This is what we saw during DeFi summer: stake your LP tokens, earn 1000% apr in tokens! Those extra tokens were a way to bootstrap liquidity by pumping the fees received by LPs.

How to price convex positions

In TradFi, going back to the covered call example, the premium paid upfront is actually under the control of the seller: they must find a suitable buyer for the call they just sold, and unless they can agree on a fair price for that option, then the transaction won’t happen.

How do you fairly price an option? There are several models available (with the Black-Scholes model being the most successful one), but all pricing comes down to a single number: the implied volatility (IV).

Both parties, the seller and the buyer, will be satisfied with their trade once they agree on the IV of that position. If IV is too low, buyers are structurally +EV, if IV is too high, sellers are +EV.

How much fee revenue is enough

Since a call seller is giving up unlimited upside while retaining downside exposure, they MUST receive a higher compensation to make them statistically +EV to account for the edge case where they lose their entire investment (or more).

This means the implied volatility of an option is very often higher than the realized volatility (RV) of that asset. Otherwise, the option buyer will underpay for that privilege to be exposed to unlimited gains and a limited loss.

Volatilities in Uniswap v4

Are LPs currently compensated enough on Uniswap v3 and v4?

We can compute the implied volatility of LP positions in Uniswap by looking at the daily volume, the average at-tick liquidity, and the amount of fees collected. The realized volatility can also be computed from the actual block-by-block price move.

Here’s what the implied vs. realized volatility looks like for the ETH-USDC-30bps pool on Uniswap v4

source: https://app.panoptic.xyz/pool/ethereum/0xdce6394339af00981949f5f3baf27e3610c76326a700af57e4b3e3ae4977f78d?tokenId=0x0

Most of the time, the realized volatility (blue) is above the implied volatility (purple). The brief amount of time IV > RV was in early June when the price of ETH went down to 1550 and hit low liquidity zones.

There are several reasons why the realized volatility is above the implied volatility. In TradFi, this means the market has low entropy/quality flow. On Uniswap, trades being mostly arbitrage is one reason. Routing +EV trades through UniswapX instead of through the underlying Uniswap pools is another.

Volatilities in Uniswap v3

In Uniswap v3, the fee switch means that LPs receive 10-25% less fees than the same position on Uniswap v4. Since the fee paid by buyers is still 5bps, 30bps, or 100bps, the flow and realized volatility will remain the same, whereas the implied volatility will be based on fee revenues that are 10-25% smaller, basically shifting the whole IV curve down by 10-25%.

We can clearly see this for the WETH-USDC-5bps pool on Uniswap v3. Here, the implied volatility is computed using that 25% fee switch, meaning that each swap earns the LPs 3.75bps instead of 5bps.

source: https://app.panoptic.xyz/pool/ethereum/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640

The implied volatility is never above the realized volatility

Even during that transitory period when the pool had lower liquidity in early June, the net returns for LPs were not high enough to compensate for the potential losses they were just subjected to.

Some pools do have a IV > RV relationship (eg. the LIT-USDC pool, memecoins, and basically most pools pre-2023) because they have/had organic activity.

Proposed Solution

I am not saying to never turn on the fee switch.

But the protocol fee should be conditional on LP profitability. If a pool’s implied volatility is consistently above realized volatility, then governance can take a cut without breaking the LP trade.

Instead, if RV > IV, then LPs are already undercompensated. Taking 25% of their fees does not monetize the protocol. It pushes LPs further into negative EV.

For v2 and v3, a fee switch can make sense as a migration tool to deprecate legacy pools and push liquidity to v4. It remains to be seen whether v4 can truly give LPs a better venue with hooks, dynamic fees, and better execution design, but at least the vanilla v4 pools have a better RV-IV profile.

But if you add a 25% pay cut on top of a structurally inefficient market, the only rational move for LPs is to leave the Uniswap ecosystem entirely.

---

The only way I see myself supporting this is if LPs are directly compensated with $UNI tokens or through other means that make LPs consistently profitable. And I don’t mean $100k in incentives sprinkled over months here: it has to be millions and sustained practically forever until organic activity returns.

[Abel189]

I support this proposal because Uniswap v4 introduces a fundamentally different architecture, and protocol fee management should evolve accordingly. A policy-based system that computes fees deterministically while remaining fully governed on-chain is a more scalable approach than configuring individual pools one by one.

I also appreciate that the rollout is gradual, initially covering only specific pool families rather than enabling protocol fees across the entire v4 ecosystem. This measured approach allows governance to evaluate the impact of the new fee model before considering broader adoption.

As the system matures, it will be important to monitor the effects on liquidity providers, trading activity, and protocol revenue to ensure that fee policies continue to balance ecosystem growth, user competitiveness, and sustainable value creation for the protocol.

[wenhao]

i agree the propose ,because I am not saying to never turn on the fee switch.

[Manugotsuka]

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted FOR.

We support activating protocol fees for Uniswap v4. This is a continuation of the fee rollout approved through UNIfication, and given that protocol fees are already live across v2 and v3 pools on multiple chains, extending the framework to v4 feels like the next logical step.

V4 is more complex than previous versions because of hooks and dynamic fees, so a simple pool-by-pool approach would not scale well. The proposed fee controller system seems like a practical way to handle that complexity: governance can define rules for different pool families, while still keeping the ability to adjust the policy over time if needed.

Before voting, we asked our Research Team to review the proposal. They did not identify any issues that would change our position.

[himlock]

I’ve recently been shopping for insurance protection for Uniswap V3 pools. We used the pricing tool of an on-chain insurance-type company that does provide coverage for Uniswap protocol and contract risk. The v3 policies are the least expensive policies they offer. Speaking to the agent for that company, he explained that the reason it’s so cheap is because the protocol has had years to beat the bushes to find the snakes and the risks are very well understood and considered very low. This is indicative of a well-used, high quality smart contract.

I also got a quote for V4 contracts insurance, even though we’ve not migrated over to V4 LP’ing yet. The cost of the policy was almost 10x the V3 pricing.

I think that when considering new ‘costs’ for LP’s, in the form of fee reduction, we should really consider the down-range issues. For instance, when outside markets believe that one contract is far more risky than others, governors should take that into consideration and understand that raising costs equivalently in v4 as was done in v3 will have serious cost considerations that weigh down our ability to gain +EV.

[Frozond]

Basically this.

Fee switch should only be used to encourage migration of sticky capital towards the latest (new/improved) protocol version, which is especially important when it comes to capital efficiency gains at the million/billion TVL scales.

It provides an incentive for the protocol to innovate over time, because if Uniswap doesn’t, competitors will.

[UniAnon]

To the commenter who said “not yet”, the idea of “not yet” means really never, and the purpose of the fee switch is not to be a catalyst for LP migration, but to create a link between platform success and Uniswap token value. Unless your comment proposes some alternate way of creating that link, it’s an incomplete thought.

So I fully support this proposal of enabling v4 fee switch.

[himlock]

What do you think about some kind of rewards or token bonus to re-compensate LPs? Can we think of a way to overcome the losses? For many people, the v3 fees increase was their profit. We also had the idea of just steadily buying UNI… if they’re using their portion of the fees to burn UNI, then demand goes up over time, right?

[gammastrategies]

I agree with @guil-lambert that we shouldn’t be taking fees from Uniswap’s frontier AMM at this moment in time. While Uniswap V4 has gained significant market share, it still isn’t the market leader on even Uniswap AMMs in terms of volumes: https://dune.com/queries/5663153/9199844

It still lags Uniswap V3 in terms of volumes, and there’s evermore increasing competition from AMMs, propAMMs, RFQ’s, and spot limit order book dex’s such as Lighter/Hyperliquid.

My vote is to wait until V4 at least has the dominant market share of volumes and LP fee generation on solely Uniswap pools, including v2, v3, and v4 pools. By dominant, I mean at least doing 3x the volumes of Uniswap V3 & V2. To introduce profit-taking prior to achieving market dominance is unwise.

Additionally, this can be done piecemeal. We have all the data and analytics to know which chains Uniswap V4 is a clear leader in, and where it’s trailing in. Base is highly competitive, so I would not advise taking anything from there until we have a clear market leader position over other DEX’s.

There will always be a trade-off between market share and token holder profitability, but I think we need to be more thoughtful on how we approach this. It doesn’t have to be all-or-nothing on every single chain. We have the data, means, and resources to be more thoughtful here.

[Axia]

I support the goal of creating a stronger link between protocol usage and UNI value, but I think the concerns raised by @guil-lambert and @himlock around LP economics, as well as @gammastrategies point about v4’s still-limited market share, are important and should not be treated as secondary.

LPs are the core supply side of the protocol. If protocol fees reduce LP income too aggressively, especially on v4 while it is still competing for liquidity and volume, there is a real risk that liquidity migrates elsewhere. That would weaken the protocol even if the fee switch looks beneficial for UNI holders in the short term.

I also think the DAO should keep evaluating whether the fee and burn mechanism creates durable demand for UNI, not just supply reduction. Burning UNI is useful, but long-term value probably depends on whether UNI has a stronger economic role in the system.

So I’m not against activating protocol fees, but I do think governance should be careful about where and how they are applied. A more data-driven approach by chain, pool, LP returns, liquidity depth, and competitive position seems important here.

[UniAnon]

Can you please expand on what you mean by “steadily buying UNI”? Who would be constantly buying UNI?

There is no way to overcome “Impermanent Loss”. If you LP two tokens and one token massively appreciates in value, you’re not overcoming it - in the short term. What goes up tends to come back down though on a long enough timeline, at least in crypto…

[UniAnon]

There is no “elsewhere”, IMO. Curve is losing stablecoin share to Uniswap and that was their bread and butter. Aerodrome is a complete joke (and a shell game, and likely a security that surely the SEC will take a hard look at). On Ethereum chains, who else is there? I think Balancer is gone, Bancor is gone… am I forgetting any?

[UniAnon]

If you really want to do something useful on Base, submit to the SEC’s anonymous tip line about how Aerodrome is blatantly a security. Uniswap spent too much time and money coming up with a buttoned up (and from my understanding, developed with an “sec blessed” amount of input) mechanism for linking platform performance to token value, to allow a blatantly fraudulent competitor to just exist without any sort of pushback from the relevant government agency.

[kevkro]

Are we charging the wrong side?

Disclosure: I’m a co-founder of Ascnt.fi, building market-making tooling for LPs on Uniswap v4.

I agree with the concerns raised by @guil-lambert, @gammastrategies and @Axia on LP profitability and thought its worth adding some perspective how the protocol fee could be restructured to better serve all stakeholders.

As I understand the current market structure, trading venues typically monetize the takers and support the makers: CEXs charge retail takers often 0.5-3% per trade, while professional makers pay little to none or receive incentives — higher liquidity depth helps the venue win.

What keeps me puzzled is why the current design incentives the opposite. Interface fees on swappers went to zero, while the protocol fee takes 10-25% of LP revenue — where profits are already thin next to private market makers (PMMs), since most LPs lack comparable tooling and strategies. In turn, PMMs filling UniswapX orders from inventory currently pay no protocol fee. LPs are down on two fronts: the tooling/strategies and pay the infrastructure that takers (swappers) and PMMs benefit from.

This causes an uneven playing field as you can see from the roughly sketched value chain below.

Taker side: On-chain is already the cheapest venue — before maker compensation, a swapper pays almost nothing, vs. fixed fees of up to ~3% at CEXs before the maker’s spread.

Maker side: CEX makers get incentives, on-chain PMMs have largely zero venue costs, and the Uniswap LP suffers twice. It’s like the service provider paying the customer.

The current model could become a negative flywheel

PMMs’ lower costs plus their dynamic pricing let them outcompete LPs → LPs lose flow and get heavily taxed on what remains → more LPs leave → the fee pie shrinks → a high relative protocol fee chases a falling LP fee base.

A high relative protocol fee on LPs also makes it unattractive for teams to build the missing tooling like battle tested dynamic pricing, if there’s no margin left to compensate their work, weakening the v4 platform thesis.

What we’d suggest exploring

A taker-side fee applied to all fills — PMM and LP alike, on a level playing field. On-chain stays far cheaper than any CEX in pure venue fees, the PMM/LP asymmetry closes.

This also restores the incentive for devs to build the tooling LPs need to compete with PMMs — diversifying the on-chain liquidity market and enabling new products built on profitable LP pools. TVL and depth grows much larger, and absolute revenue grows further with a small, fair relative fee than with a concentrated high one that drives a core supplier of liquidity out of the market.

[riskypete]

Some disclosures first: I’m part of the team behind Sentralis.io, a portfolio risk and scenario analysis solution. Nobody here asked or paid for this, and none of it is advice. A few posters above asked for numbers before the rollout, and while the chain-level LP data gammastrategies and Axia want is something only Labs or a data team with per-pool coverage can produce, there is one number set missing from this thread that is fully public: the supply and treasury side of the burn.

Three observations from on-chain reads (as of July 16, block 25,546,407 — all of this predates v4 and Robinhood Chain fees, so treat current rates as the floor the vote would raise):

1. Observed burn rate: ~1.1M UNI/month. The dead address has grown ~7.21M UNI since fee burns started in January (0.53M in January rising to 1.77M in June). Worth knowing when weighing the headline projections: this is the realized number under v2/v3 fees on 11 chains, not a forecast.

2. The treasury currently sheds units ~1.5× faster than the market burns them. The governance timelock pays ~1.67M UNI/month to Labs under the growth budget (5M/quarter, three quarters drawn so far) against the ~1.1M/month burned. Whether v4 + Robinhood Chain flip that ratio depends on exactly the fee-flow numbers this thread is debating.

3. On burn demand mechanics (himlock’s question): the burn-to-claim design makes “demand” the wrong frame — a searcher burns UNI whenever the TokenJar basket is worth more than the UNI they pay, so burn volume tracks fee accrual more or less mechanically, minus the searchers’ margin. The variable the vote moves is fee flow; the burn follows it.

One number for scale on what all of this orbits: the timelock holds 267.13M UNI — 29.9% of supply net of what’s been burned. The fee votes change the flow around that stock; they don’t change what the stock is exposed to. We’ve run drawdown and exit-liquidity scenarios on that position and will post the full analysis separately; happy to share methodology or re-run with different assumptions if useful.

[UniswapLabs]

Thanks everyone for the discussion. We want to address the LP impact concerns, specifically that protocol fees on v4 will push liquidity providers off Uniswap and towards other venues.

The same concern was raised before activating the fee switch on v2 and v3, and we have intentionally slowly rolled out fees since UNIfication to monitor this potential risk.

Based on the data from the last seven months, we saw that the growth of v4 actually came from net new assets, LPs, hooks, and other use cases, not from v3’s blue-chip liquidity:

• Blue-chip v3 liquidity stayed. The 25 largest Uniswap v3 pools on Ethereum at fee activation have held 98.5% of their pre-activation liquidity in token terms today. On Base, the top-25 fee-enabled pools hold 131% in token terms. Over the same windows, these pools’ swap volume fell far less than total DEX volume on Ethereum (down 20% vs. a 62% market decline) and in line with the broader market on Base (down 31% vs. 36%) As we shared in the February expansion post, market-adjusted TVL on mainnet rose after activation.
• Fees have steadily grown. Protocol fees have funded ~7.5M UNI (~$25.6M) of burn since December, with monthly fees growing from ~$3.1M in February to ~$5.1M in June as the rollout expanded across chains, including a record 186,000 UNI burned in a single day last month.
• v4’s growth did not come out of v3. The data analyzing v4’s growth on mainnet and Base shows that it is unrelated to v3’s fee switch. v4’s largest pools are new pairs and new liquidity, some coming from issuers who require battle-tested smart contracts (FIDD from Fidelity; PRIME from Figure (FIGR)) and from deep partnerships (USDS pairs with Spark), not migrated v3 blue-chip positions.

While acknowledging that Uniswap v4 has structural differences to Uniswap v3, our proposed fee configuration is the result of extensive research and modeling.

Just like with v3, if the proposal passes we intend to monitor the impact closely. If the fees on v4 are not well tolerated, additional governance proposals can be submitted to adjust them as needed.

LP performance remains a critical priority, and we are excited to evaluate the protocol fee’s performance over the coming weeks.

[Abel189]

Thank you for sharing the data and addressing the concerns around LP impact. I particularly appreciate that the rollout has been gradual and supported by measurable results rather than assumptions.

One aspect I believe will become increasingly important is establishing a consistent post-activation review process. Since governance has already stated that fee parameters can be adjusted if market conditions change, publishing periodic metrics—such as protocol fee revenue, UNI burned, liquidity retention, trading volume, and any migration between v3 and v4—would provide the DAO with a solid basis for evaluating whether the current fee policy continues to achieve its intended objectives.

This would also make future governance discussions more data-driven and help build confidence as protocol fees expand to additional chains and pool families.