Recently, a critical bug was found in the MultiSig wallet implemented by the Parity team. A function that was meant to initially set the key holders was completely unprotected. Everyone could call it anytime and effectively take over control of any MultiSig wallet that was using this insecure code.
Tokens and Ether worth more than $200m were affected by this bug and could have been stolen by anyone. For us, the main question is now: Can we be 100% sure that such a bug can never make it into our MultiSig Wallet?
The realistic answer is: We can never be 100% sure. However, we do think that we can at least make these bugs very, very unlikely. When there’s a single person writing code, it is likely that bugs and errors sneak in during development. The key to preventing errors is a rigorous review process involving multiple developers. This process starts at the initial creation of the smart contract and extends to the actual release to catch all bugs before the contract is used in production.
Below is a list of absolutely minimal process requirements we defined for our smart contracts that intend to deal with millions of dollars of value.All contract code needs to be published multiple months before actual deployment. A natural language specification of the code should exist. A formal internal review process needs to be in place. Multiple experienced developers need to go through a checklist and sign off that they checked for specific bugs. At least two experienced developers undertook external audits of the smart contract. A public bug bounty program had been running for at least one month. A pilot...