Proposal to Update the Whitelist Process

Governance Liquidity Mining [deprecated]
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.