wrapFactor: penalizing pairs of equivalent tokens in liquidity mining

Thanks @followthechain for summarizing this proposal formally here.

I wrote some python code to show in practice how it would work numerically. For example, the following pools would have the following final factors (tokens A, B and C are not considered equivalent to any other token, so they don’t have a penalty for being equivalent when paired with other tokens, unlike for example a pair like cDAI + aDAI would):

[0.75, 0.25], [‘A’, ‘B’] => 0.75
[0.75, 0.25], [‘cDAI’, ‘aDAI’] => 0.075
[0.49, 0.49, 0.02], [‘A’, ‘B’, ‘C’] => 0.9359
[0.49, 0.49, 0.02], [‘cDAI’, ‘aDAI’, ‘DAI’] => 0.0936
[0.49, 0.49, 0.02], [‘cDAI’, ‘aDAI’, ‘C’] => 0.1572
[0.49, 0.49, 0.02], [‘cDAI’, ‘B’, ‘DAI’] => 0.9041

The code can be found here: https://gist.github.com/FernandoMartinelli/c95603767092c5237c4643aef5faaf4b

This proposal has been welcomed and no objections have been raised by the community. It will be used from the third week of BAL liquidity mining onwards. The third week starts tomorrow, Monday Jun 15th at 00:00 UTC.

PS: synthetic tokens like sETH are not considered equivalent to their underlying because there is a floating peg between them and the underlying. Therefore, having pools with synthetics and their underlying tokens has been deemed by the community as useful liquidity. This is different from tokens that can be just wrapped into one another (like DAI and CHAI, cDAI etc) which this proposal aims to penalize.

2 Likes