Modifying wrapFactor: applying a 0.7 factor to SOFT-pegged pairs

Read the formatted version of this proposal at: https://forum.balancer.finance/t/modifying-wrapfactor-applying-a-0-7-factor-to-soft-pegged-pairs/108 The content below has been slightly edited for clarity on a text-only format (e.g. equations substituted from image to text).

TL,DR Proposal to apply a wrapFactor = 0.7 to the liquidity of every pair of soft-pegged tokens for the purposes of liquidity mining distribution, in an effort to attract more useful liquidity to the protocol.

Context The original proposal approved about a month ago applied a wrapFactor = 0.1 for hard-pegged tokens, i.e. tokens that are equivalent to each other. Example: {USDC & cUSDC}.

Read more: wrapFactor: penalizing pairs of equivalent tokens in liquidity mining 3

Since then, we have seen the rise of pools that are not subject to that wrapFactor, but contain tokens that track the same asset and are naturally highly correlated. These are being called soft-pegged pairs. Example: {USDC & mUSD}.

Liquidity in soft-pegged pairs usually attracts relatively little trading volume on Balancer while at the same time exposing LPs to a lower risk of impermanent loss. Many community members have expressed their concerns about this type of liquidity being unfairly highly compensated by the current mining distribution rules with their less useful liquidity. Some believe the wrapFactor for the soft-pegged pairs should be as low as 0.3. Others believe it should not apply at all.

After weeks of much debate, it seems 0.7 is a reasonable compromise. For being a contentious topic, a final decision has been postponed until a voting tool using BAL tokens was implemented. This value could be revised (up or down) at some point in the future, according to community sentiment regarding the practical results observed.

The Proposal For every pair, we analyze:

Is this a hard-pegged pair? If so, wrapFactor = 0.1; If not, is this a soft-pegged pair? If so, wrapFactor = 0.7; If not, wrapFactor = 1.0 (i.e. no liquidity adjustment from the wrapFactor). Other examples of soft-pegged pairs:

{renBTC & WBTC} (both track BTC), {DAI & cUSDT} (both track USD), etc. Further Considerations All liquidity in compliant ERC20 tokens is welcome in Balancer pools, but BAL distribution is a scarce weekly resource (i.e. for an LP to get more BAL, other LPs have to get less). So penalizing soft-pegs is the equivalent of giving an extra incentive for liquidity that has shown itself more useful to the protocol. The 0.7 value has been seen (apparently by most community members) as a conservative measure, that doesn’t drastically alter the current incentives for liquidity and is an adequate value with which to move forward.