"Fee Switch" Design Space & Next Steps

There has been a lot of discussion around whether the “Fee Switch” should be turned on. In most of this discussion I see an assumption that using the fee switch = money going to UNI token holders. I think this is limiting.

The design space around how a fee switch can be used is much larger and it’s crucially important to all of DeFi that we consider the design space broadly. Mindlessly adopting a generic “stake UNI = get some sort of fee” would miss the incredible opportunity we have to think creatively about how protocols, governance, and value accrual can work in Web3.

The purpose of this post is make clear UNI governance has two very different decisions to make 1). should a fee switch be turned on? and 2) how should fees be utilized?

By separating these decisions we may actually be able to move faster.

The stakes are high
Uniswap is the #1 DeFi protocol – both in terms of utilization and ethos. What Uniswap chooses to do with the “fee switch” will set precedent for the whole industry. Much like the retro-active UNI token airdrop set precedent for how to distribute governance.

The high stakes make complacency a comfortable option but there is equal risk in waiting too long to explore this tool.

The “fee switch” Design Space
I believe the term “fee switch” is a misnomer. It refers to the ability for the Uniswap protocol to retain a portion of what is already being paid to the liquidity providers. The protocol retaining a portion of this gives UNI token holders new tools to leverage in furthering the growth and mission of the protocol. It does not create any expectation the retained tokens will be paid out to UNI token holders.

  • Public goods funding (thus far the #1 use of the protocol treasury)

  • Building protocol owned liquidity

  • Funding grants / developers / etc. for the Uniswap Protocol specifically

  • Other things we can imagine! :sparkles::unicorn:

Should the “fee switch” be turned on?
I believe the answer to this question is “yes”. It should be turned on in a limited testing capacity. Doing this now will 1) provide us with real data and 2) provide the community more time to consider how assets accrued via this mechanism should be used.

At this point, it’s too large of an unexplored design space to neglect. As mentioned already, this will not increase fees for people using the protocol to swap. It will simply retain a small portion of what is currently being paid out to liquidity providers.

What are the next steps?
Uniswap V3 sets fees on a per pool basis. This means we can turn the fees for a limited set of pools. We can analyze the impact this change has and use results to discuss.

I’m suggesting a simple standard – if trading execution is not diminished for the pools with the “fee switch” turned on – the experiment is a success.

I suggest we start with two of the largest pools, one stable <> stable pairing and one stable <> volatile. I also suggest we start with the lowest possible setting of 1/10. Based on recent data, these modest changes should accrue $20-$40k per day to the protocol. According to this Dune dashboard, total LP fees over the last 7 days have been $9.5 million. Assuming the lowest possible setting (1/10) that’s 950k per week the protocol hypothetically could be accruing. The cost of inaction is high.


  • USDC / ETH @ 0.05%, initialize 1/10 “protocol fee”
  • USDC / USDT @ 0.01%, initialize 1/10 “protocol fee”

This is an important decision, let’s discuss!

In accordance with governance procedures, I’ve created a temperature check vote here: Snapshot


Like the proposal and discussion. I think a major consideration here is whether or not liquidity providers remove liquidity as a result. Given that we don’t know for sure how this type of change would play out, I think using 2 of the largest and most important pools is pretty high risk. Personally, I would prefer to try something like this on a couple of smaller but significant pools to start before going this big, but this discussion is interesting and I’m following along.


Large-scale LPs are conspicuously absent from a lot of the discussion on this forum and it would be really beneficial to hear from them in this discussion. If you are a LP, especially on the USDC / ETH and UDSC / USDT pools, consider this an invitation to make an account if you haven’t got one and comment.


Cosigning @jcp comment above. I think it would be better to start out with less important pools / pools that provide relatively less utility to traders.

Eg. switch the USDC/USDT 0.01% pool for the 0.05% pool, and USDC/ETH 0.05% pool (arguably highest utility pool on Uniswap v3) for 1% pool.

This positions the proposal as somewhat of a win-win; if LPs are put off by the protocol fees, they may be interested to move their liquidity to the lower fee tier pools which would provide improved utility to the Uniswap ecosystem.


Seems like to get the best data we should select a sample of pools, varying in

  • fee tier
  • liquidity
  • trade volume

Trialing with too few pools could lead to a lot of disagreement about what was actually learned. Ideally have maximal parity in the size and composition of the control group and test group.


