BAL Whitelist - Round 16

On behalf of the Balancer community, I’d like to propose the following modifications to the token whitelist used for BAL governance distribution. As a reminder, these whitelist proposals are now pre-approved on objective technical criteria only, so they are not subject to community vote. All new tokens will be placed at cap1 for liquidity mining, meaning each token’s measured BAL-eligible liquidity is scaled to a maximum of $1M (at time of writing). At any time, community members may propose to increase a token’s cap to the next tier. For reference, please see the previous proposals which detail the motivation for creation of the whitelist and define the list of tokens used to date. Links are included at the end of this post.

Proposed Modifications

The following token has migrated to a new contract. I would like to propose modifying the existing whitelist entry for this token such that it points to the new contract. As a result, the old contract is no longer incentivized, and the new contract inherits the cap tier specified for the previous contract:

    MIGRATE	NOIA	0xfc858154C0b2c4A3323046Fb505811F110EBdA57	->	0xa8c8CfB141A3bB59FEA1E2ea6B79b5ECBCD7b6ca

The following token is a special entry. Ampleforth ($AMPL) is a rebasing token with dynamic supply. On every supply change, normal Balancer pools containing $AMPL are at risk of being gulp() attacked for a small loss of funds. However, Ampleforth and Balancer recently launched a USDC/AMPL smart pool which dynamically adjusts its asset weights on every $AMPL rebase. This behavior saves the smart pool - and only the smart pool - from the gulp() attack, and as such this whitelist entry will be the first to apply only to a single pool.

    ADD		AMPL	0xD46bA6D942050d489DBd938a2C909A5d5039A161	(pool: 0x7860e28ebfb8ae052bfe279c07ac5d94c9cd2937)

I would also like to propose adding the following new tokens to the whitelist:

    ADD		ADX		0xADE00C28244d5CE17D72E40330B1c318cD12B7c3
    ADD		DEFI+L	0x78F225869c08d478c34e5f645d07A87d3fe8eb78
    ADD		FTT		0x50D1c9771902476076eCFc8B2A83Ad6b9355a4c9
    ADD		HEGIC	0x584bC13c7D411c00c01A62e8019472dE68768430
    ADD		MTLX	0x2e1E15C44Ffe4Df6a0cb7371CD00d5028e571d14
    ADD		xSNXa	0x2367012aB9c3da91290F71590D5ce217721eEfE4

The proposed changes will go into effect at 00:00 UTC on Monday, October 12. Pools containing whitelisted tokens will begin to accrue BAL rewards beginning at 00:00 UTC on Monday; but they may not appear on the Balancer pools UI with symbol/logo until a bit later in the week, most likely Tuesday or Wednesday. Please be patient. Furthermore, whitelisted tokens will not be added to the Balancer exchange UI; the core team adds tokens to the official exchange UI at their own discretion and considers a variety of factors. Tokens can always be traded using contract addresses in place of symbols, and anyone is free to fork the open source exchange UI to add more symbols.

Resulting Soft/Hard Pegs

The following price pegs will be added to the BAL mining scripts in response to the whitelist changes. At time of writing, soft pegs receive a wrapFactor of 0.2 and hard pegs receive a wrapFactor of 0.1.

There are no definitive pegs introduced this week. Instead, there are two open-ended peg questions, which will need to be solved by community discussion and/or governance vote:

  1. Is AMPL soft-pegged to USD?
  2. Is xSNXa hard- or soft-pegged to SNX?


No requested tokens were omitted this week.

Reference: Prior Proposals

1 Like

great to see this!

would just like to point out that xSNXa is neither hard nor soft pegged to SNX. it’s a staking derivative

Is it not similar to, say, cDAI as a derivative of DAI? At Balancer we call cDAI-DAI a hard-pegged pair. The price will actually diverge over time, but ultimately cDAI is a claim on underlying DAI, and the price will track over short and medium time frames.

I am genuinely asking and not trying to shoehorn it in as a peg. I just need to know because it’s relevant to the liquidity mining reward structure.

Makes sense @rabmarut.

The key distinction is that cDAI will always grow in value relative to DAI. There’s no such guarantee with xSNXa, which is valued by the net asset value of the SNX position, less the value of sUSD debt, plus the value of a dynamic hedge portfolio which may or may not outperform the debt. The fund may very well lag the performance of SNX. We’ll eventually have xSNXb which will have a different hedging strategy that performs differently.

While a lot of the value is derived from the performance of SNX, it’s not a direct claim on the underlying.

Fair enough. I’m happy to leave it alone for now and reassess any peg questions at a later date if need be. Perhaps if our community members are interested in evaluating the pegginess of SNX-xSNXa we could have you do an AMA to describe the product? I think it’s really neat, by the way. Nice work.

1 Like