Suppose, we would like to issue a token with an initial supply of dev + inv to be pre-allocated to developers and investors, respectively. Investors obtain their tokens at a pre-sale price p after which the price is free-floating, subject to market forces of available supply and demand.
- If the sale of inv tokens is unsuccessful, investors are refunded in full.
- If the initial sale is successful, most of the collected funds must be available for developers, without them having to sell their tokens.
- The rest is used for funding the bonding curve contracts market making.
This is a fairly standard arrangement, similar to how Ethereum got funded.
For a constant ratio n of market capitalization to liquidity tied up for market making, a polynomial price function f(x) = cxⁿ⁻¹ should be used where c is a constant depending on the above parameters and x is the total number of tokens issued by the contract.
However, in the initial sale phase, while x < inv, a different, constant function, f(x) = p is used and no other tokens are allowed to exist. When the sale concludes successfully (i.e. x = inv), dev tokens are allocated to developers and the final price function is activated. At this point the price should still be p to prevent discontinuities. Thus, we have c(inv + dev)ⁿ⁻¹ = p, which yields c = p / (inv + dev)ⁿ⁻¹.
The total amount that can be withdrawn from the bonding curve contract is ∫(0,inv + dev) c * xⁿ⁻¹ dx = cxⁿ/n = p(inv + dev)/n but the balance of the contract is p * inv. Thus, without causing any discontinuity, developers can withdraw the difference: p(inv - (inv + dev)/n) for funding development.
The parameter n is the leverage ratio of the bonding curve contract. The benefits of increasing n are obvious, but there are also risks associated with it. The higher the leverage ratio, the cheaper it is to move the price of the token downwards by dumping it. Thus, n should be chosen in accordance to expectations about immediate sales of developer tokens.
If we follow Ethereum's playbook, part of dev tokens will be kept by the Foundation, while the rest will be made available to individual developers at pre-sale price p. Thus, the Foundation is motivated to maintain the value of the token by doing a good job of developing the application for which it is used, as a large part of its assets are in this token. Individual developers and investors, however, may choose to cash out early, depending on their trust in the continued success of the project reflected in the appreciation of its utility token, though both will incur a loss, if they sell below the price of p, i.e. more than what users or speculators are willing to buy. The choice of n limits the amount of damage an individual seller can incur.
Example: If the largest individual holder holds 20% of the tokens. It means that q=5. If they sell it all, the price will go down to 0.8ⁿ⁻¹. If we wish for them not to be able to crash the price to half, we should keep n ≤ 4, since 0.8⁴⁻¹=0.512, barely above 0.5.
The attached bc file has the formulae implemented in integer arithmetics (i.e. directly applicable to EVM-based smart
contracts) for the primitive function prf(x) of bonding curve of the 31st order (n=31). While these calculations
assume that the scaling factor scl is the same for both the backing asset (DAI in the example) and the issued token
(called BZZ), in an actual implementation they can differ.
Since for each transaction, it is the primitive function of the bonding curve that needs to be evaluated, the bonding curve needs to be selected in such a way that this calculation can be implemented efficiently in EVM. If the degree of the primitive function is a power of two, the dominant component in the polynomial can be calculated by subsequent squarings. In order to keep the scale of the function values manageable, it is worth inserting scaling operations into this. Finally, we must also maintain strict monotonity for the primitive function, as otherwise the price of certain tokens will be zero. The least intrusive way to achieve this is to add an x term to the primitive function that is completely dominated by the higher-order term for most values, yet guarantees that neighboring values of the primitive function differ by at least one.
The particular choice of reserve ratio of 31 is motivated by a similar ratio of market capitalization to orderbook value
in well-functioning markets. Numerical experiments with the attached bc script confirmed the desirable properties of
this selection by resulting in reasonable outcomes for various regular and extreme scenarios.
As a safety measure against numeric overflows and to address investor concerns about a possibly unlimited token supply, it is worth adding a hard upper limit for the number of tokens the contract can emit. In numerical experiments, I used twice the initial amount. In practice, this limit will probably not be reached, as it would correspond to a market capitalization of about 4 billion times the original, but even in this unlikely case, all this limit does is that it forces market participants to trade through secondary markets, as the consensus price moves beyond this hard limit. With a market capitalization of that magnitude, it will surely not be a problem to find exchanges willing to list the token.
In order to ensure medium-term developer commitment, is is advisable to disburse the BZZ tokens set pre-mined for financing development in a gradual fashion, perhaps even throttled by a smart contract. This way, the developing organization can credibly commit to building the system and upholding the value of the token.
In particular, following Ethereum's playbook, invididual developers (subcontractors) can ask part or all of their compensation in the token and have an option to purchase at the pre-sale price. The developing organization (i.e. Swarm Foundation) should also be barred from dumping their part of the premined on the market over a short time.
Investors participating in the presale do not need such restrictions, as they have no incentive to do that, given that they could only sell at a loss.