Proposal to Update the Whitelist Process

Governance Liquidity Mining [deprecated]
1

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.

6 Likes
2

This will require a code change it seems like? I guess as of now no change since all whitelist remains at $10M cap, but as soon as new stuff is added a code change will be required. So we are voting for this with no PR and just wait for more tokens to get added then we can see the team’s code for the implementation?

3

I want to add my token to whitelist? what steps should i take?

4

The following is an amendment to the whitelist criteria described in the proposal above. After much discussion on Discord, it is clear that the token distribution requirement (Criterion #5) is still too subjective, not only as it pertains to decentralization but also to infinite mint capability. Notably, there is some confusion as to whether “infinite mint with caveats” - such as timelock and/or multisig - is acceptable. Ultimately, it has been decided that token distribution does not directly affect the BAL distribution, and was simply a good-faith but misguided effort to protect liquidity providers through gatekeeping. This runs contrary to the permissionless spirit of the Balancer protocol and more specifically the parent proposal of this comment.

It is clear that the cap tiers introduced by this proposal are sufficient to protect the liquidity mining program from anomalous forms of attack, and therefore it should be sufficient to reduce the whitelist criteria to a strictly technical list with no extra safety considerations. Liquidity providers will have to judge for themselves the subjective risk profile of their tokens, and Balancer will vouch only for a token’s fundamental smart contract compatibility with the protocol. The spirit of this update is that all technically compatible tokens will be given an equal opportunity with respect to liquidity mining, being whitelisted at cap1 as soon as possible and without friction. The BAL governors will then decide on extension of that opportunity to more advanced cap tiers, thus allowing the community to regulate the level of trust placed in each token without imposing a single gatekeeper on the system.

The following is the most up-to-date version of the whitelist compatibility criteria, which will be utilized from this moment (Round 11) forward. This list will necessarily evolve over time as further technical incompatibilities are discovered, but the permissionless spirit of the proposal will always be preserved in future updates. All such updates to the criteria will be specified as additional comments to this proposal.

  1. The token’s smart contract must be verified on etherscan. Neglecting this small degree of transparency adds unnecessary friction to the process of vetting for the remaining criteria.
  2. The token must conform to the ERC-20 interface described in EIP-20. Namely, the functions transfer(), transferFrom(), and approve() must return booleans.
  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.
  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.
  5. The token must not be vulnerable to the so-called "gulp() attack," which is exposed when a pool’s token balance changes unbeknownst to the pool. For now, known cases include tokens that charge a transfer fee (as described in #3) and tokens that periodically rebase. A rebasing token utilizing an atomic rebase+gulp should be safe from such attacks, but none has yet been discovered.
  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. Examples will be added as they are discovered; the only currently known example is VBZRX, whose claim() mechanism entitles token holders to receive BZRX airdrops on each token transfer. In isolation, this mechanism is perfectly safe, but if a token is airdropped to a Balancer pool whose asset list does not contain said token, then the airdropped tokens are forever locked in the pool contract and cannot be recovered by anyone (including Balancer Labs).
  7. The token must have a price feed accessible via CoinGecko’s API, e.g. this example link for WETH. 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.