Bonding Surfaces & Balancer Protocol
After well over a year of work, Balancer Labs has released the Balancer Protocol Whitepaper. We have restricted it on purpose to the core mathematical framework and main proofs for conciseness and readability.
Balancer is a non-custodial portfolio manager, liquidity provider, and price sensor. We see Balancer Protocol as a potentially powerful primitive in the Ethereum ecosystem, especially in DeFi. A building block that will empower more complex use cases on top of it.
Among the many ideas the team believes can be built on top of Balancer, we will describe that of bonding surfaces: a new paradigm that expands on the great work done by Simon de la Rouviere and many others on bonding curves. Before we start, it’s useful to quickly revisit the concept of bonding curves.
Bonding Curves Recap
In case you are not familiar with bonding curves, I suggest reading this excellent article on curation markets and bonding curves by Simon. On a very basic level, bonding curves allow for the minting and burning of a new token, say #projectToken — which can represent ownership shares of a new project or DAO — in exchange for a reserve token. The price of minting new #projectTokens usually goes up with an increasing supply so that early adopters or investors in the project are rewarded for the risk they took.
Bonding curves have given rise to many interesting concepts and applications such as Continuous Organizations — h/t to Thibauld — and Augmented Bonding Curves — h/t to Michael Zargham and Abbey Titcomb.
Balancer Pools and Bonding Surfaces
Imagine you wanted to launch a new project or DAO that accepted more than one token in return for #projectTokens — MolochDAO could become a real example. Say your organization needs the reserve value to be 60% in DAI to hedge against crypto volatility, 25% in ETH because it’s the most liquid and trustless asset in Ethereum and 15% in another ERC20 that is closely related to your project. How would you do it?
Enter Balancer Protocol and its Balancer pools. A Balancer pool is a contract that can hold several different tokens, each of which with its own defined share of the total value in the pool — the token weight. Thanks to carefully designed mathematical properties and the alignment of incentives with arbitrageurs, Balancer pools will always hold the same ratio of value in each token — even if their relative prices change. This is why we consider Balancer to be a self-balancing portfolio management tool.
While bonding curves usually have only one reserve token, a Balancer pool can have two or more underlying tokens. In a bonding curve, a given supply of #projectTokens maps exactly to one, and only one, amount of reserve tokens (considering they do not have different buy and sell functions):
You can think of Balancer pool tokens (which represent partial ownership of a pool) as the equivalent of #projectTokens in a bonding curve. The underlying tokens in a Balancer pool — DAI, ETH and ERC20 in the example above — are the equivalent to reserve tokens in a bonding curve.
If you want to mint pool tokens, you can do so by depositing all of the underlying tokens of a pool proportionally to their weights. You can also deposit only one of the reserve tokens, if you prefer. By depositing only one token you change all prices in the pool relative to that token, possibly creating an arbitrage opportunity for other traders to profit on your back. When deposits are orders of magnitude smaller than the liquidity of the pool, that effect goes almost unnoticed. The details on the formulas that define how freshly minted pool tokens are calculated are described in our whitepaper.
The bonding surface below shows how the supply of #projectTokens changes with the reserve balances of #reserveTokenA (rTA) and #reserveTokenB (rTB) for a simple Balancer pool with only two tokens and equal weights of 50% each. All Uniswap pools have these characteristics, however each pool always has ETH as one of the two reserve tokens along with another ERC20. There is an incredibly useful animation by Markus Koch on how Uniswap pools can be seen as dynamic bonding curves.
Notice that, given an outstanding supply of, for example, 5 #projectTokens, any of the combinations of rTA and rTB balances that lie on projection of the blue curve is possible.
The equation used to calculate the supply of #projectTokens illustrated by the surface above is directly derived from Balancer’s value function. In this case it is the value function divided by a constant of 100:
Notice that, if there are for example 500 rTA and 500 rTB in the pool, the outstanding supply of pool tokens (PT) is 5 — as shown in the chart above by the green cross.
In the end, the external market decides what is the right combination of balances of reserve tokens for a given outstanding supply of pool tokens. This is because all Balancer pools allow anyone to trade between any two tokens inside the pool, with prices determined by their weights and current balances. That is why Balancer protocol is a liquidity provider: the aggregate liquidity of all its pools is accessible for any trader to tap into.
Another example of bonding surface for a Balancer pool with rTA with weight 85% and rTB with weight 15% is shown below. In this case, 85% of the total reserve value would be held in rTA and 15% in rTB. This could be for example a more conservative project that is minting its #projectTokens keeping 85% of the reserve in DAI and 15% in ETH.
It is harder to visualize n-dimensional bonding surfaces with Balancer pools that contain 3 or more tokens, however the mathematical definition is still valid and very useful.
Rewarding early contributors
Conventional bonding curves have an increasing price per #projectToken as the supply of #projectTokens increases. This is equivalent to saying that, for the same amount of reserve tokens contributed to the project, early contributors would get a higher amount of #projectTokens than someone who contributed later. Conversely, #projectToken holders that redeem first have a better price than those who redeem afterwards.
Like with Uniswap, Balancer Pools do not have that design by default: liquidity providers of Balancer pools get the same amount of pool tokens regardless of whether they deposit their reserve tokens early or late. This has been a design decision to avoid any unwanted risks for liquidity providers. It is however easy to implement the logic of an increasing price per pool tokens on top of the existing Balancer protocol (details on the implementation can be the subject of a future post). One could add an exponent lower than 1 to the entire formula shown above, for example 0.5.
In that case, early liquidity providers would have a financial benefit over late ones. You can notice that visually in the chart below as the gaps between level curves — which represent incremental increases of #projectTokens supply — increase as the supply increases. In other words, late liquidity providers will need to deposit more reserve tokens to get one unit of #projectToken.
Conclusion
This short article aimed at illustrating a specific example of how our team believes Balancer protocol can become a building block in the Ethereum ecosystem. Specifically, I showed an example where Balancer pools could be used as bonding surfaces. These dictate the issuance of new tokens that represent ownership in a project or DAO through the deposit of any desired basket of reserve tokens that make most sense for the project.
More generally, Balancer pools are permissionless non-custodial smart contracts through which any liquidity provider can earn passive revenues from trading fees in exchange for providing liquidity to Balancer Protocol. We are excited to see the various different ideas and new applications that will be spawned with Balancer. If you are interested in knowing more or contributing, please get in touch. We will keep you updated on the upcoming launch of the first release of Balancer protocol.
I would like to thank Simon de la Rouviere and FollowTheChain for providing me the motivation to write this article. Thanks also Trent McConaghy, Zargham, Markus Koch and Thibauld for providing invaluable feedback and helping make this article more interesting and easier to understand.
