When takers pay their fees, they pay their taker rate using the amounts of token0 and token1 based on the geometric mean price of the interval (in Data.computeBorrows):
For example, if there is 1e18 taker liquidity in the [-122880..245760] range, the borrow amounts for this interval should be:
- borrowX = 0.046e18
- borrowY = 21.6e18
The issue is that since a segment tree is used to store taker liquidity, internally it's broken into 2 segments, and the amounts of token0 and token1 are calculated based on the geometric mean of each segment rather than original price, which inflates borrow amounts a lot:
- for [-122880..0]: borrowX = 20.6e18, borrowY = 0.044e18
- for [0..245760]: borrowX = 0.00214e18, borrowY = 464.7e18
The sum of these borrow amounts is: borrowX = 20.6e18, borrowY = 464.8e18. It is at least 200x times more than the expected borrow amount.
With a 10% taker rate, taker expects to pay 0.0046e18 token0 and 2.16e18 token1. However, due to how the liquidity is stored and calculated, the taker will pay 2.06e18 token0 and 46.48e18 token1.
Alpha: essentially depending on the state, that is, the number of segments at a certain time, the fees paid vary significantly, which is inconsistent, and should always be reported. Always make sure the fees are consistent.
Conclusion
This finding would earn you $4432, requiring knowing how exactly fees work, and how they can vary wildly for the same outcome.