Skip to main content

All about Token Bonding Curves


Bonding curves are a significant concept in the domain of blockchain and cryptocurrencies as they offer a novel way to program the pricing mechanism for digital assets. Much research has been completed by both pioneers in the field and by general economists, and the topic is one that is new and worthy of pursuit. Here, we will explain the idea of bonding curves, their benefits, and practical examples – as Coinweb’s revolutionary cross-chain tokenisation platform, brings the concept to life for any of our users who wish to use token bonding curves for any range of real applications.

Prior to blockchain, it was not possible to dictate the exchange value of two different assets – this interaction has always been determined by trading or exchanging, and the relative value of the assets being traded was de facto what is agreed upon by the parties performing the transaction. There is a saying that goes to represent this well:

“What is the value of something?”

“What someone is willing to pay for it”

The market determines this result, as has been laid out in Classical Economic Theory. The basic premise is that supply and demand, given perfect information and access to trade, will always meet at a price equilibrium. This ties in the theoretical concepts of scarcity, economic utility, and the free market to always tend the optimal price as determined by market forces.

But what if you could program the price? The advent of blockchain technology, its creation of digital currency and assets – enables that to become possible. This is the primary function of a token bonding curve, and it is an innovation that is brought to your fingertips by Coinweb’s LinkMint platform.

What are Bonding Curves?

In the simplest terms, bonding curves are mathematical curves (which can be viewed as a graph of a function f(x), such that the x-axis represents the Cumulative Amount of Tokens, and the y-axis represents the Price of Each Token), that define the relationship between the price and the supply of a specific token within a bonded market.

Each token created has a price determined by the curve, and every token bought or sold moves the price along the curve. They are often implemented in automated market maker (AMM) models, which allow users to trade directly with smart contracts, reducing dependency on traditional exchanges and intermediaries.

It is important to note that the above applies only to the bonded market that provides sufficient liquidity to support the price of the token supply. It can be denoted as a∫b(x) dx, or the area under the curve from point a → b. Unbonded token supply (which has no collateral backing the price) is referred to as “Naked Tokens.”

The curve can be any shape, but it's typically designed to start low, increase gradually, and then flatten out at a certain point. The aim is to provide an incentivizing mechanism for early adopters, ensuring that the price increases as demand rises and decreases as demand falls, implementing a form of automatic, programmable price discovery.

The easier it is to derive a real-world value for the project, the easier it is to derive a real token value - creating a crypto-economic feedback loop necessary for a sustainable system.

What to consider when designing for a bonding curve:

  • You may wish to incorporate 2 curves, one for BUYING and one for SELLING

  • Early investors should typically be rewarded higher than late adopters

  • Any opportunity for price manipulation and abuse WILL be taken advantage of. Because of arbitrage, the bonding curve will always be the oracle of truth for a defined supply of tokens.

  • The natural growth of a token's underlying project is likely to follow an S-curve (more on this soon) where growth accelerates quickly and then decelerates as a project reaches maturity and stability.

  • xpect tokens to scale up at least 5-10x from their inception. Pre-mining (in this case, distribution of tokens before implementing the curve) is possible but needs to be justified.

  • There is an expected/estimated amount of capital developers can reasonably expect to attract across a token's lifetime (think in the millions for bigger projects). Returns should remain logical across that range.

There is a variety of approaches one can take when designing a bonding curve, but to keep it simple and relevant to what is planned to be offered via LinkMint, the available bonding curves include:

Figure 1: Constant (Peg) or Linear (y = mx +b)

Figure 1

Figure 2: Polynomial (y = axn) or Quadratic

Figure 2

Figure 3: Sub-linear or Logarithmic (y = a logb(x))

Figure 3

also known as a Hyperbolic curve

Figure 4: S-curve (y = 1 / (1 + e^-m(x+b)))

Figure 4

also known as the Sigmoid curve, where m determines how aggressively the curve accelerates during the growth phase, and b determines the inflection point of the curve where it begins to decelerate.

Piecewise or Custom curves, which can incorporate multiple types of curves (above) for each section of the supply – and is possible to implement in LinkMint using the Draw Your Function feature, enabling up to 16 degrees of polynomial functions.

Bonding curves are powerful tools that should be a consideration in every new blockchain project's roadmap. They're simply the smarter way to launch tokens and put the power of smart contracts into trading. When done right, they can be just as important in the long-run as the very project they back.

