When developing a crowdsale smart contract, there are several options for handling the collection of funds. In this post, we’ll analyze the most common approaches, and try to assess their degree of security and transparency.

The Naive Method

During a crowdsale, the contract will receive payments. The simplest option is to let these funds accumulate in the contract’s balance. Once the crowdsale ends, the funds are sent to a wallet managed by the project’s team. Examples of this scheme can be seen in the Golem and DigixDAO crowdsales.

This simple approach, however, suffers from poor security. Crowdsale contracts have complex logic and hence a large attack surface. Leaving the funds (even for a short period of time) in such a contract is risky. Even if we take measures to strengthen our confidence in the correctness of the code (following best practices, performing code audits, etc.), it’s still possible to miss a bug, and an attacker can exploit it. Since we have to be extra careful when we’re handling money, this situation is undesirable.

The Forwarding Method

As an extra precaution, there is a complementary security principle one can follow: security by isolation. This means keeping parts of a program separate so that if one of them is compromised, the rest is not affected.

Following the above principle, a more secure approach has developed in the industry. Instead of temporarily storing the funds in the crowdsale contract, we can immediately forward them to a multisig wallet after each individual investment. Examples of this are the Storj and HackerGold crowdsales.

This is a better approach than the naive method: if the crowdsale contract is compromised, the funds are protected.

The Problem and the Solution

We have found, however, that using the forwarding method opens the possibility of a serious breach of the social contract of most crowdsales.

While the crowdsale is still active, the funds in the multisig wallet could be reused to buy tokens. This would corrupt investment figures, by emitting more tokens than were actually paid for.

Since blockchain data is public, and tools like block explorers enable anyone to easily see an account’s transactions, it is unlikely that such a manipulation would go unnoticed. However, the promise of smart contracts is that they enforce contractual clauses without human intervention. We think a programmatic enforcement is desirable in this case.

We propose a simple solution: timelock the funds in an intermediate contract until the crowdsale is over. When the crowdsale is finalized, funds can be sent to the project’s multisig wallet.

We’ll provide a simple implementation of this idea in OpenZeppelin and update the post with a link in the following weeks.

Conclusion

We have analyzed two common approaches to handling crowdsale funds, and presented what we think is a more secure and transparent approach.