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

5325235235235 · July 30, 2020, 7:51am

TL,DR

Proposal to apply a wrapFactor = 0.2 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 2 weeks ago applied a wrapFactor = 0.7 for soft-pegged tokens, i.e. 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 liquidity providers 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. The introduction of 0.7 wrapFactor did not stop the explosion in size of soft-pegged pools chasing low risk yield on Balancer. Majority of publicity that Balancer recently got was related to sky high rewards for supplying soft-pegged liquidity.

After much debate, it seems that 0.2 is a reasonable compromise. This value could be revised (up or down) at some point in the future, according to community sentiment regarding the practical results observed. This is unlikely to happen within the next month.

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.2;
If not, wrapFactor = 1.0 (i.e. no liquidity adjustment from the wrapFactor).

Examples of soft-pegged groups:
{WBTC, renBTC, pBTC, sBTC, imBTC, cWBTC, BTC++} (all track BTC),
{DAI, cUSDT, mUSD, USDC, sUSD, USD++, TUSD, yUSD-SEP20, aUSDT, aTUSD, aUSDC, aBUSD, oaUSDC, aSUSD, USDx, aDAI, yDAI+yUSDC+yUSDT+yTUSD} (all track USD),
etc.
All the above are pooled on Balancer.

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). Penalizing soft-pegs is the equivalent of giving an extra incentive for liquidity that has shown itself more useful to the protocol. The 0.2 value has been seen (by most community members) as a reasonable measure, that will be good for the future of Balancer.

We feel that liquidity composition on Uniswap is natural, while the composition on Balancer is highly skewed towards soft-pegged assets due to very generous rewards. We hope that liquidity composition will improve with wrapFactor 0.2.

Many believe that the pools like the extreme examples below are earning rewards that are too generous:
WBTC-imBTC-pBTC-sBTC: 1.2m liquidity, $0 24h volume
cUSDC-cUSDT: $1.3m liquidity, $0 24h volume
cUSDC-cUSDT: 1m liquidity, $0 24h volume
cUSDC-cDAI: 200k liquidity, $0 24h volume

1A1zP1eP5 · August 1, 2020, 12:11am

Can you please spell out all of the assets and pools that will be impacted? It makes sense to reduce the rewards for pools that have no volume, but do we really want to apply this to pools such as WBTC/renBTC that do have volume and valid use cases? (e.g. diversification of smart contract/ centralization risks, etc.)

5325235235235 · August 1, 2020, 11:57am

WBTC/renBTC pool has a valid usecase. However, liquidity providers in soft-pegged pools like this are not exposed to impermanent loss as much as others are. The proposal shifts rewards to volatile pools while retaining some rewards for these useful pools. Soft-pegged pools will still have very generous APY from BAL rewards and decent returns thanks to Balancer being currently optimized for volatile pairs (large slippage relative to providers like Curve).

The up to date list can be found here:

github.com

balancer-labs/bal-mining-scripts/blob/master/index.js

const Web3 = require('web3');
const BigNumber = require('bignumber.js');
const cliProgress = require('cli-progress');
const fs = require('fs');
const { argv } = require('yargs');

const utils = require('./utils');
const poolAbi = require('./abi/BPool.json');
const tokenAbi = require('./abi/BToken.json');

const web3 = new Web3(
    new Web3.providers.WebsocketProvider(`ws://localhost:8546`)
);

BigNumber.config({
    EXPONENTIAL_AT: [-100, 100],
    ROUNDING_MODE: BigNumber.ROUND_DOWN,
    DECIMAL_PLACES: 18,
});

This file has been truncated. show original

under equivalentSets =

