Why is it a game?

There have been a lot of proposals of various mechanisms for better token sales, which either include just an idea written as prose, or some code. While this is great, we would only know if these solutions work after they have been tested in “real life”. The token game will not be just and attempt to throw an idea into the wild, or just a piece of code for others to review in their free time. There will be a contract deployed on the Ethereum Main net, with the “Prize Pot” (not as a promise, but as a smart contract) for anyone who plays the game and therefore helps test the code in “real life”. The plan is to conduct multiple rounds, with a bigger bounty each time, and hopefully with higher participation. There is no direct monetisation involved, simply because there is no good way of doing it. Which means that the size of the bounty will always be greater than the amount collected by the game. In fact, the only reason the game “collects” anything is to make the concepts that are tested applicable to the token sales.

Where is the code and its status

Under development, feature complete, but still adding tests.

Contract: https://github.com/AlexeyAkhunov/tokengame/blob/master/contracts/TokenGame.sol

Tests:

https://github.com/AlexeyAkhunov/tokengame/blob/master/tests/TokenGame.kt

The idea of using Kotlin and EthereumJ for testing is courtesy to: https://github.com/Zoltu/recoverable-wallet

Caps

Caps on token sales have been almost universally introduced after the DAO incident in the summer of 2016, after which it has been suggested that no contract should not hold ETH in excess of $10M. The caps on token sales seemed a responsible thing to do. Very popular token sales were closing in matter of hours or tens of minutes. The caps slowly grew. Caps created competition to get into the popular sale at the beginning. The situation became absurd during the BAT sale on the 31st of May 2017, which sold out in roughly three blocks. In order to get in, one had to either employ some clever tricks, or be prepared to pay a very high fee.

Caps with proportional returns

This idea has been proposed many times, and it is to accept uncapped amount of ETH during the sale only limited by time. At the end of the sale, accept only the amount required, and return the rest proportionally to how much has been put in.

Two main problems have been pointed out. Lets call the first one “ambush”. One can wait until just before the end of sale, observe the current total contribution, and then contribute a relatively large amount (potentially borrowed for a very short time) as close to the end as possible, in an attempt to acquire a large share of tokens, unchallenged. The second problem is the ability of large ETH holders to dominate most of the ongoing sales by selling tokens as they hit the marketplaces and recycling the ETH to get into the next one. Lets call it a “whale” problem.

Anti-ambush: Dynamic extensions

Token game deals with the ambush by dynamically extending the end time of the game depending on the relative magnitude of the recent contributions. The “relative magnitude of recent contributions” is modelled as Time Weighted Exponential Moving Average of amount of wei contributed (function “exponential_decay”), divided by the total wei contributed so far. For example, if the initial duration is 1 week, and just before the end of the game, someone contributes the amount equal to the amount already collected, the game is extended by a maximum of 2 days. Subsequent extensions will require more and more sizeable contributions, and eventually the game will conclude. The details could be found in the “contribute” function of the TokenDistribution contract.

One of the desiderata in designing this feature was the lack of the incentive for the players to split up their contribution. Hopefully, if there is no need to do that, we shall have a better understanding of the token distributions, for example, from the excellent analyses done regularly by Corey Petty.

Anti-whale: Delay of excess returns gives token advantage

Vlad Zamfir has recently suggested the use of an uncapped sale, but instead of returning the excess ETH, burning it or donation to charity. It might eventually prove a workable model. However, burning seems quite extreme for the time being, and giving to charity is not a simple problem per se. In that twitter exchange, Ethan Buchman suggested using time locks as a multiplier for token allowance. The token game takes this idea a bit further and introduces exponential advantage in token allocation in exchange for readiness to lock up the excess ETH for extended period of time.

For example, the game looks to “collect” 10 ETH. Alice contributes 1 ETH, and she is happy to lock up the excess (part of her contribution which is not accepted in exchange for tokens) for 52 weeks (one year). Bob contributes 10 ETH, but he is only happy to lock up the excess for 4 week, and Carol (the whale) puts in 100 ETH, but with zero lock up time. In the current version of the code, 52 weeks of lockup gives Alice 1.07⁵²=33.72 advantage factor versus Carol. Bob will have 1.07⁴=1.31 advantage versus Carol, and Alice has advantage 1.07⁴⁸=25.72 versus Bob. In order to compute accepted amounts from Alice, Bob, and Carol, we use this reasoning:

accepted(Alice) + accepted(Bob) + accepted(Carol) = 10 accepted(Alice)/contributed(Alice) = 25.72 * accepted(Bob)/contributed(Bob) accepted(Alice)/contributed(Alice) = 33.72 * accepted(Carol)/contributed(Carol)

There are 3 linear equations with 3 variables, therefore it is quite easy to solve:

accepted(Bob) = accepted(Alice)*contributed(Bob)/contributed(Alice)/25.72 = accepted(Alice)*10/1/25.72 = 0.38 * accepted(Alice) accepted(Carol) = accepted(Alice)*contributed(Carol)/contributed(Alice)/33.72 = accepted(Alice)*100/1/33.72 = 2.96 * accepted(Alice) accepted(Alice)[1 + 0.38 + 2.96] = 10 accepted(Alice)= 2.3

Alice is allowed to contribute 2.3 ETH, but she only put 1 ETH, therefore we take the whole 1 ETH, and then solve the equations again for Bob and Carol and remaining 9 ETH to accept:

accepted(Bob) + accepted(Carol) = 9 accepted(Bob)/contributed(Bob) = 1.31 * accepted(Carol)/contributed(Carol) accepted(Carol) = accepted(Bob)*contributed(Carol)/contributed(Bob)/1.31 = accepted(Bob)*100/10/1.31 = 7.63*accepted(Bob) accepted(Bob)[1 + 7.63] = 9 accepted(Bob) = 1.04 accepted(Carol) = 9 - 1.04 = 7.96

After the game, Alice will have acquired almost the same amount of tokens as Bob, without any excess locked for 52 weeks. Bob will have 8.96 ETH locked in for 4 weeks, and Carol will get only 8 times more tokens than Alice, despite having put 100 times more ether.

This mechanism is implemented in the function “close_next_bucket”, which needs to be called after the end of the game as many times as there are non-empty buckets (players locking up excess for the same amount of weeks are grouped into buckets, and the maximum lock up time is 100 weeks).

Security features

There are two security features in the Token Game contracts. Firstly, and very obviously, any participant can withdraw from the game completely at any time before the end of the game, using the “escape” function.

Players can, of course, rejoin, with the same or different lock up period. To prevent this mechanism from being used to endlessly extend the duration of the game, such withdrawals suspend the extension mechanism until the withdrawn amount is replenished by the new contributions:

if (total_wei_given <= ema_divisor) return;

The same escape function is used in the case when the game contributions did not reach the target.

The escape functionality also allows everyone abandoning the game in case someone finds a way to extend it indefinitely.

The second feature is in the way the time locked excess is stored (contract ExcessWithdraw). When the excess is locked up (during the call to “close_next_bucket”), the player is given tokens capable of withdrawing the locked up ether in the future. Because these tokens are fully transferrable (ERC-20), they can be moved to a different account (for example, when the player upgrades her security and buys hardware wallet). They can also be sold, like a zero-coupon bonds with the blockchain as the counter-party.

Prize pot

Prize pot is funded before the game starts, but it can also be topped up during the game. In the end, the tokens distributed by the game, give equal share of the prize pot. If the game did not reach the target, the prize pot can be taken back by the owner of the game.

Feedback please

I hope you will come and play the token game when it is launched. But for now, please leave any feedback in the comments, and thank you for your time.