Tracking error due to fees, and oracle may undervalue LP shares by to-be-accrued fees

[livnev]

There might be two subtleties relating to LP fee accural in Uniswap which affect the accuracy of this oracle:

(i) for the purpose of valuing the shares, this oracle assumes that the assets in the pool will eventually be rebalanced such that the balances of the two assets represent equal value. This assumption is necessary in order for the LP price oracle to be resistant to manipulation of pair balances (by sanwiched back-and-forth trading, for example). However, the assumption is not exactly accurate due to the presence of the 0.30% taker fee (in the current Uniswap code), meaning that if "full arbitrage" occurs it will only take the balances to a ratio that is 0.30% away from "market value". This 0.30% discrepancy is always "in favour of the LPs" meaning that the oracle effectively undervalues the LP shares by up to 0.30% in these instances (and by less when the price implied by current balances is less than 0.30% away from "market value").

For an example of an oracle implementation which does not have this discrepancy, (probably) at the cost of burning more gas, see here. The tl;dr is that this implementation simulates the effects of an actual profit-maximising trade on the balances of the pool, instead of using the elegant but simplified formulas in this repo.

(ii) the effect of protocol fee accrual on the value of LP shares is not taken into account. Specifically, the implementation in this repo relies on the hypothesis that sqrt(res0 * res1) / totalSupply is invariant across trades, mints, and burns. In fact, this quantity is not quite invariant, since it can increase by the accrual of taker fees, but this growth is precisely the discrepancy described in (i) above which results in a slight undervaluation of the shares by the oracle. However, due to the presence of the _mintFee function in Uniswap, it is also possible for this invariant to decrease, when _mintFee is called from mint or burn, and a decrease in this invariant will result in an overvaluation of the shares, which is potentially more problematic for our purposes. Moreover, the magnitude of the overvaluation is not bounded by 0.30%, and can in theory be very large if mint or burn have not been called for a long time while a significant increase in sqrt(res0 * res1) / totalSupply has occured due to trading.

Explicitly, since the protocol fee is hardcoded to ~17% (while currently disabled), the oracle will overvalue the LP shares by 17% of the fee growth since the last call to mint or burn. Taking GRT/USDC, a pool with currently very high fee revenue, as an example, we see that if mint or burn have not been called for a day, then the shares will be overvalued by ~0.35%, and if no one calls it for a week they will be overvalued by 2.4%, etc. Obviously, it is very unlikely that the pool will go for so long without any mint or burn, and I am not aware of any way to stop them from being called or otherwise force this outcome, but it is still worth keeping in mind by anyone consuming this oracle, since in some cases this could be problematic.

Incidentally, the oracle implementation linked earlier, explicitly accounts for _mintFee here, avoiding this problem. Another way around it would have been to somehow call _mintFee before starting the calculations, however I don't see a way of doing that since minting or burning 0 shares is not allowed.

[livnev]

@NiklasKunkel assuming you are likely aware of both issues but thought it was worth writing them out here for brainstorming/clarity purposes.

[NiklasKunkel]

Thanks @livnev for bringing up such a detailed analysis of the LP Oracle. Indeed, we're aware the design does make some trade-offs in correctness in order to reduce complexity. Reducing gas costs was one factor, but so too was minimizing the chance for something to go catastrophically wrong. Leaving out the protocol and lp fees for the initial launch was a conscious decision made under the following assumptions:

1). Complex designs are harder to reason about making it difficult to harden potential attack surfaces.
2). The LP Oracle would be launched without a formal audit in order to introduce it into the protocol sooner and test for product-market fit.
3). The collateralization ratio of the DAI-ETH LP ilk in combination with the historical volatility means that the deviation from the true price is within tolerable bounds with regards to liquidation risks.
4). Exposure would be limited by limiting the debt ceiling due to smart-contract risk of the Oracle.

With respect to the protocol fees (ii) we've done some preliminary work in the fees branch.

Re: (i) this is something I'd like to explore further after the holidays.

[brianmcmichael]

Hey @livnev awesome analysis, and very useful for someone who is relying on this for pricing.

We're currently exploring fee accrual as Nik mentioned but now that I've had a chance to fully grok this issue I'm wondering if it's something worth solving at the expense of the additional overhead it requires. Our current LP token targets are high-liquidity, high-volume exchanges, so, for now, we don't need to worry about mints and burns being called regularly, it'll just happen. If these V2 exchanges fall out of favor in the community we could reduce the ceilings and fees to compensate the additional risk.

The problem here seems to be, as you mentioned, some of the more long-tail LP exchanges that maybe don't see regular liquidity injections or withdrawals. I think the system may be able to handle a deviation of even a couple of percent to the high side on these tokens, which we could offset with a slightly higher collateralization ratio on these long-tail tokens to compensate for this risk.

This actually makes me more comfortable using this oracle for the existing collateral system, but does leave some question about this oracle's precision and desirability as an accurate price gauge. It almost makes sense to just monitor these pools outside of this contract and mint/burn on a given exchange if it hasn't been done for a while.