The largest pools that can be reasonably coordinated are the 5bp and 1bp DAI/USDC. 1.5 billy between them, what do you think @monet-supply? I’m sure this would be a great move with makerdao.

I think at this stage the fee switch should not be the highest priority on the list for the UNI token holders. Restructuring the community, streamlining the governance process, providing white glove support for proposals should all be prioritized first and then implement limited fee switch.

Personally, I believe this would bring more value to the UNI token holders, but Im not against it in principle. I feel like @monet-supply points are valid.


One idea I’d like to propose is to potentially use the fee switch to incentivize LPs to lock their liquidity on Uniswap. Incentivizing LPs to lock their liquidity within specific ranges for certain periods of time would make Uniswap TWAP oracles provably harder to manipulate (ref: https://blog.euler.finance/eulers-oracle-risk-grading-system-93f47d68205c). Safer oracles would make it easier for lending protocols to adopt Uniswap TWAP oracles instead of relying on more centralized solutions like Chainlink.

I think it could be an interesting way to experiment with the fee switch for the following reasons:

  • Safer oracles would benefit the whole DeFi space;
  • Over time this initiative could lead to Uniswap TWAP oracles becoming the gold standard in DeFi;
  • All of the fees would still go to LPs, therefore potentially limiting the loss of pre-existing LPs as the fee switch is enabled;
  • The fees would compensate longer focussed LPs over Just In Time liquidity providers;
  • This initiative would be quite easy to roll back if it fails vs paying $UNI holders a dividend.

Just my two cents. Curious to see if there is any interest in this!


I’m from Gamma Strategies, which is an active liquidity manager on Uniswap v3, and I will say that USDC / ETH is one of the hardest pairs to be profitable on due to the lack of correlation between the two assets which leads to higher impermanent loss. The fees are desperately needed to offset any IL in that pair. So, I would not take fees away from USDC / ETH. It’s one of Uniswap’s most dominant pairs, and any fees taken away from that pool will likely diminish Uniswap’s market dominance.

USDC/USDT 1 bps fee tier pool is extremely dependent on fees to make a respectable profit as well. The margins are razor thin already. Curve and CEXes also do offer respectable competition for these swaps.

I guess the main purpose of this test is to see how much liquidity would leave after implementing a fee switch?

I think that’s a dangerous game. The AMM design of Uniswap v3 was genius in that the concentration of liquidity allowed it to have an amplified effect, which got Uniswap 80% trade volume market share on a fraction of the TVL, but I don’t think it should get too cocky or complacent with that lead. Other AMMs like Curve v2, Sushi, Quickswap, Orca, and Shell Protocol are all developing their own concentrated liquidity platforms, which will likely make some dent in the trade volume market share of Uniswap in the future.

Uniswap seems to be very well capitalized and endowed with a lot of funds for protocol development. They even have enough funds to make venture investments of its own.

So why is this needed? Protocol owned liquidity is great, but it need not come from the fees. I would rather see Uniswap fund these developments via providing liquidity in their own pools. There are plenty of stable-stable pairs where good income can be made through either incentives programs provided by other protocols (such as Frax Finance and Angle Protocol, which offer double digit yields on Uniswap’s stable-stable pairs) and via leveraged stablecoin liquidity providing. Thus, I’d rather see Uniswap bring in this income via liquidity providing in their own pools versus taking fees away from the LPs. Its double benefit that way where you increase Uniswap’s liquidity and maintain a competitive edge over other AMMs that are vying to take market share away from Uniswap.


It will simply retain a small portion of what is currently being paid out to liquidity providers.

I also suggest we start with the lowest possible setting of 1/10.

10% of the fees from any pool is not a small portion, especially when the LP still has to consider impermanent loss. Those fees are often the difference between profit and loss. LPing on V3 is already challenging enough. I can understand concentrated liquidity managers and others building on top of Uniswap charging fees for managed services. But the base layer? 10 percent of all fees?!

Just like in government or business, if you’re going to create taxes or fees that make you less competitive and less capital efficient, you should probably have a rigorous plan of how you wish to spend those funds. A plan with accountability that benefits the protocol, UNI holders, and LPs (especially LPs in this case).

Public goods funding (thus far the #1 use of the protocol treasury)
Building protocol owned liquidity
Funding grants / developers / etc. for the Uniswap Protocol specifically
Other things we can imagine! :sparkles::unicorn:

This is not an acceptable plan. The last one is particularly concerning. Just fund whatever you want because you can? That’s defi education fund vibes.

Seriously consider reducing the % of the fees you are seeking, create a spending plan for any raised funds, and create a backtest for a variety of pools (small, large, stable-stable, stable-eth) before you just stick it to the LPs.


So, If Uniswap invests money received from fees to handle impermanent loss issues somehow, will it be a win-win?

Can we think of other ways to generate income without exerting this negative pressure on LPs? I think there are plenty of other ways to generate this income via delta-neutral liquidity providing in Uniswap’s own pools, which have a positive as opposed to negative effect on the amount of liquidity. Also, it does not seem that Uniswap at this moment is strapped for cash given its recent venture investments. Taking fees away from LPs should be a last resort. Let’s explore other income generating ideas first that don’t have this negative effect on the LPs.

Unless the opportunity cost of capital is a Curve pool versus a lower fee tier Uniswap pool

Would love to see a DeFi protocol act more as a protocol than a business personally. Most protocols are charging their TradFi analogue level fees currently.

A small %ge over a looooong period of time (hundreds or thousands of years if all plays out well for Ethereum/Humanity) is a better realization of the capital efficiency crypto promises than taking larger middle-men level cuts.

Unpopular opinion probably but meh. That’s what one random guy on the internet thinks.


I think you and @jcp have a good point.

How do you think about the value of varying the assets vs. varying the fee tiers?

To me it makes a bit more sense to use the same low fee set but on trading pairs with less volume.

10% of the fees from any pool is not a small portion

This is the smallest portion the code allows, it’s impossible to set it lower.

This is not an acceptable plan. The last one is particularly concerning. Just fund whatever you want because you can? That’s defi education fund vibes.

The whole point of my post is that I am suggesting NO PLAN for how these accrued tokens might be used. I’m explicitly trying to separate the testing of value accrual from how / if that value is disbursed.

create a backtest for a variety of pools (small, large, stable-stable, stable-eth) before you just stick it to the LPs.

Agreed on being more thoughtful on what pairs this is tested on.

1 Like

Speaking for Avantgarde here, I agree with @Buckerino’s sentiments almost entirely.

I’m pro-experimentation but think this proposal is riskier than it seems on the surface. The risk in my opinion doesn’t necessarily come from the action of turning on the fee switch itself, and indeed I think that liquidity providers should build their businesses around the assumption that that happens some day in the future.

Instead, I think the decoupling of two distinct but related questions (“Can the protocol charge fees” and “What will the protocol do with the fees that it earns”) is where the danger lies. Uniswap’s governance is still in its formative stages and though the past year has seen some positive outcomes, kicking the can down the road and trusting that we’ll figure out how to manage and deploy this income stream is not a good look. It’s irresponsible to make a foundational shift in the economics of an entire set of users without telling them why that shift is being made.

And this is not even taking into account the regulatory risk to token holders which, \ __o __/, I’m not qualified to speak on.

With that said, there is definitely an opportunity to fund research around this topic so that we can make a more comprehensive plan on how to change a key tenet of the biggest dex in the market and arguably the most important protocol on Ethereum. Off the top of my head, I’d like to have as a start:

  • a framework for categorizing pool types. @wilsoncusack gets at this a bit in his post but I think a more rigorous quantitative and qualitative definition would be useful in figuring out a) how to test and b) assuming test results positive, how to roll out to all existing pools
  • a plan for converting long-tail shitcoins into useful stables (a la 1Inch) and a backtest run on that plan including a sensitivity analysis on what happens when LPs leave in varying quantities.

