Virtual Supply and Virtual Balance

Within the original design of the Augmented Bonding Curve, tucked deep inside the complex matrix of code and algorithms lies the parameters Virtual Supply and Virtual Balance. These two whimsical settings can be adjusted to create inflated or deflated projections of the Token Supply or Reserve Balance. These “projections” are used in place of their real values to shape the bonding curve, meaning the actual Reserve Balance or Token Supply could be different values than what the Augmented Bonding Curve (ABC) is using.

These two parameters are useful if the Commons implements a mechanism or strategy that partitions, manipulates or withdraws from the Reserve Balance and/or Token Supply but doesn’t want it to impact the calculations of the Augmented Bonding Curve. Having a Virtual Supply or Balance is useful when designing mechanics outside of the normal functions of the ABC.

What is Virtual Supply?

Virtual Supply is the inflated or deflated projection of the Token Supply currently attributed to the Augmented Bonding Curve.

What is Virtual Balance?

Virtual Balance is the inflated or deflated projection of the Reserve Balance currently in the Augmented Bonding Curve.

Changing the Parameters

Virtual Supply and Virtual Balance parameter values are the increase or decrease relative to the actual Token Supply or Reserve Balance, respectively. If for example the Token Supply is 108 TEC and you want to add 1000 TEC tokens to the ABC’s calculation you would set the Virtual Balance as 108 + 1000. Conversely, to remove tokens from the ABC’s calculation you would input 108 - 1000.

If there is 1,000,000 wxDAI currently in the Reserve Balance to increase the value used to calculate the bonding curve by 1000 wxDAI without depositing more wxDAI you would set the Virtual Balance to 1,000,000 + 1000. To remove the same amount you would set it to 1,000,000 - 1000.

Why are these Useful?

These parameters have very specific use cases and should only be touched by Bonding Curve Professionals. Some examples use cases for Virtual Supply & Balance would be:

Scenario #1

A Token Engineer or Commons wants to earmark portions of the Reserve Balance for future savings or investment strategies. Meaning they would make an under inflated projection of the Reserve Balance/Token Supply since there are more funds in the Curve than is desired to be calculated by the ABC.

Scenario #2

If the Commons wanted to stream funds out of the Augmented Bonding Curve into another pool a Token Engineer would want to increase the Virtual Balance since there are less funds in the Curve than is desired to be calculated by the ABC.

Scenario #3

The Commons wants to grant additional governance rights to a member by minting TEC tokens for them and putting the tokens into a vesting contract, rendering them non-transferrable but still useable for voting. We wouldn’t want these minted tokens to affect the ABC so we would deduct the amount of TEC minted from its calculations by decreasing the Virtual Supply.

*Commons Configuration Dashboard

In the commons configuration dashboard changing these parameters will mean that the Virtual Balance and/or Virtual Supply are used in place of the initial Token Supply or Reserve Balance at the moment of the Commons Upgrade. This means that by changing these you drastically impact the initialization of the ABC.

Suggested Range

It is suggested to leave these parameters alone. Seriously, don’t mess with these. Change these only if you’re a pro and have designed a use case that requires changing these values.

Related Inputs:

Reserve Ratio
Token Supply
Reserve Balance


So, could you imagine a scenario where we inflated the projected supply of tokens in order to provide for the initial liquidity on secondary markets (LP tokens owned by the DAO)? These tokens would bootstrap liquidity during times of volatility, when fickle LP’s enter and exit on much shorter time horizons. If we can increase the amount of virtual supply, we will effectively lower the Reserve Ratio, decreasing sensitivity in price movement on the curve while simultaneously earmarking funds to provide for LP, and to reward LP holders. Since a large portion of these funds are owned by the DAO, we can prolong LP rewards (because the DAO will be earning the majority of those rewards) and also incentivizing individual LP providers for longer time periods until enough liquidity can reliably support the secondary market.

I’m not sure if what I just said is anywhere near accurate or feasible. Just “off-the-cuff” brainstorming the implementation of our transferability parameter and setting up the tokens initial liquidity. Do you think this is a possible use-case for this parameter? I just think that these parameters have a ton of potential to develop new mechanisms for the TEC economy.