Introduction
The Balancer Labs team did its best to keep our initial proposal for Liquidity Mining simple. At the same time, we welcome improvements suggested by the community to ensure the distribution of BALs is as fair as possible towards all Balancer liquidity providers. We expect that the mining formula will continue to evolve over time as we explore how different forms of liquidity add value to the platform.
A few days after BAL liquidity mining started, a few active community members have raised some very legitimate shortcomings in the current method of calculating the weekly BAL distribution (a special shoutout to @rabmarut).
Namely, while different pools may have the same total liquidity in USD terms and even have the same fee (and therefore same feeFactor), they contribute less to trading volume if their weights are imbalanced. A 60/40 pool generates more trades (and is thus more prone to impermanent loss) than a 90/10 pool. This proposal aims to compensate for this by reducing the amounts of BAL distributed to pools as they deviate from perfect balance.
The Proposal
The efficiency of a two-token pool in generating trading volume is proportional to the multiplication of its weights. We propose to use this efficiency measure as an extra ratioFactor that will be multiplied by the pool liquidity in the same manner as the feeFactor.
In order to have a base line factor of 1 when a pool is perfectly balanced (50/50 pool) we add a factor of 4 to the multiplication:
Notice how this factor is equal to 1 for a 50/50 pool and tends to zero as weights go off balance towards 0/100 or 100/0.
Since Balancer allows for up to 8 tokens in a pool, we propose that for pools with more than 2 tokens we consider the ratio factor for all possible pairs (in a pool with n tokens, there will be n*(n-1)/2 pairs). For each pair, we normalize the weights so that we can use the same ratio factor:
To finalize, instead of just calculating a simple average of the ratio factors of each of the pairs, we propose to weigh them by the multiplication of the pair weights. This ensures the desirable property that a pool with weights [49, 49, 2] has a factor very similar to a pool [50,50], which is 1. In other words, the imbalance of the two pairs [49, 2] will count much less than the balance of pair [49, 49].
The final formula proposed is then:
which can be re-written as:
Practical consequences
The following calculations show a mapping of [pools weigths] => ratioFactor using the formula proposed above:
[0.5, 0.5] => 1.0
[0.6, 0.4] => 0.96
[0.75, 0.25] => 0.75
[0.8, 0.2] => 0.64
[0.9, 0.1] => 0.36
[0.98, 0.02] => 0.0784
[0.333, 0.333, 0.333] => 1.0
[0.25, 0.25, 0.25, 0.25] => 1.0
[0.2, 0.2, 0.2, 0.2, 0.2] => 1.0
[0.49, 0.49, 0.02] => 0.9359
[0.45, 0.45, 0.1] => 0.8754
[0.4, 0.4, 0.2] => 0.9444
[0.4, 0.3, 0.3] => 0.9852
Notice that if some of the tokens are not eligible for liquidity (because they are not listed on CoinGecko), they can just be considered as having weight 0. If a pool has $100k across 5 tokens with equal weights and two are not eligible, it will have a ratio factor of 1 but only $60k of its liquidity will be considered:
[0.2, 0.2, 0, 0.2, 0] => 1.0
[0, 0.3, 0.3] => 1.0
[0.4, 0.1, 0] => 0.64
Start date
So far the community feedback on discord about this proposal has been pretty positive: the initiative and idea itself came mostly from the community, not from the Balancer Labs team. If this proposal is welcomed in the next 3 days, we would like to already implement it for the second week of liquidity mining which starts on Monday, June 8th, at 00:00 UTC.