The first 5 days of the EOS token sale will be unfair. Here's how to fix it.

EDIT: This post is for informational/educational purposes; my proposal is apparently not implementable on Ethereum due to the need to sort the list of bids.

Ever since the EOS token sale was announced yesterday, there has been much hand-wringing and off-the-cuff analysis. I wrote an article with a few of my first thoughts, and I haven't been able to get the sale out of my head since.

In my article, I wrote the following:

The fact that the optimal bidding strategy is not obvious means that whoever gets the game theory right is going to make a killing off this crowdsale. You should ask the team why they think a weird non-traditional auction is fair.

In this article, I'll argue that the distribution model in the first 5 days is, in fact, unfair.

Let's say Alice is a hyper-bull on EOS, and thinks it's going to hit $10,000 someday. As far as she's concerned, any ICO price is a good price.

On the other hand, Bob believes the long-term potential is wonderful and could easily see $100 per token someday, but he's confident that it's going to take a while to get there. He suspects the crypto bubble will probably burst in the next couple months as the ICO calendar thins out, and thinks EOS could easily fall to $0.10 during the crash before the chain is actually launched. This leads him to say that $1 per token is the most he'd want to pay in the token sale. Any higher price than that and he'll wait for greener pastures down the line.

So Alice has no maximum price, but Bob does: Bob doesn't want to pay more than $1 per token in the first 5-day period of the sale.

What are Alice and Bob's optimal contribution strategies?

For Alice, it's easy. She just contributes ETH. Since she has no maximum price, she doesn't care how much ETH gets pushed into the sale. She'll take whatever she can get at any price.

For Bob, the optimal strategy is completely non-obvious. Let's see why. The way the auction works, everybody who contributes in the first 5 days gets the same price. If the total amount of ETH contributed in that time is total_ETH_contributed, that price is simply

total_ETH_contributed / 200,000,000.

The more who contribute, the higher that price. But Bob has a maximum price that he's willing to contribute for! How can he be sure he doesn't pay more than his maximum price?

Bob cannot be sure that he'll pay less than his maximum price.

It's mathematically impossible for him to be sure. The only way he'd know for sure is if he could somehow wait until after everybody else has bid, check to make sure that the implied price is below his max, and then decide whether to contribute. But Bob's not special - and there are probably a lot of Bobs out there with a max price in mind who don't want to be caught with their pants down when all the other Bob's contribute right in the last few minutes of the sale.

The only way Bob can protect himself is to contribute less than he'd like to. So a side-effect of this auction format is that people should self-limit their contributions to mitigate the pricing uncertainty. I don't know how much FOMO will counteract this.

The auction format is unfair to Bob.

If you're a voluntaryist/anarchist/believer in the non-aggression principle, pay close attention to this: Subsequent bidders can force Bob to pay more than he's willing to pay.

How do we fix this?

Fortunately, there's an easy fix. We give Bob the ability to set a maximum price. It's so easy it hurts. We're running the token sale on Ethereum, the smart contract platform, so this should actually be possible to do.

In my proposed format (for those who care, it's a Simulated Descending Price Auction), people submit a bid as a pair of two numbers:

1. Amount of ETH they're contributing
2. Maximum ETH/EOS price they're willing to pay

At the end of the 5-day period, we sort all the bids in descending order of max price. We iterate through the bids, calculate an implied price based on the total ETH seen so far (divided by EOS to be minted), and increment the iteration whenever the implied price is less than the most-recently-seen maximum price. If the implied price is ever greater than the current maximum price bid, the iteration terminates and all orders seen so far are filled at the implied price. Everybody receives a price no greater than their maximum price, and everybody who entered a max price less than the final price is happy their order didn't get filled.

The algorithm terminates in finite time with a deterministic outcome because the list of bids is finite, the implied price is an increasing sequence, and the maximum prices are sorted descending.

Why is this important?

It's important because now Bob has total control over protecting his maximum price. Now, nobody can force him to pay a higher price than he wanted to. Now, he has no uncertainty about what his optimal bidding strategy should be. Now, he doesn't have to stay up till 3 AM when the 5-day period ends in his time zone to make sure that he's not paying too much.

Nothing has changed for our hyper-bull Alice! She can just enter an obscene max price, or we can design the smart contract so that she can enter a "no-max" option where she is guaranteed to get part of the distribution.

Caveat: implementability

I don't know Solidity, and it's possible that sorting the list of bids could be annoying/challenging/costly. Need dev comments on that one.