Deep Dive: Augmented Bonding Curves
This article is a deeper technical primer into the system design of the Augmented Bonding Curve used for the Commons Stack based off of Michael Zargham’s complex system research at BlockScience. For brevity, this article will assume a preliminary knowledge of bonding curves (if you need a refresh or an introduction, check out Slava Balasanov’s deep dive into bonding curves, Jeff Emmet’s simple introduction, and our first article on the topic here). The beginning of the article focuses on the overall design of the system and the second half will dive deeper into the equations and simulations that define how it all works.
As Slava puts it — “bonding curves are a design space for new incentive mechanisms”. Zargham’s research shows that ‘bonding curves’ themselves are only the doorway to this design space. By incentivizing early adopters with tokens encoded with intrinsic value, we are able to envision a new funding model for continuous organizations governed by their communities.
As research has progressed, many questions have been raised regarding the scalability, manipulability, and viability of bonding curves as a primitive — the major one being a comparison to Ponzi schemes. Bonding curves are very susceptible to “pump and dump” attacks and manipulation in pursuit of speculative returns. To combat the downfalls of bonding curves, the Augmented Bonding Curve system uses conservation principles and mechanisms to create a robust and controlled environment that aligns incentives and generates returns while managing speculation and subjectivity.
🛠 System Design and Flow
The Augmented Bonding Curve design can be conceptualized as a typical bonding curve with the addition of a funding pool, a token lock-up/vesting mechanism, and inter-system feedback loops.
The system models a Reserve Pool (a Reserve of bonded DAI and a Supply of tokens) and a Funding Pool (floating supply of DAI available for use) that work together to create a self-sustaining funding mechanism for a continuous organization. The system is launched in two stages: the Hatch Phase and the Open Phase.
During the Hatch Phase, initial contributors (i.e. founding members of the organization, devoted contributors, initial investors or “Hatchers”) participate in a hatch sale. The point of this phase is to gather contributors and pool capital — in our system we use xDAI - to bootstrap their Commons by funding an initial goal. A percentage is put into the Reserve Pool and “bonded” to the curve (i.e. minting tokens and determining the initial spot price used during the Open Phase) and a percentage is put into the Funding Pool. The capital in the Funding Pool remains un-bonded as a floating source of capital that can be distributed as real capital outside of the bonding curve.
For their contribution, Hatchers receive newly minted tokens, specific to the Commons, in return.
In a typical bonding curve system, these tokens could then be burned at any point or after an arbitrary temporal deadline. In an augmented bonding curve system, tokens minted during the Hatch Phase are locked (burning is disabled) in a vesting process. This vesting period combats any harmful early speculation/arbitrage that would affect the stability of the Reserve Pool. Although burning tokens to withdraw DAI is disabled, Hatchers’ tokens are far from useless — they can still be used to curate options for future capital allocation. Early in the system, this token usage is critical to ensure the capital in the Funding Pool is allocated to community initiatives, research projects and development milestones which will help grow the commons.
After the goal for the Hatch Sale is met, the vesting process is initialized and the system enters the Open Phase. In the Open Phase, anyone can mint tokens by contributing DAI into the curve, hence becoming ‘members of the Commons’. Their contribution will go directly into the Reserve Pool, returning newly minted unlocked tokens that can be burned or used to vote within the system. For the Hatchers, the first inter-system feedback loop comes into play. The Hatchers tokens are slowly unlocked in correlation to how much capital has been allocated to fund projects that support the commons. This means that for the Hatchers’ tokens to vest, capital from the Funding Pool has to be allocated to fund projects that positively impact the commons. With this vesting process and introduction of a governance model (we will be exploring Conviction Voting), members of the Commons (token holders), are economically incentivized to participate in the system’s governance process to allocate funding to curated projects that have the most beneficial impact on the Commons. This combats a known incentive misalignment observed in capital-allocating DAOs — in which capital allocations are rare because members are too selective or stingy with funds.
Finally, whenever tokens are burned (withdrawn for DAI → $), an exit tax is enacted on liquidation. As Members “cash out” and liquidate their tokens for DAI, a small percentage of their returns are sent back into the Funding Pool, allowing for the simultaneous funding of the commons while contributors are earning returns. This means the system always benefits, even if speculators are just looking to make returns.
The goal of the system is to attract new members of the Commons that see the impact of the Commons and want to be a part of the movement so that the Funding Pool can grow.
Now, on to some math….
⚖️ Initialization Equations
To initialize the hatching of an augmented bonding curve, the creators set three variables: the
p0 (DAI per token), and the
θ. The initial raise can be and is modeled as a range (min, max). The
initialAllocation is the % of the
initialRaise that is directly allocated to the Funding Pool. This sets the system up for success by consolidating a floating amount of capital to be distributed as soon as the system makes it through the Hatch Phase. These three variables are used to determine the
R0 of the system:
The second choice to be made is the shape of the curve. For sake of brevity, we will leave discussion on bonding curve design out of this article but please refer to articles from Wilson Lau and Paul Kohlhaas on the subject.
We defined our model by relating our
reserve in terms of a constant power function invariant
V(R,S), in which
κ represents varying degrees of polynomials (i.e. x², x⁴, x⁶). When defined in respect to
initialReserve , we’re left with the
By taking the derivative of this constant function, we derive our Price Function
P(R) in terms of the
With this invariant we can define the
reserve in terms of each other:
With these equations, we are able to derive the
p1 by substituting the initialSupply and initialReserve equations.
p1 is the price point of the curve when it enters the Open Phase.
✏️ Calculating the Return Rate
postHatchPrice equation, the return factor
p1/p0 can be calculated with the
It’s important to note that the return factor is not dependent on the initial raise
d0. All properties of the system hold true as long as inputs are positive, which provides a robust system at scale. When simulated across the power function invariant, the range of return rates provides a realistic model of the financial incentives of the curve in relation to the variables set at initialization. From our simulation, we saw formidable return rates under realistic conditions (i.e.
θ= 0.3 and
κ= 6 returns rate of 420%). These returns are paper returns, not realized returns because the Hatchers’ tokens are vesting. This can be compared to how post money valuations work in venture capital. By making Hatchers’ vest, we avoid harmful profit-incentivized ‘dumps’ and catalyze action within the community.
#Power function independent variables for analysis
vec_theta = np.arange(.1,.55,.05) #unitless
vec_kappa = np.arange(2,9,1) #integer
mat_return_ratio = np.outer(vec_kappa.T, (1-vec_theta))
📈 Simulating the Curve
A simulation for a curve (
V(R, S) = S^6/R) can be seen below. In this graph, the gray divider marks the end of the Hatch Phase and beginning of the Open Phase.
d0 = 5 #million DAI
p0 = .01 #DAI per tokens
theta = .4
R0 = d0*(1-theta) #million DAI
S0 = d0/p0
kappa = 6
V0 = invariant(R0,S0,kappa)
reserve = np.arange(.01,100,.01)
supply = np.array([supply(r,kappa, V0) for r in reserve])
price = np.array([spot_price(r,kappa, V0) for r in reserve])
Find the simulation notebook here.
🗝 System Functions
There are two core mechanisms that affect the state of the system: 💰
depositToMint and 🔥
burnToWithdraw. These mechanisms are designed as energy conservation equations based on the constant invariant function of the system’s state-space:
Both mechanisms work by computing the exact output — not a price — of the curve from the state transitions of
supply. The Realized Price is an inferred quantity calculated by comparing of
ΔS. We then show that it is consistent with the Price Function because it approaches P(R) in the limit as the action tends to zero.
onMint (driven by Deposit ΔR):
onWithdraw (driven by Burn of ΔS):
Calculating the limits of the mechanisms and the derivative of the last realized price results in the spot price — or the resulting price which the minting/burning is transacted at.
This proves how the Realized Price, based only on the change in
supply, informs the Spot Price of the transaction as a result of the Price Function derived from the constant invariant function — validating the fact that this system operates independently from the
burnToWithdraw mechanism also includes the activation of an exit tax whenever tokens are withdrawn and hence, burned. The fee is computed given a friction coefficient,
ϕ. When the exit tax is enacted on a burn the
(1-ϕ)ΔR is sent to the agent's address (i.e. individual burning the tokens) and
ϕΔRis sent to the Funding Pool address. This exit tax can be pre-set at initialization of the curve, or can be designed to fluctuate according to other state variables (i.e. how much capital in Funding Pool, how many tokens in supply, etc…)
Incorporating the exit tax into our previous equations, we come to the true realized price for the
burnToWithdraw mechanism when an individual burns tokens is:
and the true return factor post withdraw is:
🔎 Accounting for Slippage
The resulting slippage according to the mechanisms increases in accordance to the transaction fraction (i.e. % of the supply being transacted upon). As the chords of the graph demonstrate, the more DAI that is deposited into the (
depositToMint) into the
reserve, the higher the price gets. The more tokens that are burned to withdraw DAI(
burnToWithdraw), the lower the price gets.
#given V0 and kappa
R = 20
S = supply(R,kappa,V0)
p = spot_price(R,kappa,V0)
#sweep the transaction fraction
TXF = np.arange(.001, 1,.001)
#realized price for withdrawing burning .1% of tokens
withdraw_price2=[withdraw(S*txf, R,S, kappa, V0) for txf in TXF]
#realized price for depositing .1% more Xdai into the reserve
mint_price2=[mint(S*txf, R,S, kappa, V0) for txf in TXF]
As seen in the following model of the system (first image — y-axis = price), even within the “everyday, small transactions”, the slippage is extremely small (i.e.
10⁻²). This ensures stability despite potential speculation (frequent buy/sell for return maximization over small transaction fractions) in the system’s Open Phase. In the logarithmic representation (second image — y-axis = percent error), the consistency of the lines shows the normalization of the spot price and validates the stability assumption.
💡 Concerns and Potential Considerations
In practice, the augmented bonding curve system is a robust and scalable implementation of a token minting model that can be used to continuous fund a pool of capital to be cover expenses of real-world labor. To make this an implementable primitive, there are a couple key concerns/considerations to be explored:
- Front-running: We’ve been actively exploring solutions to front-running and other “buying” manipulation. Billy Rennekamp has done some great analysis into potential solutions including batched bonding curves.
- “Circuit-breakers”: We believe that in the early days of any new, experimental system, there has to be safety mechanisms in place that can automatically turn off system functions if certain conditions such as a destructive ‘pump and dumps’, manipulation of governance processes, or overall system failure. Potential solutions range from global settlements to manual resets (i.e. non-majority requiring multisigs).
- Non-arbitrary parameterization: For our simulations, we set most numbers as arbitrary estimations to test. For implementation and future testing, we recognize the need for economic analysis of how the parameters (θ, ϕ, d₀, p₀) affect the system at scale.
🌳 Use Cases and Implementations
When paired with other primitives & governance modules, augmented bonding curves unlock immense opportunity to redesign the way communities govern and fund organizations, resources, and commons. Members of the system can use their tokens to govern (vote, decide, stake) the allocation of capital from the Funding Pool.
With the augmented bonding curve system, we’re exploring “Conviction Voting” as a social sensor fusion approach to coordinated decision making of capital allocation. Conviction voting explores higher-dimensions of “coin votes” by modeling conviction as function of time and amount. Within the system, conviction is computed as the time weighted sum of token holders’ passive preference, weighted by tokens held. This approach supports the growth of long standing, consistent members, and reducing the negative impacts of token volatility on governance, such as last minute vote switching.
Continuous organizations are finding a niche in the rising number of open-source projects looking for more sustainable ways to support community contribution and maintenance. Many experiments with “community activation” are being explored and conducted at the moment — especially in the crypto space, where public infrastructure is being more and more recognized and treated as a Commons. MolochDAO is building a decentralized organization to fund the development of public infrastructure related to Eth 2.0. Kevin Owocki from Gitcoin is leading the charge with the ERC 1789 proposal for ongoing ecosystem stewardship with inflation funding via transaction fees and block rewards. Band Protocol is building toolkits for token-powered communities.
Augmented bonding curves are another primitive to be used, tested, and implemented within these experiments. The robustness and scalability of the system could have real sustainable impact on how open-source projects & communities are funded and governed.
Augmented bonding curves have the potential to redefine the way we “crowdfund for social good”. By aligning incentives around the support, growth, and maintenance of Commons, we are able to encode new value in community contribution to social impact and regeneration. By building for social commons that are funded and governed by their respective communities we can offset the disservice of our current social systems by redesigning incentive models that drive sustainable and socially beneficial behavior.
Our favorite example are the National Parks of the US — a Commons centrally funded by the national government but with extremely devoted community members. During the government shutdown, the lack of funding causes a depreciation of parks despite having an active and dedicated communities who want to help. When incentive alignment is paired with intrinsic motivation, these active communities are given the means to fight back against centralized forces that are negatively impacting the support and growth of public goods.
The Augmented Bonding Curve system model represents a robust and scalable implementation of a token network that utilizes conservation principles and feedback loops to provide a framework for continuous and community funded organization. This research is an ongoing co-creation effort and collaborative tinkering. We invite feedback, criticisms, questions and concerns — without them we lack the capacity to design real, implementable systems to test, iterate, and build upon.
Please reach out to myself, Griff Green, Michael Zargham, or Jeff Emmett on Twitter for more information or discussion. Big thanks to the Giveth team, our four teams hacking on the Commons Stack at Odyssey Hackathon this weekend, and all the previous research that has informed this design (Billy, Slava, Simon to name a few!)