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.