Proposing the Token Whitelist for BAL Distribution

On behalf of the Balancer community, I would like to propose to implement a whitelist of tokens which qualify for BAL distribution. The goal is to reduce the likelihood that the distribution mechanism can be attacked or gamed while continuing the equitable distribution of BAL governance tokens to as many well-intentioned liquidity providers as possible. We believe that incentive alignment only works if good actors are properly rewarded and bad actors excluded.

On Wednesday, June 24, a pool was created using illegitimate assets valued close to $100M USD in total. This pool would have single-handedly collected more than half of the weekly BAL reward while providing very little utility to the protocol. The community took swift action to prevent future incidents without retroactively punishing the pool creator, who played by the (imperfect) rules that were well established at that time. It was proposed that, beginning at Ethereum block #10331138, the BAL distribution would change from an oracle-based (CoinGecko) qualification to a whitelist-based qualification. The initial whitelist has been formulated from a long list of assets in active Balancer pools and pruned using community discussion and rough consensus.

The list proposed here is not exhaustive; assets can be added and removed going forward, provided community consensus, and without applying any retroactive action. For the sake of expediency, any assets appearing contentious during community discussions have been temporarily excluded from the list, but these may yet be added after further discussion. A few basic rules governed the selection of tokens during this round and will most likely apply to all future additions as well:

  1. Token must return boolean success on transfer. If an ERC-20 does not return a bool when transfer() is called, it is broken within Balancer v1. Funds added to Balancer liquidity pools will be irrecoverable, and there is nothing the team can do to intervene; Balancer v1 is a set of immutable smart contracts with no administrative keys.
  2. Token must not charge fees on transfer. While not necessarily intended as an attack vector, transfer fees are dangerous for Balancer pools. Every trade or removal of liquidity from pools containing these assets will result in a pool price which is “out of sync” with the true balances. Arbitrageurs can gulp() the pool and then trade with it at liquidity providers’ expense. Among others, all “deflationary” assets fall into this category.
  3. Token contract must be verified on etherscan. This metric favors tokens which value transparency and reliability.
  4. Token must be listed and have a live USD price feed on CoinGecko. This is the price oracle used for distributing BAL proportional to shares of overall liquidity.
  5. Token distribution must be somewhat equitable. This is a highly subjective metric subject to community consensus, but in general the desire is for tokens to be somewhat evenly distributed. If the founders, for example, hold 90% of the supply, there are probably ways in which they can hurt liquidity providers or extract disproportionate BAL rewards by artificially driving up the token’s price.
  6. Token must provide some form of “real” value. This is another highly subjective metric, but the idea is for the community to actively filter out tokens which have been promoted as “pump-and-dump” schemes, which could hurt unknowing liquidity providers.

The rule set above should be considered rather immutable and apply to all whitelisting decisions moving forward. But during the formulation of this initial whitelist, due to time constraints, a few other factors were also given priority:

  1. Token is currently utilized in a Balancer pool.
  2. Token supply/distribution mechanisms are trivial to understand.
  3. Token discussion is rather one-sided, i.e. it is non-contentious or a “no brainer.”

As such, there were a few potentially legitimate token archetypes which were not given serious consideration over the last few days. Creators and holders should understand that further community discussion will follow, and many of these tokens may be listed in the coming weeks. This is designed to be a somewhat flexible process in the beginning before true decentralized governance is fleshed out, and we as a team and community will do our best to be fair and adaptive in the weeks and months ahead.

With all of the above being considered, we propose to include the following tokens in the initial whitelist:

