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!
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.
Specification:
- USDC / ETH @ 0.05%, initialize 1/10 “protocol fee”
- USDC / USDT @ 0.01%, initialize 1/10 “protocol fee”
Feedback!
This is an important decision, let’s discuss!
In accordance with governance procedures, I’ve created a temperature check vote here: Snapshot