Smart Contracts Gone Rogue


Recently a suggestion to liberate frozen funds, written up in Ethereum Improvement Proposal EIP-999, has caused some controversy. The proposal aims to liberated stuck investments, that were frozen on the Ethereum blockchain in the second Parity hack.

Before discussing this particular case, let’s first talk about smart contracts in general. A smart contract is a contract written in computer code, providing automated execution. On a blockchain this means, we can automate financial transactions and other interactions in a transparent way. The blockchain’s immutability property provides protection from transactions being undone or manipulated.

Smart Contract Pitfalls

However, the properties that make smart contracts such powerful tools are also their biggest problem. Every software engineer knows that writing bug-free code is extremely hard, if not impossible. Automated financial transactions, therefore, present a risk of things going unstoppably wrong. This is made even worse by the immutability property that states that smart contracts, once deployed, cannot be changed. Thus, they cannot be fixed either.

There are many cases of smart contracts on blockchains going rogue, but two cases stand out because of the amount of money involved and the high profile of the stakeholders involved.

The DAO Attack

The DAO attack happened in June 2016 to one of the biggest and most ambitious blockchain projects ever. DAO stands for Decentralized Autonomous Organization, referring to a blockchain-based organization ruled by a series of bylaws written in smart contracts. This particular DAO consisted in participants paying investments into a smart contract and voting on which project to support with the collected funds. The idea is simple and brilliant, but surprisingly easy to get wrong.

The DAO was hacked when an attacker managed to divert 3.5M ETH into a so-called child DAO. A child DAO is a mechanism that was provided for investors to reclaim their funds and create a spin-off in case they were unhappy with decision making. Unfortunately, the withdrawal code had a critical vulnerability, that allowed the attacker to withdraw much more funds than he had invested, i.e. steal other people’s money. We might go into the specific vulnerability (reentrancy attack) in another article, but for now, let’s just say it is a simple mistake that is very easy to exploit.

Child DAOs had a 28-day lock period, meaning the attacker could not move the funds for four weeks, which led to a race against time to find a solution, splitting the community. In the end, a majority of the community decided to rewrite history by patching up past transactions, with a significant minority opposing this move and splitting off into Ethereum Classic.

The Parity Hack

The Parity hack, which is causing the current controversy, happened in November 2017 (actually it was the second parity hack). Whilst the case is different from the DAO hack, it is another example of people trusting open source smart contracts provided by one of the biggest blockchain industry players.

Parity, apart from providing one of the most used Ethereum node implementations, also provided a boilerplate contract for creating multi-signature wallets. Multisig wallets are incredibly useful for start-up companies to manage their funds. If you are a start-up and need such a wallet, using a popular open source implementation provided by an expert company, such as Parity, looks like a solid and safe decision, which is why many companies trusted their funds in Parity’s code.

Without going into details of the actual hack, the problem of this particular contract was related to a common library, which was rendered useless by the accidental attacker (the person responsible claims stumbling into this mess unknowingly). The result was the funds of all start-ups using a Parity based multisig wallet being frozen, possibly forever. The owners still see the Ether on their accounts, they just cannot withdraw or move them.

The above-mentioned EIP-999 is about unfreezing the accounts, again by messing with transaction history in a protocol fix.

The Controversy

Changing transaction history is against the fundamental principle of immutability. Opponents argue that a blockchain that is changed retrospectively cannot be trusted. Another argument against these type of protocol fixes is that it is hard to decide who gets to be bailed out. Plenty of people have messed up their smart contracts. Why should high profile cases be treated differently?

On the other side, supporters of EIP-999 claim that the technology is still new, and mistakes will happen. Not providing a way out and insisting on cautiousness can stale progress. They also claim, these hard forks are community decisions and, therefore, comply with the decentralization principle.


Whatever will happen to EIP-999 and the stuck funds, it’s becoming clearer every day that writing smart contracts is extremely difficult. The powerful technology involved has its downsides. The problem is also closely related to blockchain governance, which we touched on recently. Who gets to have a vote on such issues?  There is no doubt the blockchain community has to figure out a way to write more secure smart contracts and find ways to resolve these conflicts, should issues arise.

Previous articleBlockchain Governance and the Limits of Decentralization
Next articleCrypto Prices Fall on Phantom Meeting News
Dr. Stefan Beyer is editor-at-large at BlockTelegraph and a Blockchain consultant and smart contract auditor. He graduated from the University of Manchester in 2001 with a degree in Computer Science and obtained a Ph.D. in 2004 from the same university with the title “Dynamic Configuration of Embedded Operating Systems”. Since then he has worked in computer science research in distributed systems, fault tolerance, ubiquitous computing and cyber security. He is currently working as head of research and development for a medium-sized cyber security company in Spain.


Please enter your comment!
Please enter your name here