Bonding Curves and Bonding Curve Accessories
By: Doyun Kim
Tags: Smart Contracts, Ethereum, Bonding Curves, Bancor

Bonding Curves and Bonding Curve Accessories

An Unholy Mix of Introduction and Abstract

Admittedly, I am pretty late to the Bonding Curve conversation. The original concept of Bonding Curves/Continuous Tokens/Smart Tokens was created back in 2016 and 17 by Bancor and Simon de la Rouviere (although Rouviere himself denies this in his article about the history of the Bonding Curve design). Most of the articles I’ve read during my research were from 2018 or 19. On the other hand, 2020 was the year of DEFI swaps, lending protocols, and yield farming — so far 2021 hasn’t been too different.

Right now, Continuous Crypto-Economics lie on the fringes of the “crypto-sphere”, but it’s far from dead. For example, FairMint is actively developing digital securities based on the continuous token model, and is currently allowing early access to their CAFEs (Continuous SAFEs). Outside of securities, Truebit’s $TRU token demonstrates a fascinating utility token architecture using Revenue-Based Bonding Curves and deflationary tokenomics.

In that case, what better way to spend my time than to organize and reduce all the information I’ve gathered on the subject, and add something to my github as a bonus.

Terminologies

Disclosure

If you do your own research into this, you’ll find others have different definitions for some of these terms. For instance, in some cases “Bonding Curve” and “Continuous Token” are used interchangeably (the term “Smart Token” is also thrown around), but in this article, there is a clear distinction between those two. Also, when people usually refer to a “Bonding Curve”, its derivation from the “Bancor Formula” is implicit; here, I’ve specified “Bancor Bonding Curve” as the pricing algorithm derived from the formula.

I feel obligated to point out that the terms and definitions here were chosen for personal convenience. My philosophy is that definitions for abstract cocnepts should not add too much to what the name implies; e.g. just from the name “Bonding Curve”, it’s impossible to predict its derivation from something that’s called a “Bancor Formula”. Furthermore, as will be discussed later, the “Bancor Formula” derives a monomial “Bonding Curve”, which ignores other possible Bonding Curve algorithms.

Bonding Curve

If you google “Bonding Curve Definition”, coinmarketcap’s definition appears at the top as a featured snippet. So, we might as well go with that:

A mathematical concept used to describe the relationship between price and the supply of an asset.

In other words, a Bonding Curve is a function that returns a price at a given supply. It can be visually represented as a supply graph curve:

Simple Bonding Curve Visualization

We’ll add just a tiny bit more to the definition: Continuity, which is arguably implicit from “Curve”. However, it is important that we clarify this since it leads us to our next term.

Continuous Tokens

are fungible token assets whose price is determined by a Bonding Curve. As a result, such tokens must have the following properties:

Limitless Supply (allegedly)

Personally, I think we can do away with this one. Limitless supply only makes sense if the Bonding Curve is continuous on all positive real numbers. But, it’s not hard to imagine a token whose bonding curve is continuous on a upper bounded interval, in which case the token supply must also be upper bounded. Deterministic Price, which is implicit from the definition. Continuous Price, which is also implicit from the definition. Instant Liquidity

Funds deposited for purchasing/minting tokens are kept in a collateral reserve, making instant liquidation possible. As a result, the bonding curve functions as an Automated Market Maker, and liquidity is always available by design. The reserve is kept in Reserve Tokens — for convenience, we’ll assume the reserve token is ETH.

Let’s look at property no.4 more closely:

Let’s consider a bonding curve function, P = f(S), where P is the per unit token price (in ETH) at a total supply of S tokens. Given an initial supply of S₀ at an initial price of P₀, the cost of purchasing/minting t tokens is:

Now, token supply is S₀ + t, and the collateral reserve has a balance of at least Mₜ.

Price of minting t tokens

Now, say another arbitrary token owner wishes to liquidate k tokens ( k ≤ t ). At the current supply of S₀ + t, liquidating k tokens returns:

Returns for liquidating k tokens

Since Lₖ ≤ Mₜ, there is enough in the reserve to allow k tokens to be instantly liquidated without an external liquidity provider. This implies that, at any given point in time, the reserve balance is lower-bounded by:

Total Balance of Collateral Reserve

For convenience, we’ll assume that the reserve has just enough to allow instant liquidation.

Bancor Bonding Curve

is a Bonding Curve whose algorithm is derived from the Bancor Formula.

The Reserve Ratio or Collateral Weight or Reserve Weight — we’ll stick to the last one — is the fixed ratio between a token’s Market Capitalization (in ETH) and the Collateral Reserve Balance (also in ETH).

This paper by Meni Rosenfeld does further analysis of the Bancor Formula and extrapolates the following. Note that the 0 underscore indicates initial value.

Note that this requires a non-zero supply and reserve. Hence, when “initializing” a Bancor Bonding Curve, we need to set three values:

Initial Supply (S₀) Initial Reserve (R₀) or Price (P₀) Fixed Reserve Weight (F)

If we choose R₀ instead of P₀ the supply to price equation becomes:

Note that these three values determine how sharply a token price needs to adjust each transaction — i.e. price sensitivity.

For S₀ = 1, R₀ = F = CW

For S₀ = 1, F = 1/2

Revenue-Based Bonding Curve (RBBC)

has two Bonding Curves; one for Minting tokens, and one for Retiring/Burning/Liquidating tokens. Price of minting (Pₘᵢₙₜ) is always larger than or equal to liquidation returns (Pᵣₑₜᵢᵣₑ). The difference between the total deposit (from minting) and the collateral reserve (for liquidating) is the Revenue. An organization that uses an RBBC as part of its revenue model is called a Continuous Organization. A continuous tokens with an underlying RBBC is called a Revenue-Based Continuous Token (RBCT).

Visualization of a RBBCs Two Bonding Curves

Perhaps the most obvious Revenue-Based Bonding Curve is one where Pₘᵢₙₜ and Pᵣₑₜᵢᵣₑ are linearly proportional:

We’ll call this a Scalar RBBC, and k is called the “Mint to Burn (M2B)” ratio. Naturally, this means that:

Revenue-Based Bonding Curve Applications

RRBCs for Securities (ft. FairMint)

Here are links for pages explaining FairMint’s Continuous Security Offerings and CAFEs (Continuous Agreement for Future Equity).

RRBCs for Utility Tokens (ft. Truebit)

Truebit’s $TRU token is priced under a Scalar Revenue-Based Linear Bonding Curve — the Bonding Curve is linear and the M2B is 8. $TRU is also a deflationary utility token — services are paid for in $TRU tokens, and a portion of the payment is burnt. In theory, this allows $TRU to be reliably soft-pegged to ETH. Furthermore, note that $TRU is neither an equity nor a governance token. Hence, the Truebit company itself has negligible incentive owning a vast amount of $TRU, as is often the case in popular utility tokens like LINK and GRT. As long as there is a demand for the protocol, new $TRU tokens will be minted.

If you can tolerate hasty writing, here’s my article explaining $TRU’s tokenomics in detail.

Programmatic Implementation

PENDING CHANGE!!!

For the past couple of months I’ve prioritized a personal project rather than finishing this article and its programmatic implementation. My project does incorporate bonding curves, however. I’ve finished writing the smart contracts and the relevant hardhat tests for the project, and it should be pretty easy to port over the contracts and tests from that project to this one. I’ve learned a few things in the meantime, in particular the feasibility of Bancor bonding curve contracts (spoilers: it’s ridiculously expensive). I will come back to this article and finish this section as soon as possible.