Building Liquidity into Token Distribution

This is a continuation of a series of articles on Balancer where we highlight the flexibility of the protocol, specifically the concept of smart pools. Smart pools are controlled / private pools that are owned by a smart contract which enables any sort of arbitrary logic to be built. Balancer Labs plans to design several templates for smart pools which allows teams to modify, deploy, and manage pools in an extremely friendly interface. This article will focus on Liquidity Bootstrapping Pools (LBPs) — a smart pool template that allows teams to release a project token while at the same time building deep liquidity.

Background

Before AMMs became mainstream, projects had very limited options to get liquidity for their token. Exchange listing fees can be upwards of $250,000 and paying market makers can be even more expensive.

Over the last several months there has been lots of experimentation around creating liquidity for new tokens using AMM style curves. Synthetix has subsidized liquidity on Uniswap. Saint Fame has added a small amount ETH to bootstrap liquidity. We expect to see the trend continue of long tail tokens building liquidity on AMMs.

It is helpful to walk through an example scenario of how teams can currently build liquidity.

Example Scenario:

A team has created token XYZ that they believe has a starting fair market value of $1 and the price of ETH is $250.

Below is a table of costs and slippage for entering a constant-product 50/50 AMM.

As you can see, the upfront capital requirements for a team become very expensive in terms of ETH liquidity needed to prevent slippage.

Liquidity Bootstrapping Pools

LBPs were conceived with the following key considerations:

1. A team should be able to build liquidity without large amounts of upfront capital
2. A team should be able to create a treasury to fit their desired risk profile and funding goals
3. Distribution of tokens and liquidity provision should be decoupled from token price changes. In other words, differently from bonding curves, tokens should be distributed even if their unit price stays constant.

With those points in mind we have developed a flexible template that allows teams to define how liquidity is bootstrapped as part of their token distribution.

In the linear example above a team sets its project token to start at 80% weight and DAI to start at 20% weight (ETH can be substituted instead of DAI). Over the span of 6 months the weights are slowly adjusted and ultimately flip. The linear formula is explicitly described in the controller contract and allows anyone to “poke” the contract to update weights. The small arbitrage opportunities that occur upon each weight change also brings in additional traders. Below is the pokeWeights function in the code that allows anyone to call and perform a range transformation from the block number to the scaled weight.

function pokeWeights() {
    uint oldRange = bsub(_endBlock, _startBlock);
    uint newRange = bsub(_startWeights[i], _endWeights[i]);
    uint newWeight = badd(bmul(bdiv(bsub(block.number, _startBlock), oldRange), newRange), newMin);
   _bPool.rebind(_tokens[i], _bPool.getBalance(_tokens[i]), newWeight);
}

Going back to the table for costs and slippage, in the LBP example above we now have the following data points:

With the same amount of ETH, a team can now introduce up 4x the amount of their project tokens in liquidity and distribution. Note: this assumes 80 / 20 weights — more extreme 95/5 weights would require even less initial ETH

An LBP allows projects to create meaningful liquidity and distribution at launch

At the end of the weight adjustment period the pool will continue being traded in perpetuity. And comparatively, the project team is not left holding onto 50% (in value) of the project token.

Another possibility is for projects to define an exponential curve to adjust the weights on. The slope of the curve is a configurable parameter in the smart contract template.

One of the major advantages of using an exponential curve is to counteract the initial hype and excitement around a token release. By quickly adjusting weights down, and therefore dropping the value of the token in the pool, it discourages an eventual price spike due to early speculation.

The two examples shown in this article use a project token and Dai. However the smart pool template allows for vectors of tokens and weights. So one option would be to start 80% XYZ, 10% DAI, 10% ETH and end at 33% XYZ, 33% DAI, 33% ETH. Allowing for users to purchase the project token in ETH or DAI.

Conclusion

LBP templates allow a fully customizable token distribution mechanic that gives teams more control and flexibility. As the long tail of tokens continues to explode in the crypto space, more experimentation is necessary around liquidity bootstrapping. We see LBPs as an important building block in that process.

Balancer Labs also plans to create frontend dApps specifically for LBPs that allow a team to create, design, and distribute a token in a few clicks.

For any teams who are interested in learning more about the smart pool template, or in how to create their own Balancer pools, contact us or join our Discord.

Thanks to Alex Evans and Chris Burniske whose discussions inspired ideas in this article.

Look out for more articles in this series where we will cover: dynamic fees on asset volatility, synthetic perpetuals on rolling expiry tokens, and more.