How Much Do I Pay?
Evolution of ICOs: Part II
During 2017 and continuing today, we have seen very many ICOs competing for investors’ attention (and money). In this part of the mini-series on evolution of ICOs, I will look at the pricing mechanism that is used to determine the value of a token. Mostly, when an ICO takes place, the tokens the value is something that is not very clear—after all it is still unclear whether the app will ever see much usage or whether the token provides any customer value. During the past several pricing mechanims have been tried. I will look at them in this piece.
The series is divided into three parts:
- The Token: What is it that I am actually buying?
- The Price (this piece): How much am I going to pay for it?
- The Release: Once I have bought a token, how (and when) can I sell it again?
The Price: How Much Do I Pay?
When deciding on whether to participate in an ICO the price per token and the mechanism to define that price is somewhat important. After all, a potential investor wants to know how many tokens he will receive for any given investment.
The Past: Fixed Price
The early ICOs usually just set a fixed price per token and then started the sale. This means that an investor knows exactly how many tokens he will receive for a given amount of money. Thus, the mechanism is very transparent to a participant. It does, however, suffer a drawback: The creators of the token have to determine a reasonable price for the token. Usually an ICO is scheduled before a real product has been developed; price determination is then pretty much an educated guess with many assumptions. A token creator has to estimate the market for the token and its potential usage and then come up with a price tag for that token.
The Present: Reverse Dutch Auctions
If a fair price is unknown to both the investor and the seller, an auction is a good approach to determine a price. The default auction mechanism with increasing bids until there are no more bids is a good example of that: Every bidder ideally determines an acceptable price (the so called reservation price) and then bids until the bids surpass the reservation price and then leaves the auction. If the auction does not surpass the reservation price, the bidder wins the auction and receives the good. The traditional design is useful for auctions with just one item. ICOs, however, usually want to sell as many tokens as possible to the bidders. It is obviously unpractical to have as many auctions as there are tokens up for sale: Reverse Dutch Auctions are a variant of that is particularly suited for the sale of fungible (ie. indistinguishable) goods. They got their name from the Dutch flower market where they are still in use today.
In a Dutch auction a seller wants to sell a quantitiy of goods. Instead of increasing bids, the mechanism relies on decreasing bids: The seller starts with an artificially high price and then continuously lowers the asking price. As soon as a bidder decides that the price is acceptable, she bids for that price and gets the goods. The auction continues until all goods are sold. The design allows for the quick sale of many goods. However, it does rely on a number of prerequisites:
- The auction must start at an artificially high price that is much higher than any reasonable price would be. If the price starts around the acceptable price range already, there is the risk of selling all items within the first couple of rounds. The intended outcome of determining a fair price with the auction is then thwarted.
- A Dutch auction is particularly sensitive to the timing of a bid. Because it is not an interactive game that extends with every bid, any bid will directly lead to a sale. If a Dutch auction is to be used, it is important that every potential bidder has the same chance of submitting a bit. The traditional Dutch flower market achieves this condition by _co-locating_ every potential bidder. Only people that are physically present at the auction can participate.
The Future: Vickrey Auctions
To alleviate the winner’s curse, so called Vickrey auctions come to the rescue: Their protocol is a sealed bid, second price auction, meaning that each bidder submits a sealed bid in phase 1 of the auction. Then, in phase 2, all bids are revealed and ordered. The highest bid wins the auction, but the bidder then pays the second highest price. This design preserves the winner determination of the traditional auction so that the highest bidder is the one that actually wins the auction, but it alleviats the risk of the winner’s curse. Because the winner only pays the second highest price, the price is effectively based on the value determination of the second highest bidder and the winner does not overbid the price by any arbitrary amount.
In Vickrey auctions there is no better strategy than to bid one’s true reservation price. This property is very desirable in auctions because it reduces the possiblity to be cheated by bid manipulation. Standard Vickrey auctions are useful for auctions on one item (just like traditional auctions) and thus not directly useful for ICOs. However, there is an extension of the Vickrey auction mechanism, the so called Vickrey-Clarkes-Groove auction that allows for auctions on many fungible items like tokens.
There is a drawback with Vickrey auctions when used for ICOs. The mechanism relies on sealed bids in the first phase. However, on the Ethereum public chain any transaction and a smart contract’s content is public and can be inspected by anyone. Thus, any submitted bid could be inspected by potential investors and they could adjust their bid. The most used strategy to work with bids that have to be submitted, but remain hidden in phase 1 is a publish/reveal scheme: Instead of submitting the bids in plain text, each bidder submits a bid’s hash. After all bids have been collected, the bidders reveal their bids by submitting them in plain text. A smart contract can then compare the hash of the plain text bid with the hash that was submitted in the earlier transaction. If both match, the smart contract knows that the plain text bid is the one that the bidder had set initially. The potential problem with this mechanism is the bidder that reveals her bid as the last participant: She already knows all other bids and could then decide not to reveal her bid. This could substantially alter the auction’s result, which is undesirable.
The risk of the last bidder not revealing her bid can be solved by placing economic penalities on non-revealing. A bidder would loose its deposit if she does not reveal a placed bid. However, this complicates the implementation of an already complicated mechanism. So far, I have not seen a Vickrey auction being used for an ICO, but I expect that to potentially happen in the future.
While the pricing mechanisms have developed quite a bit from the early fixed price schemes, there is still room for development, in particular to prevent ICOs to end after minimal amounts of time.
In part III of this mini series, I will talk about the release of the funds after an ICO has ended.
If you liked this part or you have a suggestion and/or remark, feel free to comment on the piece. As the author, I really appreciate any feedback. Also, if you liked it, please clap for it. It shows your appreciation and helps others find it.
