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.
I would like to propose adding the following new tokens to the whitelist:
ADD HEZ 0xEEF9f339514298C6A857EfCfC1A762aF84438dEE ADD UFT 0x0202Be363B8a4820f3F4DE7FaF5224fF05943AB1
The proposed changes will go into effect at 00:00 UTC on Monday, October 26. 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 price pegs introduced this week.
Some requested tokens were omitted this week.
The following token has logic in place for a transfer fee, which can be enabled at any time by the contract owner. This violates Whitelist Criterion #3: The token’s transfer() and transferFrom() implementations must exhibit the expected behavior - namely, transferring N tokens from one address to another. Certain divergences from this behavior, such as transfer fees, can cause issues with Balancer pools, and these tokens will be rejected.
TRANSFER FEE XAUt 0x4922a015c4407F87432B179bb209e125432E4a2A
The following token prohibits zero-approval, which will cause issues with the Balancer Exchange Proxy. This violates Whitelist Criterion #4: The token’s approve() implementation must exhibit the expected behavior - namely, it must allow for infinite approval, or the token cannot be sold using the Balancer exchange proxy.
BAD APPROVE HBTC 0x0316EB71485b0Ab14103307bf65a021042c6d380
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.
NO PRICE FEED UPXAU 0x0557Df767419296474C3f551Bb0A0ED4c2DD3380
Reference: Prior Proposals