Proposal to Update the Whitelist Process

This proposal is also on Balancer's forum.

TL;DR

Proposal to modify the token whitelist process from the status quo. The method described circumvents the need for any subjective decision-making at the time of whitelisting, instead favoring a set of purely technical criteria. To protect the liquidity mining program from bad actors, a series of cap tiers is added to the capFactor computation (see the original capFactor proposal for reference), with the default cap for new tokens being reduced to just $1M of adjusted liquidity.

Context

After seven weeks of whitelisting, we've begun to observe some serious contention within/regarding the existing token whitelist process. Namely, it is no longer acceptable for me (@rabmarut) to have subjective control over the list. There has been too much controversy recently about the interpretation of certain listing criteria, and no entity should have the power to make those interpretations.

The current criteria for whitelisting are described in the original whitelist proposal and copied below:

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.

It seems clear that Criterion #6 is far too subjective and therefore prone to the curator's interpretation.

The Proposal

Criterion #6 (above) will be removed from the existing list, and Criteria #1-5 will fully govern the whitelisting process. That is, there will be a minimal set of objective criteria for listing: a token must be technically compatible with Balancer, and its distribution must not raise any red flags as to the ability of a single party to game Balancer's liquidity mining program by manipulating either the token's price or supply. These criteria are fully focused on:

1. Protecting Balancer liquidity providers from loss of funds.
2. Protecting the BAL distribution from centralized actors.

The barrier to entry would be quite low for whitelisting tokens, but at any time, if a token is deemed to be either maliciously harming LPs or gaming the BAL distribution, it could be removed with a governance vote. Note that this approach passes no judgment on the intrinsic value of a token and leaves liquidity providers to decide for themselves what is and is not a "good investment" or a "legitimate project." Tokens would never be omitted or removed from the list on subjective merits; rather, one of two explicit removal criteria must be met:

1. There is significant evidence supporting the hypothesis that a fraudulent event took place in which token holders lost funds, i.e. an exit scam.
2. The token is being used as a BAL farm, thereby disadvantaging other Balancer liquidity providers. For example, perhaps 80% of the token's supply sits in a Balancer pool with a 0.0001% fee, and it draws either very little or mostly inorganic trade volume. Care must be taken not to over-emphasize volume here, but it may help to refine the list of potential manipulators. Another example of BAL farming could be that a single entity launches many different tokens to circumvent the $1M liquidity cap.

In calculating the week's BAL distribution, each token's total liquidity is adjusted by the feeFactor, ratioFactor, and wrapFactor; then the adjusted liquidity is capped at a predefined USD-denominated limit. This capFactor mechanism exists to ensure that no one token can reap a disproportionate share of the week's liquidity mining reward. To mitigate the potential consequences of the permissive listing scheme described above, I propose to make the default cap for each new token quite small. The capFactor system would be modified such that, instead of a single cap (now $10M) applied to all tokens, there would be several tiers of capping:

cap1:   $1M
cap2:   $3M
cap3:  $10M
cap4:  $30M
cap5: $100M

To ease the transition to this new scheme, the status quo of a $10M cap will be maintained for all existing whitelisted tokens - this puts existing tokens at cap3. All new tokens, upon being added to the whitelist, would instead be capped by default at cap1. At any time, community members may propose to vote a token into a different cap tier. Though not an explicit requirement, the spirit of these changes would be that of reactive necessity rather than preemptive ranking: if a token's TVL on Balancer nears or exceeds that token's cap, vote to raise the cap to the next tier. All such votes would be conducted with three options, for the sake of fairness of governance:

1. No change
2. Migrate the token up to the next (adjacent) cap tier
3. Migrate the token down to the previous (adjacent) cap tier

Furthermore, the cap tiers themselves can be adjusted in value (scaled up or down) by vote, as market conditions may result in more or less USD-denominated TVL across Balancer pools. These votes would be far less frequent and more flexible in structure.

Conclusion

Balancer's liquidity mining program was always designed to be permissive. The introduction of a token whitelist was nothing more than a necessary evil to inhibit known attacks on the BAL token distribution. My hope is that the new cap structure and token removal criteria will prove strong enough to mitigate such attacks moving forward, while still enabling Balancer's trustless and permissionless vision.