This is an amendment to the balFactor proposal, in an attempt to specify how to calculate this factor.
Throughout discussions on Discord and the original post for this proposal, the spirit of the balFactor was to increase in 50% (by applying a 1.5 factor) the adjusted liquidity of the pairs in which BAL is included. So for instance a 50/50 BAL/WETH pool would have:
adjusted_liquidity = actual_liquidity * all_other_factors * 1.5.
Unfortunately, upon closer inspection this simple rule revealed itself a bit too vague.
For instance, it would be clearly unfair if these pools got the same 1.5 balFactor:
- a
50/50 BAL/WETHand a10/90 BAL/WETH; - a
90/10 BAL/WETHand a10/90 BAL/WETH; - a
25/25/25/25 BAL/WETH/cappedTokenA/cappedTokenBand a25/25/25/25 BAL/WETH/DAI/WBTC.
It then became clear what we need is just a modification on the calculation of the ratioFactor, in which it gets applied a balFactor proportional to the weight of BAL in
each pair of the pool, so that the newRatioFactor (that is, balFactor * ratioFactor) of a 50/50 BAL/WETH would go from 1 to 1.5.
The solution proposed by @rabmarut to achieve this result is to have a balMultiplier = 2 applied only to the BAL side of the pair during the ratioFactor calculation. Code by @mike available at https://github.com/balancer-labs/bal-mining-scripts/blob/master/index.js#L32-L91
Some examples of results in the format
[ tokens ] | [ weights ] : ratioFactor => newRatioFactor:
['WETH', 'USDC', 'BAL', 'ABC', 'BCD', 'CDE', 'DEF', 'EFG'] | [0.125, 0.125, 0.125, 0.125, 0.125, 0.125, 0.125, 0.125] : 1.00 => 1.04
['WETH', 'USDC', 'BAL'] | [0.49, 0.49, 0.02] : 0.94 => 0.94
['WETH', 'BAL'] | [0.8, 0.2] : 0.64 => 0.77
['WETH', 'BAL'] | [0.7, 0.3] : 0.84 => 1.09
['WETH', 'BAL'] | [0.6, 0.4] : 0.96 => 1.34
['WETH', 'BAL'] | [0.5, 0.5] : 1.00 => 1.50
['WETH', 'BAL'] | [0.49, 0.51] : 1.00 => 1.51
['WETH', 'BAL'] | [0.48, 0.52] : 1.00 => 1.52
['WETH', 'BAL'] | [0.47, 0.53] : 1.00 => 1.52
['WETH', 'BAL'] | [0.46, 0.54] : 0.99 => 1.53
['WETH', 'BAL'] | [0.45, 0.55] : 0.99 => 1.53
['WETH', 'BAL'] | [0.44, 0.56] : 0.99 => 1.54
['WETH', 'BAL'] | [0.43, 0.57] : 0.98 => 1.54
['WETH', 'BAL'] | [0.42, 0.58] : 0.97 => 1.54
['WETH', 'BAL'] | [0.41, 0.59] : 0.97 => 1.54
['WETH', 'BAL'] | [0.4, 0.6] : 0.96 => 1.54
['WETH', 'BAL'] | [0.39, 0.61] : 0.95 => 1.53
['WETH', 'BAL'] | [0.38, 0.62] : 0.94 => 1.53
['WETH', 'BAL'] | [0.37, 0.63] : 0.93 => 1.52
['WETH', 'BAL'] | [0.36, 0.64] : 0.92 => 1.51
['WETH', 'BAL'] | [0.35, 0.65] : 0.91 => 1.50
['WETH', 'BAL'] | [0.34, 0.66] : 0.90 => 1.49
['WETH', 'BAL'] | [0.33, 0.67] : 0.88 => 1.48
['WETH', 'BAL'] | [0.32, 0.68] : 0.87 => 1.46
['WETH', 'BAL'] | [0.31, 0.69] : 0.86 => 1.45
['WETH', 'BAL'] | [0.3, 0.7] : 0.84 => 1.43
['WETH', 'BAL'] | [0.2, 0.8] : 0.64 => 1.15
For the 2-tokens pool of type BAL/uncappedToken, this is the effect of the newRatioFactor as a function of BAL weight:
Finally, the community members discussing the matter widely agreed this method did not insert unwanted complexity, and the results yielded were very well aligned with the spirit of the original proposal.