I would be hugely supportive of anyone that wants to propose that type of research and am happy to be a sounding board for anyone that’s thinking along those lines.


I just created an account. I am an LP in uniswap v1, v2 and now in v3. The only reason I am a LP is because the fees. I am against reducing this fee in any way of form.

TL;DR: I am 100% supportive of this proposal to add the 1/10 protocol fee to a selected number of “sister” pools.

I propose to first activate it for the following pools:

  • DAI-ETH-0.05%
  • USDT-ETH-0.3%
  • USDC-ETH-1%

The Uniswap Grants program (or internal research) should then study the effects of the protocol fee on LP revenue to guide the general decision-making process for fee activation.

I think a major consideration here is whether or not liquidity providers remove liquidity as a result.

The impact on the revenue liquidity providers for doing so will be minimal, here’s why.

First, one has to understand where fees come from. While fees obviously result from trading activity, the way orders are routed play an important role in how much volume each pool gets.

Transactions will always be routed to the pool that minimizes the slippage, which means that the 0.05% fee pool will “allow” more transactions through because it will always capture all transactions between 0.05% and 0.3% slippage limit.

We can see the price of each pool and the number of transactions in each pool for the ETH-USDC pools:

Note how the price in the lower left panel is much finely-grained for the 0.05% than for the 1% pool. However, the 1% pool sees larger jumps between trades. But each of these pools should track the same price and, by association, each pool should have the same properties, including the fees collected and the price’s realized volatility.

