How to Make Bonding Curves for Continuous Token Models
This is a technical primer on how to make your own bonding curves, followed by a discussion about the opportunities and risks involved. If you’re not interested in the tech, skip to the end for some general insights. If you just want some code samples in solidity, the reference github repo is here:
What are Bonding Curves?
There has recently been a lot of renewed excitement about ideas behind curation markets, a term coined by Simon de la Rouviere:
The core, functional components of curation markets involve:
A token that can be minted at any time (continuous) according to a price set by the smart contract.
This price gets more expensive as more tokens are in circulation.
The amount paid for the token is kept in a communal deposit.
At any point in time, a token can be withdrawn (“burned”) from the active supply, and a proportional part of the communal deposit can be taken with.
The tokens are used to bond it to curators per sub-topic, who then curate information with their proportional backing.
In curation markets, tokens are bought and sold according to a “bonding curve” — an equation that defines the token price as a function of token supply.
Here is an example of a quadratic bonding curve:
currentPrice = tokenSupply²
When a user wants to buy 10 tokens, the contract mints 10 new tokens, computes their price and sends those tokens to the user in exchange for Ether (or another reserve token).
But computing how much we should charge for the 10 new tokens isn’t trivial. One might think it should be 10 * currentPrice, but that’s not correct because creating each new token increases the price, so the user must pay a little more than the currentPrice for each subsequent token.
A naive approach might be to iterate over the new tokens and update the price at each iteration. However this is very inefficient and also inaccurate, because even the smallest change in token supply (like .1 tokens) will move the price.
What we want to do is compute the sum of all the infinitely small changes in price. This is the same as computing the area under the bonding curve — we can easily do this using integrals.
For example, to compute the total Ether (poolBalance) held by our quadratic bonding curve contract we compute the integral of the price function:
poolBalance = 1/3 * tokenSupply³
This is the same as the area under our curve between 0 and tokenSupply:
From this we can derive how much we should charge for 10 new tokens:
priceForTokens = 1/3* (tokenSupply + 10)³ — poolBalance
Using this method we can compute formulas for bonding curves based on any power function y=x^p. The sample code includes cases for y=m * x², y=m * x and y = m * sqrt(x)
Bancor Formula
However we can do better. Remember Bancor? The ICO that raised $153M last summer with 40 lines of code? Well, that code is for computing a general type of bonding curve.
A nice property of power functions is that we can define our bonding curve in terms of a reserve ratio. Reserve ratio is defined by the relationship between token price, token supply and poolBalance.
reserveRatio = poolBalance / (currentPrice * tokenSupply)
In our y=x² function, poolBalance = 1/3 * tokenSupply³, so we can rewrite the reserve ratio formula:
reserveRatio = 1/3 * tokenSupply³ / (tokenSupply² * tokenSupply) = 1 / 3
So we can express our quadratic curve as a token with reserve ratio of 1/3. Similarly, y=x is a curve with a reserveRatio of ½ and y=sqrt(x) is a curve with a reserveRatio of ⅔.
Bancor’s formula allows us to compute token prices for arbitrary curves with reserve ratios between 0 -100%, (you can read more details about in their white paper). In fact their own BNT token can be bought and sold via a smart contract with a 1/10 reserve ratio.
Here is their solidity implementation with some fancy tricks to compute fractional exponents of fractions:
Here is an implementation of a simple universal bonding curve I put together using the Bancor formula:
The gas prices to buy and sell the token are slightly higher than the specific cases, but still very reasonable.
Implications
Bonding Curves allow us to create some cool token models.
Liquidity
The obvious advantage is instant liquidity — you can create a contract and have anyone be able to buy and sell your token right away.
Bid-Ask Spreads & Dynamic Inflation Rate
Since the contract functions as a market maker, you can define your own bid-ask spread and charge a small premium when users buy or sell tokens and generate income from providing liquidity. This is also a way to mitigate pump-n-dump attacks while the token is its nascency — attack will be less profitable if we use a sell curve with a lower reserve ratio.
What is even more interesting, is that you can define separate (even dynamically computed) buy and sell curves. Again, these function as dynamic bid-ask spreads and allow you to allocate the proceeds however you like.
At Relevant we plan on using a bid-ask spread in order to create an inflationary token with a dynamically calculated inflation rate. The newly minted tokens will be used to reward users for curating quality news feeds.
Example of a token with a dynamic inflation rate:
Initialization:
- maxInflationRate = 10%
- startRatio = 20%
- minReserveRatio = 10%
As above, our reserve ratio is:
reserveRatio = poolBalance / (totalSupply * tokenPrice)
but it is now dynamic since the total supply increases with inflation.
Our ‘buy’ curve is based on a 20% startRatio and our ‘sell’ curve is dynamically calculated from the actual reserve ratio but is not allowed to fall below 10%.
We start with both curves based on a 20% reserve ratio, but as time passes, we mint new tokens based on inflation rate. As a result, our supply increases but poolBalance stays the same. This starts pushing the sell curve closer to the 10% ratio. As this happens, we adjust our inflation rate to equal 20% — reserveRatio. As the reserveRatio gets closer to a 10% ratio, inflation goes to 0%. However if there is a lot of demand for the token, and people are buying based on the 20% curve, the reserveRatio moves up closer to 20% and inflation increases toward the max 10% rate.
Eventually exchanges will be able to offer a more competitive bid-ask spread than our contract. Once our token becomes liquid enough to be traded on exchanges, the majority of trading will start happening there, with a price somewhere in between the bid-ask spread offered by the contract. Once the exchange price moves above or below the buy/sell curves, the contract will present an arbitrage opportunity, adjust the inflation rate and mint or burn tokens as needed to match the exchange prices.
Bonding Curve and ICOs
You can do an ICO with a bonding curve token. Bancor ICO is one such example. They used 20% of the funds raised in their ICO to initialize a 10% bonding curve token contract. Half of the total supply of the tokens was distributed to ICO contributors and half to the founders. As a result the 10% of the total market cap of the tokens was backed by Ether.
Bancor token sale, however was far from exemplary and much closer in design to a vanilla incapped ICO. The main novelty was immediate token liquidity and dynamic token supply.
A more novel approach would be to launch your token and have it be liquid before conducting an ICO — this dynamic is particularly great for testing market demand for utility tokens before doing a sale.
Here is how you do it:
- Create a bonding curve with your desired reserveRatio, for example 20%.
- At token launch, allocate an icoFund — amount of tokens controlled by the contract owner, not backed by Ether and not tradable via the contract.
- Let users buy and sell tokens based on a curve that takes icoFund into account (totalSupply = tradableTokens + icoFund). The calculation assumes the icoFund tokens are backed by assets even though they are not, however this is fine because the tokens in the icoFund are not tradable.
- Announce the ICO start time and set price at current token price — this will create an automatic cap = currentPrice * tokens in icoFund.
- When participants send Ether to the ICO contract, deposit 20% of the balance into the token contract poolBalance, convert an appropriate amount of icoFund tokens into regular tokens and send them to the participants.
- Creating separate buy-sell curves and making it less profitable to sell tokens right away can also limit pump and dump risks.
This model can still be abused to defraud investors, however if set up correctly and with full transparency, it can offer protection from pump-n-dump manipulation and abuse by founders.
Intra-Network “local-tokens”
As both Chris Burniske and Simon de la Rouviere propose, local bonding curve tokens can be used within a tokenized platform to incentivise users to create sub communities or curate sub topics via a Token Curated Registries.
Attack Vectors & Security
Front-running Attack
Bonding curves are susceptible to front-running attacks. This is when an adversary watches for a big buy order coming in and sends her own buy order with more gas to cut ahead of the original order. Once the original order is executed, the attacker sells her tokens at a guaranteed profit. You can read more about this exploit in the Bancor protocol here:
Bancor’s proposed solution is to set a limit on gas price buyers and sellers can submit and encourage everyone to use the maximum allowed gas price when sending their orders. This prevents the adversary from having their order executed ahead of the already-submitted orders.
Another, less effective fix is to ask users to submit a minimum token amount they would like to buy. This way if the price has increased after the order was submitted, it won’t execute unless the contract is able mint the minimum amount.
Deep-Nested Bonding Curves Increase Risk
In the case where we have several layers of child tokens, each with their own bonding curve the risks are compounded.
Lets say Alice creates a platform token with a 10% reserve ratio backed by Ether. She lets users create an arbitrary amount of child tokens, each with their own children and bonding curves.
Bob creates his own token with a 50% reserve ratio backed by Alice’s token. Bob’s token’s price is now backed by only .1 * .5 = 5% of Ether.
Carol creates a token with a 20% reserve of Bob’s token. Carol’s token is now only backed by .1 * .5 * .2 = 1% of Ether and will be extremely volatile.
Platforms will need to figure out ways to limit these scenarios and make the risks transparent to the users. One solution is to limit nesting reserve ratio so that they don’t exceed a minimum compounded reserve ratio.
