UniFees

"Dynamic fees" has been a topic of interest since a while now. Balancer and Gauntlet have tried to implement it as early as 2021. However, a widely accepted and hailed model for determining the right fee rate hasn't yet materialised. I would like to quote the following excerpt from the article "Why Use a Dynamic Fee for Liquidity Pools?":

"...However, notably, the discussion of dynamic fees has typically focused on a theoretical setting where the DEX is assumed to be operating in a relatively stylized environment, without other competing sources of liquidity aside, perhaps, from a reference exchange where price discovery occurs. Although the theoretical question of what the “best model” of dynamic fees is remains important..." (Source: https://crocswap.medium.com/why-use-a-dynamic-fee-for-liquidity-pools-def07a1e6c3b)

So, what is the "best model" of dynamic fees? We theorize that providing liquidity is a service that depends on too many factors to capture in a model. To use a model to determine the best fee rate is the same as using a model to find the worth of liquidity. It's the same as using a model to find the worth of a house. It can be done, but it can't be perfect.

And that's why we have a free market for goods, assets and services. In that vein, we seek to provide each LP with the right to decide their own fee rate. And when their liquidity is used for a swap, their own fee rate will be applied. Just as in a regular market, the cheapest liquidity, i.e. the liquidity with the lowest fee rate, will be used first.

Implementation - We propose to use the following hook functions to enable the above design:

[Function] afterModifyPosition After modifying an LP position, the hook contract keeps track of the LP’s choice of fee rate in a mapping within the hook contract.

[Function] beforeSwap

1. In the current design, an offchain computation is made to determine the fee experienced by a swap given the liquidity profile prior to the swap. Note that the liquidity profile is composed of the usual liquidity values and tick ranges, and also the custom fee tiers for each LP position. The offchain computation can be provided by a pull based low latency oracle (the new chainlink low latency oracles fit the bill well) or by keepers.
2. The fee amount returned by the hook contract is used to change the pool fee (using the getFee function).
3. The hook also specifies that 100% of the swap fees are accrued to the hook

[Function] claim: The claim function, implemented in the hook contract, lets LPs claim their pro-rata share of fees.

Simple example: Say 2 LPs provide liquidity within the same tick range but with different fee tiers: 0.1% and 0.2%. In the event of an incoming swap, the liquidity provided at 0.1% will be used first and then the liquidity provided at 0.2%. For simplicity’s sake, let’s assume that the entirety of liquidity provided at 0.1% is used and half of the liquidity provided at 0.2% is used. In that case, a total fee of 0.15% is applicable. This calculation, of 0.15%, is done offchain as described in “beforeSwap'' above. Subsequently, and again before the swap, the pool fee is changed to 0.15%. The entirety of the fees from the swap is retained by the hook, and is claimable by LPs using a custom claim function.

UniFees is a hook smart contract on UniswapV4. It uses the core functionalities of UniswapV4 which are hooks. We used Foundry development framework to test the hook contract’s functionality.

As described above, an oracle is needed to calculate the fee amount. The univ4-fee-oracle in our github organisation contains this code.