balFactor: incentivizing BAL liquidity on Balancer

Governance Liquidity Mining [deprecated]
1

TL,DR

Proposal to apply a balFactor = 1.5 to the liquidity of every “useful BAL pair”, i.e. { BAL & one of the uncapped tokens (currently WETH, DAI, USDC, WBTC) }, along with a capFactor to BAL adjusted liquidity (i.e. after applying the other factors: ratio, wrap, fee) in case it exceeds $50M. The goal is to increase the incentive for liquidity provisioning with BAL, which should increase BAL liquidity therefore providing better conditions for a wider distribution of BAL ownership.

Context

Users @jammy, @Lex Moskovski and others at the #liquidity-providers channel on Balancer’s Discord came up with the idea of increasing incentives for BAL pools. After a lot of considerations from multiple people and refining on that initial idea, the community ended up voting (on 2020-07-10) on the creation of a balFactor:

image
image912×519 24.2 KB

As it was bound to happen at some point, Discord voting was not enough to reach consensus, and a final decision on the matter was postponed until a voting tool could be implemented taking into account the BAL (governance tokens!) balance of each community member.

The Proposal

Application of a capFactor in similar terms as described in the original capFactor proposal, limiting the BAL adjusted liquidity to $50M.

After the capFactor for all capped tokens has been calculated (to correct down an eventually excessive adjusted liquidity for each capped token), a balFactor of 1.5 is applied to every pair of type {BAL & uncapped_token}.

Further Considerations

Pairs with capped tokens do not qualify for the balFactor, so that pairs of questionable trading demand/utility (e.g. {BAL & cBAT}) are not incentivized.

The $50M cap is more of a safety measure, in place just for the unlikely scenario where the balFactor results in huge and unnecessary BAL liquidity coupled with an unreasonable BAL price spike. Such a scenario is automatically neutered by the cap. For instance, with $100M of BAL adjusted liquidity, the liquidity in all BAL pairs is cut in half for the purposes of liquidity mining distribution (i.e. capFactor_BAL = min(100M, 50M)/100M = 0.5, as explained in the capFactor proposal).

4 Likes
2

I support this initiative.

Wider distribution of BAL tokens is really the goal here and generates a positive feedback loop.

  1. Convert some farmers to BAL token holders that are now invested in the success of the platform (governance participation). These farmers are currently dumping weekly yield.

  2. Take advantage of the DeFi network effects from protocols bootstrapping their projects with Balancer, see 1, to gain new BAL holders

Before v2, value capture will be dependent on supply/demand. This will likely control the supply side. We need to incentivize holding/pooling/accumulating, which will in turn lead to more interest in governance down the road.

1 Like
3

Great Initiative

Increasing the BAL Pools will permit to have more stable price as we will have more capital that will support BAL Price and will make it harder to move. The liquidity providers will suffer some losses in case BAL price goes down, but the will profit from comissions and they will increase the BAL amount for the Long term.

At some point I think it will be also important for the BAL Holders to can accrue some value of the Balancer activity, meanwhile that initiative will reward BAL Holders for the risk.

4

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/WETH and a 10/90 BAL/WETH;
  • a 90/10 BAL/WETH and a 10/90 BAL/WETH;
  • a 25/25/25/25 BAL/WETH/cappedTokenA/cappedTokenB and a 25/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

image
image1064×2160 245 KB

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:

image
image1719×1290 224 KB

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.

4 Likes