When I see voting games I usually analyze (i) 51% attacks and (ii) bribe attacks. Looking here:

  • A malicious buyer 51% attacks to force a refund. Then, if everyone recognizes the refund was malicious, the developers can just do another sale.
  • A malicious buyer 51% attacks to force a non-refund. We’ll assume that this buyer is colluding with the devs, as that’s the only reason to do that. Then, in the worst case this is a way to turn $X into $2X. If you have access to buyers who trust you with $X, there are plenty of easier ways to maliciously make money off of them so I’m not too worried.
  • An attacker bribes everyone to refund (remember: bribes can be indirect, eg. if Poloniex custodially holds a majority of the tokens, then them voting on users’ behalf, and users are ok with it because Poloniex provides them convenience, in my lingo counts as a bribe). Then, once again, the devs can do another sale.
  • An attacker bribes everyone not to refund. This bribe would have to be ongoing for funds to keep coming out, leaving users plenty of time to organize an assurance contract or whatever other coordination to escape the briber’s tragedy-of-the-commons trap.

So, this gets my game-theoretic safety rubber stamp.

Now, let’s analyze this from the point of view of my “five properties” from here (http://vitalik.ca/general/2017/06/09/sales.html). One can balance between certainty of valuation and certainty of participation as desired by fiddling with the mechanism (sale duration, reverse dutch auction, standard Nth price auction, etc etc). It’s ok for sales using this mechanism to be uncapped, because the main reason behind supporting caps (dev teams not getting huge piles of money before they’ve proven themselves) is solved here using an alternative mechanism. Hence, we can satisfy the “no-central-banking” principle and the all-important criterion of efficiency (all-important because besides being intrinsically valuable, efficiency is a very good way to tell that your sale will not be incentivizing on-chain DoS splats) just fine.

In short, from all the sale mechanisms I’ve seen so far, this looks to me to be close to best-in-class.

A few sub notes:

  • I do NOT endorse locking tokens to prevent trading. This likely to just result in wrapper contracts, especially since we’ve seen a wrapper reverse dutch auction for Status already (https://twitter.com/vitalikbuterin/status/877837756742778880 )
  • Aside from democracy-activated kill switches like this, the natural alternative is a market-activated kill switch. Basically, the Bancor approach where all funds over a cap go into a contract that offers refunds at an exchange rate of close to the sale price, which goes down over time. For example, if you set a soft-cap of $2.5m and raise $20m at a price of $1 per token, then $17.5m goes into a contract which offers to buy tokens back at $0.875. The idea is that if the price drops below $0.875, then everyone sells their tokens back, draining the devs’ remaining money, otherwise the devs can keep going. The $17.5m is given to the team over the course of the next 4 years, and so the token buy price also linearly decreases. To prevent whales from maliciously draining the devs’ funds, we can have a mechanism where if $X of tokens have been bought back, then they can be resold at the same price. What are the pros and cons of democracy-activated kill switch versus market-activated kill switch?

Source and More information: When I see voting games I usually analyze (i) 51% attacks and (ii) bribe attacks. Looking here:

Author: Vitalik Buterin