An Intro to Truebit’s Interactive Coin Offering
There are many flavors of token sales: capped sales, uncapped sales, dutch auctions (see Gnosis), etc. Most sales are either simple capped or uncapped sales where tokens are sold at a fixed rate. These sales, however, present a participation problem:
- In capped sales, all the tokens can be sold within minutes. Buyers are unable to observe the success of the sale before contributing their money for fear of missing out.
- In an uncapped sale, the final percent market share that an investor will actually end up owning is also unclear. Ten percent of the tokens now could be a fraction of a percent later (especially if large whales come in and dominate the token supply).
The two issues with current token sales suggest that a better alternative is necessary. An interactive coin offering, first proposed by Jason Teutsch and Vitalik Buterin, addresses the stated concerns and proposes the theorem that no crowdsale satisfies both:
- A fixed amount of currency at the time of purchase buys at least a fixed fraction of the tokens
- Buyers can participate with as much capital as they like.
A simple proof is as follows: if one unit of the native token can buy p percent of the tokens, then the sale valuation cannot exceed 1/p. With a fixed ratio, statement 2 is violated — without one, statement 1 is violated. The interactive coin offering (iico) enables buyers to vary the purchased quantity of tokens at different valuations, therefore satisfying buyers’ desired cost to percent-ownership ratio.
The iico is an interactive fully on-chain process and differentiates itself from traditional crowdsales largely because it allows buyers to withdraw their bids at any time before the end of the sale. The sale provides sufficient time for buyers to react to the bids of others (withdrawals or new bids) and push the market towards an equilibrium sale valuation. Many other forms of token sale require time-bound actions to be able to partake. Traditional capped/un-capped sales can end very fast as discussed above. Even dutch auctions require buyers to be active and make timely bids.
The Protocol
A bid in an iico has three parameters: the contribution amount, a maximum cap and a personal minimum. The maximum cap is the highest valuation the buyer is willing to accept at this contribution amount. If the sale valuation goes above the maximum cap the bid will be made invalid and is removed from the sale. This enables buyers to have greater control over their percent-ownership of the total market value of the sale. The personal minimum is similar: the bid is only active if the sale’s valuation exceeds the personal minimum. Consequently buyers who don’t want to take part in a low values sale can set a high personal minimum so that their bid will automatically be included if the sale becomes successful.
The sale progresses through three periods. The first and second periods are separated by a withdrawal lock deadline. Before the deadline, buyers can withdraw previous bids at any time and remove them from the sale. After the deadline, the protocol automatically withdraws bids whose caps have been exceeded. Finally, the last stage is when the sale is over and buyers can redeem their tokens.
During each phase the protocol progresses in rounds (can be multiple blocks). In each round the protocol progresses in block epochs in which buyers can submit bids or withdraw old bids (only before the withdrawal lock deadline). If the withdrawal lock deadline has passed, all bids are checked for validity (i.e. their caps are met), and invalid bids are automatically withdrawn from the sale.
One problem that arises from this protocol is that at the very start, the iico will be a completely illiquid market that will discourage early participation. To counteract buyers’ initial resistance to partake in the market, buyers will earn a bonus on their bid based on a decreasing bonus function. The bonus begins at 20% at the start of the sale, reaches 10% at the withdrawal lock and moves to 0% by the time the sale ends. Even if buyers withdraw bids before the sale ends, some portion of their contribution bonus will remain in the sale, ultimately increasing the token value.
The protocol periods and steps mentioned above are a high level look at what features an interactive coin offering provides. For a more detailed explanation of the protocol and more concrete reasoning about its benefits, refer to the original paper.
Implementation
Next, I’ll describe the implementation decisions made and how they differ from the proposed protocol in the paper.
The most significant change is the removal of the automatic withdrawals that happen at the end of each round. Automatic withdrawals, which are preferred, turn out to be difficult to efficiently implement in a smart contract without costing buyers unbounded gas penalties. Remember from above that automatic withdrawals ensure that all bids whose specified caps are violated are removed from the sale at the end of every round. Functionally, this means that in every round the contract would need to iterate through all active bids (perhaps thousands) to check their caps. This functionality would have to be put on the back of some user transactions, and offloading that heavy gas cost to a user is not a practical solution.
Therefore, we opted for a more interactive approach where users have the ability to “poke” bids out of the sale if their caps have been violated. If a bid X has it’s cap violated by the sale valuation, a user can “poke” it and make it invalid. Poking behavior is incentivized through a small reward (supplied by the bidder) that is larger than the gas consumed by the poke. Of course a buyer can choose not to set any caps on their bid if they always want to be included in the sale. In that case, they don’t need to worry about incentivizing pokes on their bids.
Users can also poke in bids whose personal minimums have been satisfied. This enables buyers to make a bid early, and only have their bid included if the sale is successful (i.e. has reached some chosen threshold). There are also some special scenarios that poke-ins are meant to resolve. Suppose three bids, each with a contribution of 30 ETH and a personal minimum of 90 ETH are placed. There are currently no bids in the sale and none of the three will be active on submission due to their personal minimum. Clearly, if all three were included in the sale, their personal minimums would be satisfied. Therefore, the poke in takes a set of bids as input and tries to insert them all into the sale together, resolving the scenario above.
Our inclusion of personal minimums is a departure from previous IICO implementations. We further distinguish ourselves by substituting the automatic withdrawals of the protocol with the more interactive “poking” process that gives spectators a opportunity to take part in the sale without contributing and earn a small reward along the way.
There have been two other projects which have implemented an IICO as their token sale protocol: Modular and Kleros.
Kleros’ IICO eliminates personal minimums as part of the bid. They only enforce maximum caps, not personal minimums. As the sale progresses, buyers’ bids are placed into a linked list. At the end of the sale, once no more bids are accepted, the Kleros team moves the pointer across the list and processes all the bids sequentially, removing ones whose maximum caps have been violated by the current sale valuation. Although the sale ends up in the correct state, this does make it difficult for participants to know the true state of the sale while it is still active.
The modular IICO compiles bids into a linked list of buckets. Each bucket represents some value X Ether. All bids in the bucket are bids whose maximum caps are set at X Ether. Unlike Kleros, the Modular IICO updates the linked list in real time, resembling the automatic withdrawal procedure.
The key point in both of these other IICOs is that they involved some sort of automatic withdrawal (whether in real time or at the end of the sale). In either case the gas expended in doing so can be supplanted by an interactive poking scheme. Users incentivized to poke out bids as they become invalid will respond quickly so as to gain the most reward. Therefore, we expect users to show up to poke-in very frequently and poke out bids in almost real-time. In fact, this process is akin to mining on a blockchain so we expect to, and encourage, user to create programs that watch the contract and try to poke out bids before everyone else.
It’s important to vary your sources, so below is a list of additional reading material that might be relevant to readers of this post:
Vitalik Buterin’s “Analyzing token sale models.”
EDITOR’S NOTE. Sometimes the current valuation may exceed the max cap of a particular bid by less the bid’s value. Poking out such a bid removes only a fraction of the bid’s value from the sale — just enough so that the current valuation becomes equal to the bid’s max cap. In order to ensure that sufficient reward persists to cover subsequent pokes on the same bid, the Buyer includes a reward deposit proportional to his bid value, and the Poker receives reward according to the proportion that he poked out. At the end of the sale, the buyer may reclaim any unspent portion of his deposit. Assuming that rational pokers always show up promptly to claim rewards for poking bids, this “partial poking” method enforces a monotonically increasing sale valuation. Monotonicity prevents “pushout attacks” from whales as described in Section 5.2 of the whitepaper and supports an intuitive interface in which each bid gets poked out at most once.