aBUSD:			0x6Ee0f7BB50a54AB5253dA0667B0Dc2ee526C30a8
aDAI:			0xfC1E690f61EFd961294b3e1Ce3313fBD8aa4f85d
AGI:			0x8eB24319393716668D768dCEC29356ae9CfFe285
AMPL:			0xD46bA6D942050d489DBd938a2C909A5d5039A161
ANJ:			0xcD62b1C403fa761BAadFC74C525ce2B51780b184
ANT:			0x960b236A07cf122663c4303350609A66A7B288C0
AST:			0x27054b13b1B798B345b591a4d22e6562d47eA75a
aSUSD:			0x625aE63000f46200499120B906716420bd059240
aTUSD:			0x4DA9b813057D04BAef4e5800E36083717b4a0341
AUC:			0xc12d099be31567add4e4e4d0D45691C3F58f5663
aUSDC:			0x9bA00D6856a4eDF4665BcA2C2309936572473B7E
aUSDT:			0x71fc860F7D3A592A4a98740e39dB31d25db65ae8
BAL:			0xba100000625a3754423978a60c9317c58a424e3d
BAT:			0x0D8775F648430679A709E98d2b0Cb6250d2887EF
BCDT:			0xAcfa209Fb73bF3Dd5bBfb1101B9Bc999C49062a5
BLT:			0x107c4504cd79C5d2696Ea0030a8dD4e92601B82e
BLZ:			0x5732046A883704404F284Ce41FfADd5b007FD668
BNT:			0x1F573D6Fb3F13d689FF844B4cE37794d79a7FF1C
BTC++:			0x0327112423F3A68efdF1fcF402F6c5CB9f7C33fd
BUIDL:			0xD6F0Bb2A45110f819e908a915237D652Ac7c5AA8
cBAT:			0x6C8c6b02E7b2BE14d4fA6022Dfd6d75921D90E4E
cDAI:			0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643
CEL:			0xaaAEBE6Fe48E54f431b0C390CfaF0b017d09D42d
cETH:			0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5
CHAI:			0x06AF07097C9Eeb7fD685c692751D5C66dB49c215
CHZ:			0x3506424F91fD33084466F402d5D97f05F8e3b4AF
COMP:			0xc00e94Cb662C3520282E6f5717214004A7f26888
cREP:			0x158079ee67fce2f58472a96584a73c7ab9ac95c1
cUSDC:			0x39AA39c021dfbaE8faC545936693aC917d5E7563
cUSDT:			0xf650C3d88D12dB855b8bf7D11Be6C55A4e07dCC9
CVC:			0x41e5560054824eA6B0732E656E3Ad64E20e94E45
cZRX:			0xB3319f5D18Bc0D84dD1b4825Dcde5d5f7266d407
DAI:			0x6B175474E89094C44Da98b954EedeAC495271d0F
DATA:			0x0Cf0Ee63788A0849fE5297F3407f701E122cC023
DGX:			0x4f3AfEC4E5a3F2A6a1A411DEF7D7dFe50eE057bF
DIP:			0xc719d010B63E5bbF2C0551872CD5316ED26AcD83
DMG:			0xEd91879919B71bB6905f23af0A68d231EcF87b14
DNT:			0x0AbdAce70D3790235af448C88547603b945604ea
DXD:			0xa1d65E8fB6e87b60FECCBc582F7f97804B725521
DZAR:			0x9Cb2f26A23b8d89973F08c957C4d7cdf75CD341c
EDO:			0xCeD4E93198734dDaFf8492d525Bd258D49eb388E
ENJ:			0xF629cBd94d3791C9250152BD8dfBDF380E2a3B9c
ETHBTCRSI7030:	0xbf70A33A13fBe8D0106Df321Da0Cf654d2E9Ab50
ETHMNY:			0xbF4a2DdaA16148a9D0fA2093FfAC450ADb7cd4aa
ETHRSIAPY:		0x136faE4333EA36A24bb751E2d505D6ca4Fd9f00b
ETHRSIAPY2:		0x9f49ed43C90A540d1cF12f6170aCE8d0B88a14E6
FOAM:			0x4946Fcea7C692606e8908002e55A582af44AC121
FUN:			0x419D0d8BdD9aF5e606Ae2232ed285Aff190E711b
GEN:			0x543Ff227F64Aa17eA132Bf9886cAb5DB55DCAddf
GHOST:			0x4c327471C44B2dacD6E90525f9D629bd2e4f662C
GNO:			0x6810e776880C02933D47DB1b9fc05908e5386b96
GRID:			0x12B19D3e2ccc14Da04FAe33e63652ce469b3F2FD
HOT:			0x6c6EE5e31d828De241282B9606C8e98Ea48526E2
IDEX:			0xB705268213D593B8FD88d3FDEFF93AFF5CbDcfAE
imBTC:			0x3212b29E33587A00FB1C83346f5dBFA69A458923
JRT:			0x8A9C67fee641579dEbA04928c4BC45F66e26343A
KNC:			0xdd974D5C2e2928deA5F71b9825b8b646686BD200
LEND:			0x80fB784B7eD66730e8b1DBd9820aFD29931aab03
LEV:			0x0F4CA92660Efad97a9a70CB0fe969c755439772C
LINK:			0x514910771AF9Ca656af840dff83E8264EcF986CA
LPT:			0x58b6A8A3302369DAEc383334672404Ee733aB239
LRC:			0xBBbbCA6A901c926F240b89EacB641d8Aec7AEafD
MANA:			0x0F5D2fB29fb7d3CFeE444a200298f468908cC942
MATIC:			0x7D1AfA7B718fb893dB30A3aBc0Cfc608AaCfeBB0
MCX:			0xd15eCDCF5Ea68e3995b2D0527A0aE0a3258302F8
MKR:			0x9f8F72aA9304c8B593d555F12eF6589cC3A579A2
MLN:			0xec67005c4E498Ec7f55E092bd1d35cbC47C91892
mUSD:			0xe2f2a5C287993345a840Db3B0845fbC70f5935a5
NEST:			0x04abEdA201850aC0124161F037Efd70c74ddC74C
NMR:			0x1776e1F26f98b1A5dF9cD347953a26dd3Cb46671
OCEAN:			0x985dd3D42De1e256d09e1c10F112bCCB8015AD41
OWL:			0x1A5F9352Af8aF974bFC03399e3767DF6370d82e4
PAX:			0x8E870D67F660D95d5be530380D0eC0bd388289E1
pBTC:			0x5228a22e72ccC52d415EcFd199F99D0665E7733b
PNK:			0x93ED3FBe21207Ec2E8f2d3c3de6e058Cb73Bc04d
POWR:			0x595832F8FC6BF59c85C527fEC3740A1b7a361269
PRO:			0x9041Fe5B3FDEA0f5e4afDC17e75180738D877A01
QNT:			0x4a220E6096B25EADb88358cb44068A3248254675
REN:			0x408e41876cCCDC0F92210600ef50372656052a38
renBTC:			0xEB4C2781e4ebA804CE9a9803C67d0893436bB27D
REP:			0x1985365e9f78359a9B6AD760e32412f4a445E862
REQ:			0x8f8221aFbB33998d8584A2B05749bA73c37a938a
RLC:			0x607F4C5BB672230e8672085532f7e901544a7375
RPL:			0xB4EFd85c19999D84251304bDA99E90B92300Bd93
RSR:			0x8762db106B2c2A0bccB3A80d1Ed41273552616E8
sBTC:			0xfE18be6b3Bd88A2D2A7f928d00292E7a9963CfC6
sETH:			0x5e74C9036fb86BD7eCdcb084a0673EFc32eA31cb
SHIP:			0xe25b0BBA01Dc5630312B6A21927E578061A13f55
SNT:			0x744d70FDBE2Ba4CF95131626614a1763DF805B9E
SNX:			0xC011a73ee8576Fb46F5E1c5751cA3B9Fe0af2a6F
STAKE:			0x0Ae055097C6d159879521C384F1D2123D1f195e6
STORJ:			0xB64ef51C888972c908CFacf59B47C1AfBC0Ab8aC
sUSD:			0x57Ab1ec28D129707052df4dF418D58a2D46d5f51
TFD:			0xE5F166c0D8872B68790061317BB6CcA04582C912
TRAC:			0xaA7a9CA87d3694B5755f213B5D04094b8d0F0A6F
TRB:			0x0Ba45A8b5d5575935B8158a88C631E9F9C95a2e5
TUSD:			0x0000000000085d4780B73119b644AE5ecd22b376
UBT:			0x8400D94A5cb0fa0D041a3788e395285d61c9ee5e
UMA:			0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828
USD++:			0x9A48BD0EC040ea4f1D3147C025cd4076A2e71e3e
USDC:			0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
VETH:			0x31Bb711de2e457066c6281f231fb473FC5c2afd3
WBTC:			0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599
WETH:			0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
ZRX:			0xE41d2489571d322189246DaFA5ebDe1F4699F498
10 Likes

