A safe token sale mechanism

Hi everyone!

I’m going to tell you about a token sale architecture that arguably has some nice safety properties.

It implements a price floor and a price ceiling on the token being sold.

Special thanks to Rick Dudley and Peter Borah for their help on this.

I’m going to assume for the sake of clarity that everything is happening inside ethereum.

Mechanism overview

The mechanism has the following parameters:

1. Token sale price, which I sometimes call the ceiling price
2. Token purchase price, which I sometimes call the floor price

The token sale mechanism parameters can vary over time and are determined by the sale administrator.

The administrator may be a fully automated smart contract, an externally operated account, or can be a smart contract with external participants. We could think of sale administrator as a role — I’m just going to assume that the sale administrator exists at some fixed ethereum address.

The mechanism exposes the following functions:

1. move_ceiling, and move_floor callable only by the sale administrator.
2. purchase_tokens, callable by the anyone.
3. sell_tokens, callable by the anyone.
4. The ERC20 token interface, callable by anyone.

The sale mechanisms will sell any number of tokens at the sale price. By doing this, it will accumulate a balance. It will use its balance to buy any number of tokens at the purchase price.

Purchasing tokens from the mechanism will increases the caller’s ERC20 balance, and selling tokens to the mechanism will decreases the caller’s ERC20 balance.

The sale never ends. This means we can bound the price of the token above. It also means that the total supply of tokens is not necessarily bounded, and is almost certainly not fixed.

A constant ceiling removes all reasonable expectation of return that token purchasers may otherwise have. Any low-enough ceiling can prevent “pumps-and-dumps” from pumping.

The buy-back never ends. This means we can bound the price of the token below.

This protects token purchasers from downside risk. This can isolate token purchasers from loss due to a token purchase. Any high-enough floor can prevent “pump-and-dumps” from dumping.

I think this will be safer than the status quo we see in token sales today.

This next section gives detail about why the purchase price is a price floor and why the sale price is a price ceiling. Skip if you don’t want to get bored. The section following this one is about how the beneficiaries of the sale benefit from the sale.

Explaining the price ceiling and price floor

The mechanism’s token sale price is an effective price ceiling on the market for tokens.

If there are bids on the open market for prices above the mechanism’s token sale price, traders can execute the following arbitrage strategy:

1. buy tokens from the safe token sale mechanism
2. sell tokens on the market
3. repeat until these are no more bids above the token sale price

This is why I refer to the token sale price as the ceiling price.

Similarly, the mechanism’s token purchase price is an effective price floor on the market for tokens.

If there are offers on the open market for prices below the mechanism’s token purchase price, traders can execute the following arbitrage strategy:

1. buy tokens on the market
2. sell purchased tokens to the SafeTokenSale mechanism
3. repeat until there are no more asks below the purchase price

This is why I refer to the token purchase price as the floor price.

The mechanism allows the sale administrator to place a floor and ceiling on the price of a token, taming otherwise volatile markets.

Note that there are the following two edge cases:

1. The sale administrator sets floor = ceiling forever, and the token purchasers are never exposed to any risk or any opportunity for returns.
2. The sale administrator sets floor = 0, ceiling = infinity, perhaps after some time of having ceiling at a fixed or growing price.

It is worth noting that the first precisely corresponds to a two-way peg of the type originally proposed for Bitcoin’s pegged sidechains, and that the second precisely corresponds to the most common finite-quantity sale models in today’s token crowd sale ecosystem.

Note also that the sale administrator can’t raise the floor price if doing so would make it unable to purchase all of the tokens at the floor price.

I left this part about how the beneficiaries of the sale get paid for later because I wanted to start by giving you a feeling for how and why this mechanism is safer for token purchasers than token sale architectures that are common today. I actually completely left it out of the “design overview” section, I hope you didn’t mind :)

How the beneficiaries get paid

Naively, we would propose that any of the funds in the sale mechanisms which are not allocated for buying back (all of the) tokens at the floor price can be withdrawn by the beneficiary at any time.

However, there is potentially a big problem with this. The beneficiary of the sale could effectively buy tokens at the floor price by following the following two steps:

1. Purchase tokens from the sale mechanism at sale_price
2. Receive sale_price - purchase_price from the token sale mechanism as beneficiary, for every token purchased.

In the end, the beneficiary will have spent sale_price - (sale_price -purchase_price) = purchase_price for every token purchased. This will allow the sale beneficiary to push the price of the tokens on the market to the floor price by following an arbitrage strategy similar to the one described in the previous section.

We will give the responsibility of allocating funds to beneficiaries to the sale administrator, pushing the responsibility of preventing excessive “double-dipping” outside of the safe token sale protocol.

Let us therefore give a revised list of methods exposed by the mechanism:

1. move_ceiling, and move_floor callable only by the sale administrator.
2. purchase_tokens, callable by the anyone.
3. sell_tokens, callable by the anyone.
4. The ERC20 token interface, callable by anyone.
5. allocate_funds_to_beneficiary, callable only by the sale administrator
6. claim_revenue, callable only by anyone, throws an exception if the requested funds have not been allocated to the caller by the sale admin.

Note that allocate_funds_to_beneficiary fails if allocating those funds would mean that the sale mechanism is no longer able to buy back all tokens at the floor price if those funds were to be withdrawn. Note that similarly move_floor fails if the administrator tries to push the floor too low.

A quick note on how investors might get paid

Some of you may be concerned that the safe token sale mechanism removes at least some expectation of return from investors.

Apple investors do not purchase products from Apple in expectation that their price will appreciate, but they purchase shares of Apple and receive revenues from Apple’s profit, which Apple has because people buy their products because their products are useful.

The analogous story here is that investors should be paid out of funds allocated to beneficiaries (after beneficiaires pay expenses) rather than by expecting the token sold by the mechanism to appreciate.

At least this is my philosophy for how to use the safe token sale mechanism. You might want to let the floor price fall to allow more funds to be allocated to the investors through the beneficiary, or to allow the ceiling price to rise to give token purchasers more upside potential.

The mechanism can be parametrized — but please be safe!

Conclusion

The “safe token sale mechanism” allows us to trade off between the interest of token purchasers and beneficiaries, while also being able to prevent (or at least effectively mitigate) pump-and-dumps. It provides flexibility to how the investors in an enterprise who wants to sell tokens can get paid.

I hope that it can lead to a radical departure from the philosophy of token sales today, by giving up on the “fixed known supply” model in favour of the “this is a product that is sold in perpetuity to consumers who find it useful” model. It is possible — we do have the technology. But I’m just being crazy :)

Really hope you like it!