Benefits of Bonding Curves

1. Price Discovery

In conventional asset markets, price discovery is reliant on supply and demand dynamics between buyers and sellers. Typically, this is an unpredictable and precarious process that is commonly influenced by the exchanges (often CEXs) and market makers, and is highly subject to a combination of incentivization and marketing hype. Bonding curves bring an alternative mechanism where price discovery is defined programmatically, eliminating the need for an order book or matching buyers with sellers.

2. Liquidiry

Bonding curves ensure constant liquidity. Any quantity of tokens can be purchased or sold at any time, with the price being dictated by the curve, reducing the typical risks associated with illiquid markets. This is true as long as the supply of the token is bonded to some form of collateral; but it is possible to decouple from this collateral value by using “Naked Tokens,” which in contrast to bonded tokens, cannot be sold back to the curve.

3. Visible Incentives for Early Adopters:

Bonding curves typically incentivize early adopters, and is enticing due to its visibility. If the demand for the token increases over time, early buyers stand to benefit more from the price appreciation, creating a stronger demand for early purchases.

4. Fair Distribution:

Tokens are available to all participants at the same price point at any given time, thereby promoting a more equitable distribution of assets.

5. Transparency:

The rules around token pricing and exchange are predefined and embedded in a smart contract, providing full transparency and minimizing trust-related issues.

How Bonding Curves are Used

1. Decentralized Autonomous Organizations (DAOs):

DAOs often use bonding curves to issue their native governance tokens. For instance, the community-centric project, MolochDAO, employs a bonding curve to distribute its tokens. Early contributors can buy tokens at a lower price and potentially sell them at a higher price later, rewarding their early involvement and contributions.

2. Crowdfunding and Initial Coin Offerings (ICOs):

Bonding curves can be used to raise funds for a project. Bancor, a blockchain protocol, uses a bonding curve to manage its token supply. During the ICO, participants purchase tokens, and the price increases along the curve. When participants want to exit, they sell their tokens back to the curve, which reduces the price accordingly. This ensures liquidity and price stability throughout the ICO process, and traditional price discovery can be used after the target supply is reached.

3. Prediction Markets:

Augur, a decentralized prediction market, uses bonding curves for the issuance and redemption of their shares in market outcomes. Participants buy shares that represent a specific outcome. As demand for a specific outcome rises, so does the price of the shares. This represents an example of one of the first novel use cases for cryptocurrency token bonding curves.

4. Art & Collectibles:

Bonding curves are increasingly being used in the realm of digital art and NFTs. The art project "This Artwork Is Always On Sale (TAIAOS)" employs a bonding curve to ensure that the artwork is always available for purchase. When someone buys the artwork, the price for the next buyer is automatically higher. If the current owner decides to sell, they sell it back to the curve, and the price decreases.

Other implementations developers can use to protect their tokens from pump-n-dump schemes:

  • Buy/sell taxes
  • Separate buy/sell curves
  • Time-locks
  • Disabling token sales altogether (only relevant for certain cases)

These features are planned to be offered on the LinkMint platform in the future, so at this time they will not be covered in this article. More options will become available as we move further along our roadmap, so be sure to stay tuned and always feel free to provide feedback for us in order to improve our platform.

