In the past year, token sales have time and again proven their merit as an effective method to secure funding and bootstrap a community surrounding an open source project. But like anything new and exciting (that involves large sums of money), token sales suffer from severe growing pains. Earlier today, the anticipated CoinDash token sale suffered an unfortunate hack that led to the theft of $7m (about half of the proceedings raised).

While token sales are an amazing new tool to democratize funding, they also put a tremendous amount of pressure on the organizations initiating them to properly manage the process. After all, raising tens of millions of dollars publicly paints a fairly big ‘bullseye’ on your back.

How did the hack happen?

Following The DAO Hack and the ensuing hard fork, resulting from a bug in The DAO’s smart contract, smart contract security and auditing began attracting lots of (well-deserved) attention. As a result, token sale related smart contracts became somewhat standardized and harder to attack.

In security, it is often the weakest link in the process that is attacked, and with the maturation of token sale contracts, attackers turn to disrupting other parts of the sale process. With CoinDash, the hack was quite simple — the attacker was able to gain control of the the company’s website and replace the official sale address with his (or her) own. By the time CoinDash reacted, the damage was done; $7m worth of Ether were sent to the fraudulent address.

At this point we want to emphasize that we have nothing but respect to the CoinDash team. The way they promptly handled the hack, offering to provide tokens to all those affected is truly commendable. Further, the CoinDash team is a strong, reputable team that will surely bounce back from this unfortunate incident.

Best practices on securing your token sale

With the upcoming Enigma Token Sale, we are spending considerable amount of time on how to secure our token sale end-to-end. It is clear that beyond the common practice of auditing our smart contract, other aspects of the sale need to be secured as well. This question was also raised in the AMA session we held in our Slack channel, which prompted us to write this blog post.

Starting with the problem, we can see that the hack stemmed from a more fundamental issue — trusting a single, centralized source of truth that can easily be forged and manipulated. Whether it’s on a website, or through social media, providing a funding address in a single location isn’t sufficiently secure. Therefore, we need a more secure kind of proof of address.

While this is one of the main problems blockchains tackle, we can’t use the Ethereum blockchain as a direct (or only) solution, since on-chain identities are not tied to real-world identities. Instead, we propose to use a smart contract that will itself contain and constitute a proof-of-address, while pointing to some external medium (Twitter) for identity verification.

The way this works is quite simple and is illustrated in the diagram below. Basically, our smart contract will include the funding address, as well as signatures provided by several parties (a multisig of sorts) attesting to its correctness. The latter is easily achieved in Ethereum by hard-coding the required addresses at the contract’s creation and then marking the contract as signed upon receiving transactions from all required parties.

As mentioned, we also need further validation on who these parties are. This is achieved by storing two main pieces of information in the contract:

An image of the team holding a piece of paper with the address written on it. A social proof proving the identity of each one of the parties who signed the Ethereum smart contract. The proof itself is simply a link to a tweet, where the party announces the address it used to sign the contract, thus tying its real-life identity to a blockchain identity.

In practice (for space conservation reasons), we are likely to only store the SHA3 output of both #1 and #2 and get a fixed 256-bit representation of the data.

An illustration of the POA Contract functionality

Since issuing (and if desired — changing) the smart contract requires a multi-sig (we’re planning a 3-of-3 or 3-of-4 scheme), we believe it would become prohibitively harder for an attacker to switch the funding address with a fraudulent one. Any other kind of attack implies an attack exists on the Ethereum blockchain, which is highly unlikely. To further boost the confidence of the community, we will make sure that in addition to us, each of the other signers are reputable figures in the industry.

Other measures

There are several other measures we are going to take beyond providing a proof of address. These are general best-practices for any security-sensitive situation. Among these, we plan on properly securing our social media outlets with strong, unique random passwords (generated from a proper entropy source); rotating our passwords on a timely basis, and specifically before the token sale; and enabling 2FA on all accounts.

Our goal in this post was not to provide a complete solution, but rather to lead the discussion in the right direction. We’re going to build out the smart contract for our proof of address concept and open source it, with the hope that other entities undergoing a token sale would use and improve upon it. Let’s work together to ensure such hacks do not happen again and strengthen the ecosystem along the way!

As usual, we welcome you to join our Slack to discuss this, our platform and our upcoming Token Sale in more detail.