please to consider RNDR sirs. 0x6de037ef9ad2725eb40118bb1702ebb27e4aeb24

Very good token and team. Already vetted by coinbase

1 Like

HY,

I’m the lead marketing of a crypto project and I would like to know where and how we can be added to the list of trusted tokens. Hopefully i’m at the right spot. Cause i couldn’t find some other treads about it but i’m new here so maybe i have looked over it.

In forward thanks!

Please find us on Discord. We have a #token-requests channel for this. If you can’t/don’t want to find the Discord server, just post an etherscan link to your token here.

Hello @Fernando and @rabmarut I just spoke to HAKKA Finance out of Taiwan.
They, unlike many other new DEFI have their products developed fully and applying for whitelisting.
They also run a pool already on Balancer… and would like to further support with their large community out of Taiwan.
Please take a look https://hakka.finance/#product

HAKKA: 0x0e29e5abbb5fd88e28b2d355774e73bd47de3bcd

HAKKA was reviewed for the whitelist and omitted due to 80% of the token supply being in a Gnosis safe. If the team could provide further information on the purpose of this safe and who owns the keys, I’d be happy to reconsider. Token distribution is a somewhat important factor in whitelisting because large holders can potentially manipulate token price or set up a BAL farm by pooling their huge supply of tokens.

Thanks @rabmarut this should help clarify

Not sure if this is where I was supposed to ask for consideration of a token, or if it was fine where it is. Excuse the double post, but wanted to make sure I followed instructions.

Please consider Empty Set Dollar. Elastic supply stable coin. Contract below:

Elastic supply tokens are actually not safe for Balancer pools. Rebasing mechanisms open vectors of flash loan attack. This is mentioned in the listing requirements (Criterion 5). I will examine the specific mechanism employed by ESD to see if it’s safe, but if it’s similar to AMPL or YAM then unfortunately it will be denied.