eligible.json
: assets eligible for BAL mining as per weekly proposalslisted.json
: assets listed on balancer.exchangeui-not-eligible.json
: assets vetted by community membersuntrusted.json
: assets that are incompatible with Balancertransfer()
, transferFrom()
, and approve()
must return booleans.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.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.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. (Added note: Ampleforth released a pool with this behavior, though it was implemented through a Balancer Pool subclass, not the token contract.)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).