How does volatility relate to LP revenues? I explicitly derived this relationship between volatility (which is related to expected revenues), feeTier, liquidity and dailyVolume in several post (this post is the most relevant), and it is given by

where gamma γ is the feeTier+protocolFee, and LP revenue is ~Impl.Vol * √timeInPool

Therefore, regardless of the feeTier+protocolFee, each pool of the same asset pair should generate the same amount of fee per unit of liquidity. An intuitive way to think about this is that if PoolA generates less revenue than PoolB, then rational LPs will relocate their liquidity to PoolB to capture that edge.

This is also true if we look between the ETH-stablecoin “sister pools” like ETH-USDC/DAI/USDT: they should all generate the same revenue as long as the keep the same peg, and that means they should all have the same implied volatility.

Is this really a valid assumption? If we look at the implied volatility as derived above for all ETH-stablecoin pairs, we see that the IV for all pool are somewhat consistent at around 130% for most pools:

hint: rational LPs should re-deploy liquidity to the high IV pools to maximize revenue

There are a couple of outliers, but let me focus on the USDC/ETH pools:

  • USDC/ETH 0.05%: IV = 116%
  • USDC/ETH 0.3%: IV = 131%
  • USDC/ETH 1%: IV = 125%

While each pool has a different feeTier, transaction routing means that each pool gets a different amount of daily volume, and this daily volume is matched by a different amount of “tick liquidity” that minimized slippage. This, in a way, magically brings them all within a similar implied volatility and LP revenue range, but there is no clear trend (we have IV: 0.3% > 0.05% > 1%, but volume is: 0.05% > 0.3% > 1% and tickTVL is: 0.3% > 1% > 0.05%).

Hence, I predict that activating a 1/10 protocol fee to any one of those pools would re-shuffle some of the liquidity provisioning, but all pools will still converge to the same IV and LP revenue at the end of the day.

So, I propose that the Uniswap Governance enables the 1/10 protocol fees for a few ETH-stablecoin sister pools and use the Uniswap Grants program (or internal research) to study the effects of the protocol fee on LP revenue.

The pools could be:

  • Dai/ETH 0.05%
  • ETH/USDT 0.3%
  • USDC/ETH 1%

Or any combination of ETH-stablecoin pools across non-overlapping feeTiers.


Super interesting discussing so far! Two things, I’d like to add:

  1. We’ve recently done some research related to the fee switch question. More precisely, we modelled how high the take rate (or “protocol fee”) should optimally be. For more details, see this post: Research on the Fee Switch
    That being said, for the beginning, the lowest possible value, i.e. 1/10 = 10%, as suggested by the proposal, is probably a good choice.

  2. One crucial question that could be answered by experimenting with the fee switch, is measuring how strong Uniswap’s moat is over other DEXs. (In a fully rational market, the DEX with the lowest protocol fee should attract most liquidity and volume. But in reality, Uniswap, as the clear market leader, likely has an competitive advantage over other DEXs, and can afford a higher protocol fee. The question is, by how much?)
    However, one Uniswap v3 pool of course has no moat over another. So this effect could not be measured, if the fee switch is only flipped for one fee tier for a certain pair.
    Instead, flipping the switch for all fee tiers for a certain pair could be considered (maybe for a “less important” token pair?).

Finally, a more philosophical thought :slight_smile:

In the long run, it might be inevitable that a part of trading fees goes to UNI token holders - simply due to the fact that exactly these token holders can decide on the matter.
The longer token holder receive no rewards, and the lower the expectation of this happening in the future becomes, the more the value of UNI tokens declines. Until at some point, it becomes cheap enough for someone to buy a sufficient amount of UNI tokens to vote to distribute fees to token holders (including themselves).