const equivalentSets = [
[
[
‘0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2’, // WETH
‘0x3a3A65aAb0dd2A17E3F1947bA16138cd37d08c04’, // aETH
‘0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5’, // cETH
‘0x77f973FCaF871459aa58cd81881Ce453759281bC’, // iETH
‘0xf53AD2c6851052A81B42133467480961B2321C09’, // PETH
],
[
‘0x5e74C9036fb86BD7eCdcb084a0673EFc32eA31cb’, // sETH
],
],
[
[
‘0x6Ee0f7BB50a54AB5253dA0667B0Dc2ee526C30a8’, // aBUSD
],
[
‘0x6B175474E89094C44Da98b954EedeAC495271d0F’, // DAI
‘0xfC1E690f61EFd961294b3e1Ce3313fBD8aa4f85d’, // aDAI
‘0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643’, // cDAI
‘0x493C57C4763932315A328269E1ADaD09653B9081’, // iDAI
‘0x261b45D85cCFeAbb11F022eBa346ee8D1cd488c0’, // rDAI
‘0x16de59092dAE5CcF4A1E6439D611fd0653f0Bd01’, // yDAI
‘0x06AF07097C9Eeb7fD685c692751D5C66dB49c215’, // CHAI
],
[
‘0xe2f2a5C287993345a840Db3B0845fbC70f5935a5’, // mUSD
],
[
‘0x8E870D67F660D95d5be530380D0eC0bd388289E1’, // PAX
],
[
‘0x196f4727526eA7FB1e17b2071B3d8eAA38486988’, // RSV
],
[
‘0x57Ab1ec28D129707052df4dF418D58a2D46d5f51’, // sUSD
‘0x625aE63000f46200499120B906716420bd059240’, // aSUSD
‘0x49f4592E641820e928F9919Ef4aBd92a719B4b49’, // iSUSD
],
[
‘0x0000000000085d4780B73119b644AE5ecd22b376’, // TUSD
‘0x4DA9b813057D04BAef4e5800E36083717b4a0341’, // aTUSD
],
[
‘0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48’, // USDC
‘0x9bA00D6856a4eDF4665BcA2C2309936572473B7E’, // aUSDC
‘0x39AA39c021dfbaE8faC545936693aC917d5E7563’, // cUSDC
‘0xF013406A0B1d544238083DF0B93ad0d2cBE0f65f’, // iUSDC
‘0xd6aD7a6750A7593E092a9B218d66C0A814a3436e’, // yUSDC
],
[
‘0x71fc860F7D3A592A4a98740e39dB31d25db65ae8’, // aUSDT
‘0xf650C3d88D12dB855b8bf7D11Be6C55A4e07dCC9’, // cUSDT
],
[
‘0x9A48BD0EC040ea4f1D3147C025cd4076A2e71e3e’, // USD++
],
],
[
[
‘0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599’, // WBTC
‘0xFC4B8ED459e00e5400be803A9BB3954234FD50e3’, // aWBTC
‘0xC11b1268C1A384e55C48c2391d8d480264A3A7F4’, // cWBTC
‘0xBA9262578EFef8b3aFf7F60Cd629d6CC8859C8b5’, // iWBTC
],
[
‘0x0327112423F3A68efdF1fcF402F6c5CB9f7C33fd’, // BTC++
],
[
‘0x3212b29E33587A00FB1C83346f5dBFA69A458923’, // imBTC
],
[
‘0x5228a22e72ccC52d415EcFd199F99D0665E7733b’, // pBTC
],
[
‘0xEB4C2781e4ebA804CE9a9803C67d0893436bB27D’, // renBTC
],
[
‘0xfE18be6b3Bd88A2D2A7f928d00292E7a9963CfC6’, // sBTC
],
],
[
[
‘0x0D8775F648430679A709E98d2b0Cb6250d2887EF’, // BAT
‘0xE1BA0FB44CCb0D11b80F92f4f8Ed94CA3fF51D00’, // aBAT
‘0x6C8c6b02E7b2BE14d4fA6022Dfd6d75921D90E4E’, // cBAT
],
],
[
[
‘0xF629cBd94d3791C9250152BD8dfBDF380E2a3B9c’, // ENJ
‘0x712DB54daA836B53Ef1EcBb9c6ba3b9Efb073F40’, // aENJ
],
],
[
[
‘0xdd974D5C2e2928deA5F71b9825b8b646686BD200’, // KNC
‘0x9D91BE44C06d373a8a226E1f3b146956083803eB’, // aKNC
‘0x1cC9567EA2eB740824a45F8026cCF8e46973234D’, // iKNC
],
],
[
[
‘0x80fB784B7eD66730e8b1DBd9820aFD29931aab03’, // LEND
‘0x7D2D3688Df45Ce7C552E19c27e007673da9204B8’, // aLEND
],
],
[
[
‘0x514910771AF9Ca656af840dff83E8264EcF986CA’, // LINK
‘0xA64BD6C70Cb9051F6A9ba1F163Fdc07E0DfB5F84’, // aLINK
‘0x1D496da96caf6b518b133736beca85D5C4F9cBc5’, // iLINK
],
[
‘0xbBC455cb4F1B9e4bFC4B73970d360c8f032EfEE6’, // sLINK
],
],
[
[
‘0x0F5D2fB29fb7d3CFeE444a200298f468908cC942’, // MANA
‘0x6FCE4A401B6B80ACe52baAefE4421Bd188e76F6f’, // aMANA
],
],
[
[
‘0x9f8F72aA9304c8B593d555F12eF6589cC3A579A2’, // MKR
‘0x7deB5e830be29F91E298ba5FF1356BB7f8146998’, // aMKR
],
],
[
[
‘0x408e41876cCCDC0F92210600ef50372656052a38’, // REN
‘0x69948cC03f478B95283F7dbf1CE764d0fc7EC54C’, // aREN
],
],
[
[
‘0x1985365e9f78359a9B6AD760e32412f4a445E862’, // REP
‘0x71010A9D003445aC60C4e6A7017c1E89A477B438’, // aREP
‘0x158079Ee67Fce2f58472A96584A73C7Ab9AC95c1’, // cREP
‘0xBd56E9477Fc6997609Cf45F84795eFbDAC642Ff1’, // iREP
],
],
[
[
‘0xC011a73ee8576Fb46F5E1c5751cA3B9Fe0af2a6F’, // SNX
‘0x328C4c80BC7aCa0834Db37e6600A6c49E12Da4DE’, // aSNX
],
],
[
[
‘0xE41d2489571d322189246DaFA5ebDe1F4699F498’, // ZRX
‘0x6Fb0855c404E09c47C3fBCA25f08d4E41f9F062f’, // aZRX
‘0xB3319f5D18Bc0D84dD1b4825Dcde5d5f7266d407’, // cZRX
‘0xA7Eb2bc82df18013ecC2A6C533fc29446442EDEe’, // iZRX
],
],
];

