Token Bonding Curve Design Parameters
Mapping Design Space, Parameters and Use Cases of Bonding Curves 🎼
As a crucial subset of curation markets, token bonding curves have gained popularity as a fascinating new cryptoeconomic design mechanism. They can enable price discovery and autonomous markets for pretty much anything. Several live implementations already exist on main-net, among them some widely used dApps including PoWH3D, and Bancor, and a multitude of alpha implementations on testnets. Check out the wonderful Memelordz to create bonding curved meme markets on Rinkeby.
While the concept is gradually building a following, the momentum is somewhat slower than with Token Curated Registries (TCRs). Bonding curves still seem to be far less explored and in my experience often still poorly understood. I believe that a primary contributor to this is the fact that the design space is arguably much wider and also unexplored due to the fact that there are many parameters to play with.
In this post, I attempt to map out the wide design space and parameters of bonding curves and highlight considerations and use cases. We also explore how to mitigate some of the attack vectors, such as pump and dumps. In addition, I describe a simple framework that can be applied for various use cases. The ideal Schelling point parameters likely differ for each use case. This post is intended as a token engineering toolset, to spur experimentation and innovation in the community and create a more holistic way of thinking about bonding curve designs.
In its simplest form, a token bonding curve is an automated market maker for trading pretty much anything. The contract accepts collateral and issues its native token in return and vice versa. For an intro, check out Justin Goro’s overview here:
We start by asking, what are the key parameters we can adjust to create new interesting properties that serve different use case? Below I propose 6 design parameters that can be derived from the name and explain each of them in depth, followed by a practical application.
- The token metrics: defined by A) the token issuance and B) total supply.
- The bond(s): defined by the C) bonded collateral and the D) traded objective or asset.
- The curve: defined by its E) mathematical function and its F) pricing structure.
1. The Token
A. Issuance: the type of token that the bonding curve creates.
Parameters…
- Fungibles, ERC20
- Non-Fungibles, ERC721
- Securities, ERC1400, ERC1410
- Composables, ERC998
- Considerations: the tokens issued by the contract are essentially a digital asset, which could provide utility, or not. It could grant access rights to another contract, or represent a real-world asset in the form of a security. The creator may want the token to be fungible or non-fungible. Practically no research has been done into bonding curves that issue non-fungibles (ERC721s) or other types of tokens. Use cases for this could include licenses in software products, collectables or securitization.
B. Supply: the total number of tokens that the contract can issue.
Parameters…
- Finite: capped token supply.
- Infinite: uncapped “infinite” issuance.
- Vesting: how the issued tokens are vested by participants or creators.
Many bonding curve designs currently proposed don’t implement a cap on the number of tokens issued, or consider vesting periods. For goods that are hard to price in the real world uncapped issuance can be a great price discovery mechanism. It avoids having to create and start with a potential market cap estimate. However, for goods that reach a definite valuation, an infinite supply may create adverse effects for token holders and the market dynamics.
In addition, it is conceivable that a bonding curve could also have different minting functions to represent negative interest in the curve beyond the positive interest of buying and selling, which could present a new parameter. Such a mechanism could, for example, be used for shorting. I’ll explain the possibilities around this in a future post.
Considerations: token supply and vesting in bonding curves hasn’t been explored extensively yet but has very large consequences on the future utility of any market on a bonding curve. For example, we might want to cap the total trading supply of a digital art piece and include vesting for early buyers, but we might not want to cap token supply for a meme.
2. The Bond
C. Collateral: the value or attention staked into the contract and its reserve parameters.
Note: Bancor refers to the collateral in its contract as reserve and there are potential design parameters and function implementations that alter the reserve/collateral ratio.
Parameters…
- Native protocol tokens: Ether (ETH) or Ocean (OCN).
- Stablecoins: DAI or similar ERC20 stabletokens. We built a first Proof of Concept of this at the recent #cryptolife hackathon by Status and plan to build an open-source implementation.
- Non-fungibles: A bonding curve backed by kittens, or other NFTs.
- Multi-collateralized:
- A combination of ERC20s or native protocol tokens;
- Tokens from other bonding curves, called nested bonding curves. Staking bonding curve tokens into further bonding curves essentially creates derivatives. Use cases would for example be a sub-meme that spins off another meme, or a derivative molecular structures developed from the original lead compound. Volatility in this case is compounded and nested curves only have fractions of the collateral in their original curve. The interaction between the “mother” curve and its child curve should be carefully modelled. Nested curves were first introduced by Slava Balasanov here:
Considerations: Trading of bonding curves itself will be volatile, depending on how the curve is implemented. If the underlying collateral exhibits volatility on top of that this will limit utility and create market inefficiency and arbitrage. Many bonding curve implementation will therefore likely need to be backed by stable coins or a combination.
D. The Traded Asset or Objective
The contract and tokens issued need to represent ownership in some type of asset, principal, state, attention or even a utility right. This asset or state can be linked or even staked into the contract. It essentially represents the bonding curves link to the real, or digital world.
Parameters…
- Staked as an Re-Fungible: NFTs (via Re-fungible token), like a cryptokitty or an asset linked to the NFT, like intellectual property. Some use cases are outlined in the article below.
- Linked: IPFS link, Meme, or connected contract, similar to Memelordz.
Legal considerations: the traded asset will very much define the legal classification of the token by regulators. For example, if we were to place a real-world asset, like real-estate, into a bonding curve and token holders were paid dividends from the rental income of that real estate then that token will most likely be a security. If, on the other hand, the token represents a limited access ticket to an arts festival, where a limited number of tokens are sold along with a linear price curve the token is likely to be a consumption good.
3. The Curve
E. Curve function: enables the autonomous market making function of the contract by plotting an algorithmic relationship between supply and price.
Parameters…
- Polynomial, exponential and logarithmic functions
- Linear functions
- Rule-based
- Sigmoid functions
Mathematical functions come in many flavours. Wilson Lau wrote a great article on a few potential functions and implementations here:
Slava Balasanov also recently published a great article on the various parameters of curve functions and formulas.
Considerations: Arguably, the function is the most significant parameter as it defines the entire market structure, its utility and future. Important here is that if the curve creator wishes to reserve himself an initial supply, this would need to be coded into the curve for example as a horizontal function up unto a certain point. From a practical perspective, we’ve found that implementing curve types in solidity code can be quite challenging and ample testing is needed to get the curve and corresponding interface right.
There is a big question of whether the function can or should be changed once the contract is live, for example, if new information emerges. Ideas are circulating around the use of oracles to adjust function parameters or token holder governance. The rise and fall of curves may not be suitable for many normal market participants, so curves should be studied and ideally simulated well before implementation, including testing of the maximum and minimum ranges of supply. As a simple exercise, consider sketching your desired market behaviour out on paper or in excel to consider which curve best fits the desired incentive scheme.
F. Pricing: how buying and selling is structured in the contract.
Various authors to date have proposed different Buy_In and Buy_Out mechanisms implemented either by differing spread functions or via a fixed tax. This enables novel funding and price stabilisation mechanisms.
Parameters…
- Static pricing: one curve that defines the market. Useful as a pure attention mechanism without funding requirements and with a clear market structure.
- Dynamic pricing, spreads and taxation: different buy-in and sell out prices, whereas a tax or a spread is taken from contributors, which could be used to develop the asset in the form of recurring cash flows. I’ve drafted a first explanation of curve taxation here. Taxation could be implemented simply by taking a small amount of each purchase, or by implementing different Price_In and Price_Out curves. Introducing a tax or different pricing mechanism introduces friction to the market. As a side effect, this disincentivizes Pump and Dump or market manipulation, as any purchase comes with a guaranteed loss. Buyers are therefore incentivised to hold for a certain timeframe at least until their breakeven price is met again and they make a profit. This reduces the speculative aspects around bonding curves and introduces fundraising opportunities.
For example, a practical use case for continued funding of organisations using taxation has recently been proposed by Thibauld:
3. Individual dynamic pricing:
4. Equilibrium pricing: when a buyer purchases she also sets a pre-defined sell price. Once an equilibrium is hit, those sell prices begin to trigger.
“Time is Precious”
Another parameter, which hasn’t been formalised to date is the concept of time. The Convergent team brought up this point in the second curation markets community call. Specifically, time could be used to structure lock-up and release periods in the context of pre-minted tokens by creators, or as lock-up periods for early contributors. Again, this would decrease some of the speculative risks associated with bonding curves and make the risk and associated volatility of exits and manage the risk of pump and dump behaviour by early contributors.
Time could also be an interesting concept to consider within the context of staged bonding curves. A staged bonding curve could, for example, implement a new curvature after a certain time point has passed to reflect a new stage of the project.
A Simple Framework 🎼
To round it off, we’ll look at a simple use case where the parameters are put in practice in a step-wise framework. Imagine, you’re an artist creating a new digital artwork. You envision a community to partially co-own the artwork and contribute to its development, both financially and artistically.
The artwork and its rights, in the form of an NFT, are staked into a bonding curve. The (1) objective of the curve is to distribute ownership of the artwork by making the NFT fungible and tradeable, as well as measure attention in its popularity and enable funding. The creator decides that the contract (2) issues ERC20 tokens to represent ownership in the asset, potentially to be used as licenses etc. The (3) supply is fixed at 100,000 total tokens to introduce scarcity and define an overall market cap. Participants send (4) collateral in the form of DAI to provide the asset with stability. The curve (5) function is linear to provide participants with a fair and clear market structure. Finally, (6) the pricing structure is dynamic, whereas a small fee is levied on each purchase to support the artist. The fee disincentivizes market manipulation, build long-term commitment and ensures the future development of the artwork.
Conclusion & Lookahead
Six parameters with a multitude of options really leave us with a heap of design choices and potential combinations. Much of this still feels very sci-fi and experimental, but once you start looking into some of the practical use cases many design choices are rational and necessary. Specifically, some of these design choices can help alleviate the pump and dump nature that is introduced by certain curve functions.
The parameters presented here seem comprehensive, but new flavours and ideas are popping up on a weekly basis. Many of these design nuances are use case dependant and hinge on the market engineering goals: market growth, trading behaviour, distribution, token utility, market volatility and so on.
In my opinion, the most interesting design parameters and challenges revolve around the curve(s) and how the buying and selling prices are programmatically structured. Specifically, these mechanisms can enable novel funding schemes, introduce equilibrium designs that alleviate some of the pricing concerns with bonding curves, or implementation of Harberger taxes. We’re stepping on the surface of an iceberg here. Lastly, altering the supply dynamics of bonding curves to represent negative interest could also widen the scope of how market participants can interact with curves, for example allowing participants to short curves.
I believe that reaching consensus on abstract design parameters will help clearly define this new design space and defining an ERC for bonding curves could be highly valuable to standardise some of these parameters and enable easy experimentation. If you are looking for specific codebases around individual design patterns or just want to dive deeper, feel free to send me a message!
Thanks to Simon de la Rouviere, Florian Bühringer, all the authors referenced in the post and my team at Linum Labs.
