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.
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 FET 0x1D287CC25dAD7cCaF76a26bc660c5F7C8E2a05BD -> 0xaea46A60368A7bD060eec7DF8CBa43b7EF41Ad85
I would also like to propose adding the following new tokens to the whitelist:
ADD cUNI 0x35A18000230DA775CAc24873d00Ff85BccdeD550 ADD DGD 0xE0B7927c4aF23765Cb51314A0E0521A9645F0E2A ADD INDEX 0x0954906da0Bf32d5479e25f46056d22f08464cab ADD OPT 0x4FE5851C9af07df9e5AD8217aFAE1ea72737Ebda ADD RLY 0xf1f955016EcbCd7321c7266BccFB96c68ea5E49b ADD XFT 0xABe580E7ee158dA464b51ee1a83Ac0289622e6be ADD ZEFU 0xB1e9157c2Fdcc5a856C8DA8b2d89b6C32b3c1229
The proposed changes will go into effect at 00:00 UTC on Monday, October 19. 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.
HARD cUNI <-> UNI HARD DGD <-> ETH
The following token is not verified on Etherscan, which violates Whitelist Criterion #1: The token’s smart contract must be verified on Etherscan. Neglecting this small degree of transparency adds unnecessary friction to the process of vetting for the remaining criteria.
UNVERIFIED `c 0xe324C8cF74899461Ef7aD2c3EB952DA7819aabc5
The following token lacks a price feed through the CoinGecko API, which violates Whitelist Criterion #7: The token must have a price feed accessible via CoinGecko’s API. This is instrumental to calculating a pool’s eligibility for BAL rewards. If a token meets all of the remaining criteria but not this criterion, it can be added to the UI whitelist and reconsidered for the mining whitelist once the price feed becomes available.
NO PRICE FEED LEX 0xA5C5C8Af327248c4c2dce810a3d3Cffb8C4F66ab
Reference: Prior Proposals