notnoteric · August 1, 2020, 1:53pm

Strongly against. Soft-pegged pairs are the ONLY useful liquidity on Balancer in the long term. For non-pegged pairs the simple invariant balancer uses as its AMM. Think about it—if market-making was really that easy, then anyone could copy the AMM algo and make a ton of money on centralized exchanges. While having non-soft pegged assets has some utility in providing liquidity to the assets that exchanges don’t want to list, in the long term most non-soft peg liquidity will go to CLOB defi protocols once technically feasible on ETH 2.0. Balancer’s strength is in providing liquidity to soft-pegged assets, and I believe we should use the liquidity mining program to specialize as much as possible into that niche.

To address some common criticisms of rewarding soft-pegged pairs:

The only reason some soft pegged pairs don’t have much liquidity now (ie cUSDC/cUSDT) is because aggregators like 1inch have not written the unwrapping logic for compound yet.
The soft-pegged pairs on Balancer are different from something like Curve only supports limited assets—the beauty of Balancer is that anyone can come up with some token like UMA’s yUSD and list it on Balancer. Curve’s niche is providing deep liquidity on a small number of soft-pegged assets, Balancer’s should be providing decent liquidity on a every soft-pegged asset.

tldr: Vote AGAINST modifying wrap factor

1A1zP1eP5 · August 1, 2020, 2:30pm

Thanks, 5325235235235. It feels like we need more robust logic to determine what’s a useful pair and what’s not. Something that takes into account the use cases of each pool may be a bit more fair and would not penalize pairs that may bring in significant volume in the future. Additionally, the impermanent loss criteria feels somewhat misguided. Just because BTC, ETH, etc. are in a bull market right now doesn’t mean that it will always be that way. If you use impermanent loss as a criteria you are embedding an always-bullish bias into the protocol. In a bear market, people holding a % of USD will be double compensated and pools with heavy BTC, ETH allocations will dry up. I think we should have a more neutral distribution so that pools that have valid use cases remain available throughout bull and bear markets.

5325235235235 · August 1, 2020, 10:56pm

“Soft-pegged pairs are the ONLY useful liquidity on Balancer in the long term”
I believe that this statement is completely wrong.

1A1zP1eP5: I think that the proposed method is simple, easy to understand and very effective.

1A1zP1eP5 · August 2, 2020, 1:25am

5325235235235: Yeah, okay. I guess can always adjust later on if needed. Thanks for your work on this.

5325235235235 · August 2, 2020, 11:28am

Here are some more numbers:

sUSD - USDC $7m — $17k 24h volume
sETH - WETH $9.2m — $103k 24h volume
WBTC-renBTC $7.5m — $88k 24h volume

1A1zP1eP5 · August 5, 2020, 6:02pm

Thanks. That’s one point in time. Here are some more numbers from the past 24h:

USDC/mUSD $25M - 1.1M in 24h volume (2nd highest)
sETH/WETH $8.8M - 500K in 24h volume (5th highest)

But, the “returns” for these pools are lowest among the top 10 pools by volume.

inq08 · August 10, 2020, 3:34am

So did this pass? Where can I see what has been incorporated and what has not been incorporated? I tried to check the github code with my non-dev eyes, and it appears the soft wrap factor is still 0.7.

5325235235235 · August 10, 2020, 12:22pm

passed, implemented already

farshad6666 · January 20, 2021, 9:41am

Hi guys plz help me with bal in erc10 how to change it to erc20

rabmarut · January 20, 2021, 11:10pm

If this is in reference to the Tron wallet airdrop, it is most likely a scam - Balancer and the BAL token do not exist on the Tron chain.

Topic		Replies	Views
Modifying wrapFactor: applying a 0.7 factor to SOFT-pegged pairs Liquidity Mining [deprecated]	3	2512	July 18, 2020
wrapFactor: penalizing pairs of equivalent tokens in liquidity mining Liquidity Mining [deprecated]	2	3220	June 14, 2020
Introduction of a weight ratio factor in liquidity mining Liquidity Mining [deprecated]	3	4727	June 12, 2020
capFactor: capping eligible liquidity to $10M per token Liquidity Mining [deprecated]	1	3676	June 27, 2020
balFactor: incentivizing BAL liquidity on Balancer Liquidity Mining [deprecated]	3	3306	July 27, 2020

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

Related topics