Should all tokens be allowed for liquidity mining?

Here is some points i want to raise about the distribution:

  • 1: There is some tokens with fantasy (or at least questionable) valuation, for example:
    HEX ~$660m (also listed on Coingecko)
    If someone add 5% of the HEX supply into a Balancer pool he will have ~$30m liquidity counted for BAL rewards it will be more than half of the expected total BAL being rewarded based on the current liquidity in Balancer pools. This is hypothetical, there isn’t any pool with HEX atm but the problem could happen later or with another token.

  • 2: I’ve seen that BTC++ is used on some Balancer pools, because BTC++ is a BPT token and it’s listed on Coingecko (like BTC++), LP can get rewards in BAL twice for the same liquidity provided, first with holding BTC++ and secondly with having BTC++ in a Balancer pool.

A simple solution would be to have a whitelist of tokens that are accepted for BAL distribution. I’m interested to know what do you think about these concerns and what solution you see?


IMO some type of whitelist is inevitable. One of the main reasons why we didn’t start with one is we didn’t want for Balancer Labs to have too much influence early on in the process before governance started to take shape. And luckily so - if I was asked to make a whitelist a few weeks ago I wouldn’t have had RPL on that list. And the 90/10 RPL pool has actually added a ton of value ($220k 24h trading volume) and demonstrated the flexibility of Balancer for other projects looking to add liquidity to their token with limited upfront capital.

Blacklists end up being too much of a cat and mouse game, where a new scam token could pop up every other week on Coingecko and it would be exhausting always having to wait until the following week to add.

This raises lots of new questions to explore:

  1. What metrics are useful in deciding if a token should be whitelisted? Should they be subjective or objective? Example: I think BAL is a great incentive mechanism for newer projects to introduce a very illiquid coin to the DEX ecosystem. But if it’s objective measure of a token needs at least $x trading volume on dexes, we lose out on that. How do we balance including illiquid but legitimate projects and plain bad projects?

  2. What if a token is legit and well known, but the team owns >95% of the supply. With a limited float, prices may be inflated and a team could add a massive dollar amount.

  3. How does voting work for tokens looking to be added? What minimum thresholds are necessary to prevent hostile additions? Can tokens be removed after already being added to the whitelist?


I think blacklisting will be too complicated, too many tokens, what would be the restrictions…

For me the only way to avoid to centralisation of BAL is:

  1. Participation in at least 3 pools
  2. Those 3 pools have at least 3 different tokens
  3. Taking the added liquidity $ average of the participant as benchmark for BAL distribution

The formula could be adapted to take into account single pool provider as well with less weight.
Otherwise the first movers advantage of big single token liquidity providers will force BAL to be centralised

1 Like

@mike: I can’t think of any objective measurement that can’t be faked - e.g. it’s very easy to fake volume on a DEX. So I trust the balancer team and their judgement regarding the whitelisting of coins :slight_smile:

@Tommeylu: I don’t agree. In my opinion, the idea of balancer is not to have as many tokens in a pool as possible and participate in a lot of pools. The new ratio factor already massively reduces the impact of single token liquidity providers (assuming they put a high weight on the token…). E.g. the RPL pool is now reduced to ~5m liquidity that’s eligible for BAL. Also, sending ~14m to a smartcontract of a new project is quite a risk and therefore it’s fair to reward it accordingly.


My personal opinion is that some sort of whitelist is overall reasonable.

The way will be implemented however can be a slippery slope, metrics for these decisions are extremely subjective. I think @mike explained the challenges well.

I think a positive outcome would ensure the following things:

  1. Create policies where Liquidity Bootstrapping Pools are not penalized.

  2. Create policies where projects building on top of Balancer are not penalized.

  3. Create policies for decision making and voting which are inclusive to the community and BAL holders.

More on Point 1)

This one feels the most difficult to tackle imo, assessing the legitimacy of a specific token is extremely subjective and it’s not in the scope of a protocol to do so. Protocols are usually better off when they are agnostic for the most part in the way they are used.

One question that may be worth asking is: Are BAL rewards a protocol incentive or a Balancer Labs incentive?

More on Point 2)

It would make sense to create conditions for projects actively building on Balancer to not be penalized.

Since @fabien mentioned BTC++, I’d like to expand on that.
I think the goal here is to exclude bad actors gaming the system, which is not the case for PieDAO products.

BTC++ and USD++ are in fact products on their own different from other BPT pools, which is part of the reason why they are listed on Coingecko, Defimarketcap, etc.

At PieDAO we feel smart pools are a real game-changer and have been the first project building on top of it, spending time educating users and developing before Balancer Protocol arrived to mainnet.

For instance, we are actively working on flash loans, circuit breakers, dynamic fee pools, dynamic weights and other stuff that are likely to become a strong differentiation point in the industry. They also provide an alternative implementation of smart pools (something of value for a decentralized protocol).

BTC++ and USD++ by being the TOP2 largest private pools, provide a relevant venue for liquidity designed with multihop in mind and a great fit for specific risk profiles.

Instead of focusing on providing liquidity on other AMMs like Uniswap, Balancer has been chosen as the main platform to provide access to such products and to foster the platform success, not a way to game the system.

I think BTC++ and USD++ bring value to the Balancer community and ecosystem.

Some level of inception is, for now, inevitable because of the 8 tokens limit.

The next product being developed, for instance, called DEFI++, will likely be constituted by a DEFI Small Cap Pie and a DEFI Large Cap Pie.

Those tokens (DeFiSC, DeFiLC and DeFi++) are 3 completely different products designed for different risk profiles, different upside opportunities, and different people.

Maybe a solution lies in limiting the level of nesting, something like >3 not allowed.
We are debating the subject and working on a policy right now.

More on Point 3)

Moving forward, I’d hope to see more clarity on how the decision-making process for BAL holders looks like. Ideally taking into consideration the fact that this a worldwide community and minimum time are important for timezones.

The way I think about good practice in governance leans towards stimulating participation with a combination of reducing friction from token holders, ensuring the distribution of information about governance proposals to the involved token holder, and inclusivity.

Keep up the good work guys!