Typical flow of a bonding curve interaction:

  • A smart contract is created that allows users to mint/buy a new token (eg. Bonding Curve Token, BCT) with a specified reserve currency (let's say CWEB).

  • The price of BCT is algorithmically calculated in relation to its current circulating supply and shown in its reserve currency, CWEB.

  • With the reserve currency, the user can buy the new BCT token through a smart contract. The sold CWEB is kept in the smart contract as collateral and not dispersed to any person or team.

  • After the user completes their purchase, the price of the token will move along the bonding curve in relation to the amount of supply the user has just minted (likely moving the price up for future buyers)

  • At any point, a BCT holder can decide to burn/sell their token back to the curve. If the price continues to go up after their initial purchase, the user will likely sell at a profit (minus gas and fees). The user will receive back the bonded CWEB from the smart contract after their sell is approved.

Note: Finding the price of any buy or sell on the curve is NOT as easy as just multiplying the current price by the number of tokens a user wants.

Because the price moves continuously, each incremental increase in the supply will increase the price of the token (slippage). Obviously, it would be a waste of effort and gas to try to split the buys up into many small pieces, so we'll call on a bit more math to help out. Referring to a polynomial bonding graph (easiest to explain), we can see the price at any point based on the current supply:

y = axn price = tokenSupply2

Using Calculus, if you take the integral of any equation, you can find the area underneath its curve. On a bonding curve, this area represents the poolBalance, or the amount of the reserve currency (let's say CWEB) that has been bonded to the curve to mint new tokens.

Taking the integral of price to find the poolBalance:

poolBalance = ∫ price = ∫ tokenSupply2 this, solves to poolBalance = ⅓ tokenSupply3

Using this equation, you can now calculate the poolBalance based on the current tokenSupply. To find the total price of the next set of tokens, you just need to go one step farther by integrating from the current supply to the final supply after a successful purchase (subtracting the initial poolBalance from the final one). For the sake of this example, we'll imagine the user wants to buy 10 tokens.

This would make the equation:

priceForTokens = poolBalance(tokenSupply + 10) - poolBalance(tokenSupply)

Bonding curves represent an innovative approach to programmable value exchange in the world of blockchain and DeFi. By establishing automatic price determination and guaranteeing liquidity, they may have significant implications for various industries and digital ecosystems. However, like all financial mechanisms, they come with inherent risks and challenges that need to be thoroughly understood and managed. As with any investment, due diligence is essential.

Now, let’s take a look at using token bonding curves with Coinweb’s LinkMint Cross-chain Tokenisation Platform!

LinkMint Bonding Curves

Curve Types

(discussion of variables follows after this section)

1. Fixed (pegged) Price

The token has a fixed price in CWEB. This option requires filling the bonding curve with enough CWEB to cover the cost of the existing issued tokens, thus the transaction to create the bonding curve might require a significant amount of tokens.

  • p = Price (input box, positive, >0, unit CWEB)
  • f = Fee (%, exponential scale 0-100%)

Table 1

2. Price Peg with Naked Tokens

The token has a fixed price in CWEB, but a portion of tokens are naked meaning they are not covered by CWEB in the curve and cannot be sold back to the curve.

  • p = Price
  • f = Fee
  • n = Naked tokens (slider 0 → premint)
    Table 2

3. Smart Variable Price

Curve specified through an initial price and growth in price and fees.

  • p = Price at x0: From 0 (not included) to infinity (not included)
  • f = Fees: From 0 (included) to 1 (included), displayed as a percentage.
  • k = Token per cweb acceleration: From minus infinity (not included) to kmax (not included).

Table 3

Auxiliary variables:

Table 4

4. Smart Variable Price with Naked Tokens

Curve specified through an initial price and growth in price and fees A portion of tokens are naked meaning they are not covered by CWEB in the curve and cannot be sold back to the curve.

  • p = Price at x0: From 0 (not included) to infinity (not included)
  • f = Fees: From 0 (included) to 1 (included), displayed as a percentage.
  • k = Tokenper cweb acceleration: From minus infinity (not included) to kmax (not included).
  • n = Naked tokens: From 0 (included) to premint (included).

Table 5

Auxiliary variables:

Table 6

5. Quadratic Amount Function

Curve token amounts specified by a pair of quadratic functions for the buy and sell side. It is not necessary to input values for cbuy, x0, or domain.

Table 7

Auxiliary variables:

Table 8

6. Hyperbolic Price Function

Curve token price specified by a pair of hyperbolic functions for the buy and sell sides. It is not necessary to input values for cbuy, csell, or domain.

Table 9

Auxiliary variables:

Table 10

7. Draw Your Function

Buy and sell curves are fitted as a 16-degree polynomial based on hand drawn curves.

Curve Settings

Price (CWEB):
  • Set of UI controls for selected Price Type: slider, two-pos-slider, input box.

  • Every Price Type has a specific set of UI controls. Proper Price Settings section is loaded when switching Price Types.

  • Some Price Types may have certain UI controls disabled with frozen value visible, to show close logical relation to another Price Type with those controls enabled.

Fee (%): From 0 to 1, displayed as percentage (i.e 0.1234 would be displayed as 12.34%).

Token per CWEB acceleration (kmax): The raw coefficient of Tokens per CWEB acceleration, dx. The increase of “token per CWEB” as the amount of CWEB increases.

In addition to the fields in the forms, we will need to fetch the amount of already minted tokens; and adjust it from minimal units to coin units by multiplying it by 10−18. Let’s call this variable premint.

Parameter Values
Abuy:-token per CWEB acceleration / 2
Bbuy:-1 / (p / (1 - fee) - 2 . Abuy.x0)
Cbuy:-Abuy .x02 - Bbuy.x0
Asell:-token per CWEB acceleration / 2
Bsell:-1 / (p.(1 - fee) - 2 . Asell.x0)
Domain:min (domainbuy, domainsell, MAX_AMOUNT_OF_CWEB) The maximum amount of CWEB that could ever be held by the curve.
Kmax:1 / ( (p . ( 1- fee))2 . 2 . Csell)

x0: will be the initial cweb-balance the curve will start with (the user will need to pay this amount). x0 has to be strictly smaller than domain. That number can not be a float due to backend inconsistency for BigInt conversion.

if asell = 0Csell . p . ( 1 - fee)
if asell > 0(-1/(p.(1-fee)) + √(1/(p.(1 - fee))2 + 4.Asell.Csell)/2.Asell
else(-1/(p.(1-fee)) - √(1/(p.(1-fee))2 + 4.Asell.Csell)/2.Asell

Formula Summary
Buy Price:-1 / (2Abuyx + Bbuy)
Sell Price:-1 / (2Asellx + Bsell)
Buy Amount:Abuyx2+ Bbuyx + Cbuy
Sell Amount:Asellx2+ Bsellx + csell

All parameters and values will be defaulted to the value of the bonded token, which in all cases will be the native CWEB platform token.


  • buy: means the curve-contract loses token, and gain cweb (the user gain token, loses cweb).

  • sell: means the curve-contract gain token, and loses cweb (the user loses token, gain cweb).

  • the amount gain/lost for the curve is the opossite of the users, specifically:

    • always, the amount of token the curve gains is equal the amount of token the user loses.

    • always, the amount of cweb the curve gains is equal the amount of cweb the user loses.

    • always, the amount of token the curve loses is equal the amount of token the user gains.

    • always, the amount of cweb the curve loses is equal the amount of cweb the user gains.

  • minting is buying on a bonding-curve.

  • there’s “buying price”.

  • there’s “selling price”.

  • price (buying, selling or plain price) refers to cweb per token; WARNING not to be confused with token per cweb (the inverse):

    • Rationale: When people speak about the “bitcoin” price, it referse to how many dollars you’d get after selling 1 “bitcoin” (or how many dollars it would take you to buy 1 bitcoin), so by analogy we’ll say that the price of a “token” is how many cweb are required to buy/sell 1 “token”.

    • Note: this is just a naming convention, it is ok to use “token per cweb”, but to avoid confusion, it should not be called “price”, but something else (i.e “inverse_price” for example).

The formula for prices, fees and so on derive from here.

  • then fee (spread) = ??? . BUT we will not use “fee” on code, no need to compute it unless we want to show it on UI or similar.

  • we’ll call X the number of cweb held by the curve-contract. the difference between X on t_1, minus X on t_0, is the cweb the user needs to pay/loss (if positive), or what the user receive/gain (if negative).

  • we’ll call Y the number of token held by the curve-contract.the difference between Y on t_1, minus Y on t_0, is the tokens user needs to pay/loss (if positive), or what the user receive/gain (if negative).

  • the formula, (let’s call it f) :

    • It will be of the form y = f(x).

    • The formula will be used to determine the amount of tokens the curve is required to held, when an specific amount of cweb is held by the curve.

    • f' the first derivative of f, f'' the second derivative, f''' the third and so on.

  • there would actually be 2 formulas, f_buy and f_sell.

    • f_buy will be used to compute amounts when buying.

    • f_sell will be used to compute amounts when selling.

  • the (buy/sell)-price of the token based on cweb will be defined as price_at(x) = -1/f'(x). Notice the (-). For example, (imagine constant price, y = - 0.5·x -> f(x) = -0.5·x, f'(x) = -0.5 ), if the curve gains 2 cweb (i.e the user pays/loses 2 cweb) then the curve loses 1 token (i.e the user receive/gains 1 token) then it would mean the price of 1 token is 2 cwebs, price_at(x) = -1/f'(x) = -1/(-0.5) = 2 .

  • buy operation will be denominated in cweb, meaning the user will specify how much cweb wants to spend, and the system will compute how much token he will receive. The reason for this is that the the equation (y = f(x)) is defined as a formula over cweb, so it is easier to compute values base on cwebs than it is to compute values based on tokens (it would require computing inverses).

  • sell operation will be denominated in cweb, meaning the user will specify how much cwebs he wants to obtain, and the system will compute how many tokens he’ll lost.

    • this is because of the same reason as before.

    • Unfortunately this means that selling an exact amount of token (i.e, sell all user’s token ) will be complicated, and probably there would be a tiny remaining dust.

  • The initial balance of token for bonding-curves, by definition, will be 0.

    • The amount of token held by a bonding-curve will get reduced when the user mints (buy), this means, that the amount of token held by the bondig-curve will be a negative number.

    • The amount of token held by a liquidity pool has to be always 0 or more. It is not allowed to have negative balance of token.

    • Bonding curves are like a kind of “magic liquidity pool” where negative balance of token are allowed.

    • Negative balance of cweb is never allowed, neither for bonding-curves nor liquidity-pools

  • When defining f_buy and f_sell, the creator will specify the domain of those functions.

  • The domain will be a range.

  • We’ll define the function f_wide(x) = f_sell(x) - f_buy(x).

  • We’ll define as y_guarantee as y_guarantee = f_buy(x). This is the amount of token that the contract needs to keep.

  • Rationale for y_guarantee = f_buy(x):

    • on liquidity-pools:

      • liquidity-pools can not create tokens, so if we withdraw to much token from the liquidity pool, it could reach an state where it could not satisfy the buy/sell price derived from f_buy & f_sell.

      • (on this model, by design) we only directly withdraw tokens from liquidity-pool/bonding-curve, not cweb. (When we indirectly withdrwal cweb what we actually do is withdraw token, then sell those tokens for cweb).

      • Because of this, the only problem we could have is not having enough token, this would only be a problem when users try to buy tokens (not when selling).

      • if y = f_buy(x), meaning the amount of token is on the line of the f_buy graph, if we only use the f_buy function, then y will reamin on that line.

      • that means that as long as y > f_buy(x) then there would be no problem while buying.

    • on bonding curve:

      • We define y_gurantee as the amount y that the bonding curve would need to gurantee if it were a liquidity-pool.

      • This means that is the amount that needs to gurantee so it doesn’t need to do extra mint.

      • This definition is useful because soon it will be possible for the token owner to limit himself: “I’m not going to mint more than what is marked by the bonding curve formula”.

  • We’ll allow the contract owner to withdraw fee (tokens) as long as y > y_guarantee. So withdrawable_y = y - y_guarantee. Of course only a positive amount should be allowed to be withdrawn from the contract owner.

  • f_buy and f_sell have the same domain, and this domain is an interval from 0 to MAX_DOMAIN or infitity. (negative cweb balance is not allowed).

    • Rationale:

      • we don’t allow gaps on the interval because that would mean we the amount of cweb help by the curve would need to “jump”.

      • if the initial domain start after 0, then we could shift the whole function to the left to define a new equivalent function that starts at 0. (unless there’s some asymptote, but we don’t represent asymptotes anyway).

  • f_buy and f_sell are supposed to have continuous first derivative .

Rationale: we need it for the formulas and numerical methods.


  • Liquidity-pool can NOT create cweb and can NOT create token.

  • Bonding-curve can NOT create cweb.

Very important, NO smartcontract or computation-block can create cweb!! If it gives away cweb is because it previously received cweb.

  • “total amount of token” = “token inside liquidity-pool/bonding-curve” + “token outside liquidity-pool/bonding-curve”

  • “token inside liquidity-pool/bonding-curve” = “initial token inside liquidity-pool/bonding-curve when created” + “tokens sold by users” - “tokens bought by users” - “tokens withdrawn from the liquidity-pool/bonding-curve”

  • “initial token inside bonding-curve when created” = 0. It doesn’t really matter the initial amount cause the bonding curve can mint/burn token on its own, and for price/buy/sell formula the only important thing is the difference of amount between 2 points (or the derivative), rather the actual amount.

  • “initial token inside liquidity-pool/bonding-curve when created” = “token spend while creating the liquidity-pool/bonding-curve”; (this implies that “token spend while creating the bonding-curve” is 0).