I had a similar thought to zeroing out any fee switch profit. I am not entirely convinced about using the fee switch for LPing incentives as it creates a profitability structure.
Here are some additional potential frictions to consider:
-
Requiring a proposal vote and votes by the UNI DAO for every pool is asking for a lot of engagement on both sides. The proposer(s) need to set up the framework for the specific pool, and the UNI DAO members need to be attentive to voting and reviewing the feasibility of that proposal versus other proposals.
-
How do incentives for LPing (the backend) increase user engagement (front-end users) with the UNI DAO?
A user-driven incentive will encourage projects to participate in fee switch pools.
Difference between LP incentives and User incentives:
LP incentives allow for better pricing for the user on the backend (reduced slippage, potentially better oracles for wide ranges). While a fee rebates give similar outcomes in attracting more LPing, while also driving more volume and giving a more forward-facing increase in user experience.
User volume engagement increases LP profitability potential:
-
The cost of gas for the user being paid by the fee switch zeros out profitability with a transaction cost.
-
More trading volume from an easier user experience means more incentive to LP.
-
Two birds with one fee switch: focusing on the user through gas rebate, etc., will also attract liquidity to the higher volume pools, accomplishing similar goals to the reduced slippage of LP incentives without a profitability structure.
I do like that this proposal allows flexibility from projects to activate pool fee switches. I think this is the right approach. My main concern comes from the proposal being structured around the use case of Liquidity provisions (and potential engagement/on-chain voting friction). I would be more inclined to a fee switch covering opt-in from the user side.