Edit: This article was previously longer.

I had, for the sake of transparency, provided the entirety of an email I sent to Roman regarding a number of my concerns.

In the interests of brevity, specificity, and to avoid retreading ground which has been covered extensively elsewhere, I have edited this down to the key unaddressed concerns that make me uncomfortable about association with ether.camp at the present time.

If you would like to review the original text, it’s here as a google doc.

Piper Merriam wrote a great post recently about Ethereum community values. I thought he was absolutely spot on, and my decision to publicly withdraw can really be encapsulated by this point:

Information Symmetry and Win-Win business relationships.
This one is particularly interesting in that it is not very common in the business world. This community seems to have silently agreed that we strongly favor openness in our relationships so that neither party has privileged information that gives them an advantage over the other in their decision making. Another way to put this is that we search for relationships where we have clearly aligned incentives.

I have been in discussion with Roman and his team over the past several days in attempt to encourage a change of strategy to address some issues which I feel make it inappropriate for ether.camp to do a token sale at the moment.

I was trying to encourage Roman to postpone the sale to allow time to solve some of the issues. As it became apparent that would not happen, I hoped at least that my concerns would be acknowledged publicly in the two subsequent AMAs so that people could make their own judgements with full information.

So far no satisfactory resolution has been forthcoming and the sale is proceeding as planned. On that basis, I do not feel that I can lend my implicit support to this token sale by continuing in my role as judge.

My primary concern is that hack.ether.camp appears to be game theoretically insecure. HKG is being sold as a means to purchase voting tokens in the Ether.Camp projects. This voting system is fundamentally flawed. I believe this may lead to backers losing their tokens, and consequent devaluation of HKG.

The voting, both to determine winner of the hackathon (and $50k prize!), and on funding decisions within the projects appear to be trivially gameable.

Firstly, “fans” who register have 10 kudos points to issue, which, along with each judge’s 1000 kudos points, will determine the winner of the $50k prize. It seems it will be easy target for sybil attack. It was suggested in the AMA that ether.camp would be watching for people sybiling votes and those teams would be disqualified. In that case competitors should sybil votes against those who appear to be doing well in order to get them disqualified.

The voting mechanism within projects also appears flawed.

HackerGold is used to buy tokens ‘emitted’ by projects. These tokens convey voting rights. It requires a 55% majority to veto a spending decision.

Here are some of the most obvious problems:

  1. Any competitor can simply purchase HackerGold, invest it in their own project such that they have at least 55% of the project’s tokens, and drain the fund without fear of rejection. A zero cost attack. A subtler attacker would use the first round of funding to lock in control of voting and wait to use the exploit in the second round of funding when they have direct control of Ether, rather than just the HackerGold.
  2. A project’s exec team can be ‘impeached’ and ‘replaced’ by 70% majority vote. In practice this seems untenable as there is no legal relationship between the startup and the token holders. The most they could do is block funding so that it is returned to investors, but as mentioned in (a), that’s trivial to prevent anyway. A team only needs to control > 30% of their DST tokens to prevent impeachment.
  3. There is no explicit relationship between an investment of HackerGold and the success of the project in which it is invested. I appreciate this relationship may be created by project issuing its own token (albeit at the risk of violating securities regulations). Consequently what is the motivation of the token holder to vote thoughtfully? It makes no difference to voters if they even vote maliciously to prevent the project having access to funds.
  4. Indeed, a malicious competitor team could purchase a controlling stake in a competitor’s project simply in order to block their access to funding. Again, this would be a zero cost attack as when a team is impeached, the HackerGold is returned to the backers.
  5. Amount of HKG invested is intended to act as a barometer of the popularity of the project:
“The amount of HKG collected by an individual team is a defacto crowd expression of the potential of the project. As such, it provides a baseline for future crowdfunding by the team once the hackathon is over. The teams who collect the most HKG will have the largest acceptance by the crowd and will have the greatest potential.”

Again, this is trivially gamed. It comes at zero cost to a project to invest in their own project in order to appear the most popular project and encourage others to invest. True enough, this is a feature/bug of most crowdfunding but explicitly highlighting this as a feature of the token only makes it more likely.

This is not an exhaustive list of issues, but rather indicative of the problems superficial consideration of the system unearth.

I believe in the premise of hack.ether.camp, which is why I agreed to be a judge. I would love to see it fly, but I think these issues should be resolved first.

Colony makes it easy for people all over the world to build organisations together, online.


Join the conversation on Discord, follow us on Twitter, sign up for (occasional and awesome) email updates, or if you’re feeling old-skool, drop us an email.