BAL Whitelist - Round 14

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.finance/t/proposing-the-token-whitelist-for-bal-distribution
https://forum.balancer.finance/t/bal-whitelist-round-2
https://forum.balancer.finance/t/bal-whitelist-round-3
https://forum.balancer.finance/t/bal-whitelist-round-4
https://forum.balancer.finance/t/bal-whitelist-round-5
https://forum.balancer.finance/t/bal-whitelist-round-6
https://forum.balancer.finance/t/bal-whitelist-round-7
https://forum.balancer.finance/t/bal-whitelist-round-8
https://forum.balancer.finance/t/proposal-to-update-the-whitelist-process
https://forum.balancer.finance/t/bal-whitelist-round-9
https://forum.balancer.finance/t/bal-whitelist-round-10
https://forum.balancer.finance/t/bal-whitelist-round-11
https://forum.balancer.finance/t/bal-whitelist-round-12
https://forum.balancer.finance/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
2 Likes

This is great @rabmarut, thanks for your awesome and diligent work!

Could I suggest an add for:

mbBASED 0x26cF82e4aE43D31eA51e72B663d26e26a75AF729

It’s the new wrapper for BASED which is not subject to rebase and therefore can safely be added to Balancer now because we don’t have to worry about sync().

1 Like

I’ll take a look at the contract and consider for the next proposal. Thanks for all you do, Eric!

1 Like