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:
https://forum.balancer.fi/t/proposing-the-token-whitelist-for-bal-distribution
https://forum.balancer.fi/t/bal-whitelist-round-2
https://forum.balancer.fi/t/bal-whitelist-round-3
https://forum.balancer.fi/t/bal-whitelist-round-4
https://forum.balancer.fi/t/bal-whitelist-round-5
https://forum.balancer.fi/t/bal-whitelist-round-6
https://forum.balancer.fi/t/bal-whitelist-round-7
https://forum.balancer.fi/t/bal-whitelist-round-8
https://forum.balancer.fi/t/proposal-to-update-the-whitelist-process
https://forum.balancer.fi/t/bal-whitelist-round-9
https://forum.balancer.fi/t/bal-whitelist-round-10
https://forum.balancer.fi/t/bal-whitelist-round-11
https://forum.balancer.fi/t/bal-whitelist-round-12
https://forum.balancer.fi/t/bal-whitelist-round-13
Proposed Modifications
The SAFE token is migrating to a new smart contract and renaming to SAFE2. I would like to propose modifying the existing whitelist entry for SAFE such that it points to the new contract:
MIGRATE SAFE2 0x250a3500f48666561386832f1F1f1019b89a2699
I would also like to propose adding the following new tokens to the whitelist:
ADD BART 0x54C9EA2E9C9E8eD865Db4A4ce6711C2a0d5063Ba
ADD DEXG 0xB81D70802a816B5DacBA06D708B5acF19DcD436D
ADD DOUGH 0xad32A8e6220741182940c5aBF610bDE99E737b2D
ADD DUST 0xbCa3C97837A39099eC3082DF97e28CE91BE14472
ADD GUSD 0x056Fd409E1d7A124BD7017459dFEa2F387b6d5Cd
ADD pxUSD-OCT2020 0xDaFF85B6f5787b2d9eE11CCDf5e852816063326A
ADD SFG 0x8a6ACA71A218301c7081d4e96D64292D3B275ce0
ADD TBTC 0x8dAEBADE922dF735c38C80C7eBD708Af50815fAa
ADD TEL 0x467Bccd9d29f223BcE8043b84E8C8B282827790F
ADD uUSDrBTC-DEC 0xF06DdacF71e2992E2122A1a0168C6967aFdf63ce
ADD uUSDwETH-DEC 0xD16c79c8A39D44B2F3eB45D2019cd6A42B03E2A9
ADD WHALE 0x9355372396e3F6daF13359B7b607a3374cc638e0
Finally, I would like to propose removing a token. This is rather unconventional for these whitelist proposals, but I believe it is necessary in this case. First of all, I’d like to clarify that there are currently no Balancer pools containing this token, so this decision does not affect any existing liquidity providers.
Token research conducted this week revealed that there are certain types of Synthetix synths which are “purgeable” - meaning that, by design, there are conditions under which the full supply of a synth will be forcefully exchanged into sUSD. This behavior is common to all inverse synths (see iETH below) and some others; in isolation it is perfectly safe, and it is completely necessary in order to migrate the inverse synth price model to a new equilibrium after a large price movement of the underlying token. However, when this forced exchange happens, any such synths stored within Balancer pools will disappear and a subsequent gulp() will destroy the price curve within the pool. Furthermore, if the pool is finalized and does not contain sUSD as one of its assets, then the incoming sUSD are locked and irrecoverable. This is a highly dangerous token-loss situation which precludes whitelisting, so this token should be immediately removed given this discovery.
REMOVE sDEFI 0xe1aFe1Fd76Fd88f78cBf599ea1846231B8bA3B6B
The proposed changes will go into effect at 00:00 UTC on Monday, September 28. 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.
SOFT GUSD USD group
SOFT pxUSD-OCT2020 USD group
SOFT TBTC BTC group
SOFT uUSDrBTC-DEC USD group
SOFT uUSDwETH-DEC USD group
Omissions
The following token breaks expected ERC-20 transfer() behavior in a few ways; most notably there is an optional token-for-gas mechanism which would cause all transfers out of a Balancer pool to signal failure, thereby locking funds. This unconventional behavior 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.
BAD TRANSFER FUNC DCN 0x08d32b0da63e2C3bcF8019c9c5d849d7a9d791e6
The following token possesses the purge mechanism described above (see sDEFI removal), which violates Whitelist Criterion #6: The token must not possess any mechanisms which, when combined with a Balancer pool, result in material losses to the principal value of the pooled token. This criterion covers all value-loss edge cases which may be difficult to anticipate but can still preclude a token’s whitelisting.
TOKEN LOSS/LOCK iETH 0xA9859874e1743A32409f75bB11549892138BBA1E
The following tokens lack price feeds 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 KIWI 0x2BF91c18Cd4AE9C2f2858ef9FE518180F7B5096D
NO PRICE FEED YAX 0xb1dC9124c395c1e97773ab855d66E879f053A289