Legal issues surrounding Parity wallet’s kill switch

The Parity wallet is one of the products offered by Parity Technologies Limited under a free software license. To be perfectly clear, the Parity wallet does not operate like a bank and it does not actually store cryptocurrencies. It is a type of digital wallet that serves as both a wallet and an interface between the Ethereum platform and your computer. But instead of storing your money, it stores your public and private keys (a bunch of random numbers used to encrypt and decrypt code), and allows you to send and receive cryptocurrencies.

On 20 July 2017, Parity updated and deployed the ‘library’ smart contract in order to fix a known vulnerability. This contract contained a new vulnerability which allowed anyone to assign them self as the owner of the ‘library’, which in turn allowed the owner to ‘kill’ the library. On 6 November 2017 the said vulnerability was triggered ‘accidentally’ by someone by the name of devops199. As a result, all wallets that were dependent on the library became paralyzed — that is a total of 584 wallets containing 513, 774.16 ETH or approximately US$243 million at time of writing.

Let’s say you physically possessed a safe that held your private key. Well devops199 disabled the electronic pin pad that would have enabled you to access its contents.

The questions

The triggering of the vulnerability raises many legal questions such as:

  • Who is responsible for the vulnerability (devops199? Parity developers?)
  • What recourse do users and businesses have against Parity Technologies Limited?
  • To what extent do free software/open sourced software licenses and legal disclaimers limit the service provider’s liability?
  • Could devops199 be facing criminal charges or civil claims under the Computer Fraud and Abuse Act?

This also raises other business related concerns about using a free, open sourced, unregulated software service where significant amounts of cryptocurrencies are at stake. Should investors and businesses be trusting their crypto holdings with a software provider that is uninsured, has no government backing, and has expressly stated that they have zero liability – even when they are negligent?

The potential contractual relationships

1. Parity and User/Business User — governed by Terms of Website Use and GNU General Public License (GPL).

2. Parity and devops199 — governed by Terms of Website Use; devops199 may have breached one of the terms by using the site for a ‘prohibited use’ (see below). It may also be possible for Parity to claim damages against devops199 under the Computer Fraud and Abuse Act (see below).

3. User/Business User and devops199 — no contractual relationship. It may be possible to claim damages against devops199 under the Computer Fraud and Abuse Act (see below).

4. Business User and their customer — recourse depends on any contractual relationships between the parties. If a business held the frozen crypto on trust or on behalf of their customer under a contractual agreement, then the business may have to cover the lost funds. Similarly, if the frozen crypto was delivered to the business in return for a good or services (e.g deliver fully functional tokens post-ICO), the business would still be bound by any contractual promises it made irrespective of whether the frozen funds are recovered.

The diagram below from Elementus reveals the main wallets affected. According to Elementus, at least 16 of the affected wallets are associated with companies that have raised money via an ICO.

Software liability

Could there be a claim for damages under tort law? It could be argued that Parity owed a duty of care to its users as there was a foreseeable harm (Parity had been alerted to the vulnerability in August but decided to delay the fix to a future point in time), the degree of certainty that the users would suffer injury was extremely high (due to the large sums of value stored and as evidenced by recent high profile hacks such as The DAO, Mt Gox) and yet there was no formal audit.

This Reddit user claiming to work for Parity admits that they “rushed” and “forgot” to execute a key piece of code resulting in the vulnerability.

The standard of care may be higher due to claims that it is “The fastest and most secure way of interacting with the Ethereum blockchain.” and “Ultra Reliable”. However as this article states, establishing the causation may be difficult so long as courts choose to fixate on the hacker, not the environment-creator, when assessing who brought about the injury in question. US courts have previously focused on the role of the hacker instead of considering the role of the software developer in creating an environment susceptible to exploit.[1]

General Public License

Parity is licensed under the GPLv3, or GNU General Public License version 3 which guarantees end users the freedom to run, study, share and modify the software. An excerpt from the license:

According to this clause, it seems that Parity may be protected from claims for damages from the inability to use the program, depending on whether an applicable law states otherwise or something else was agreed to in writing. Applicable laws could vary depending on state or jurisdiction, however it appears that all users would have also agreed to a similar limitation of liability clause in the Terms of Website Use (see below).

Terms of Website Use

Here is an excerpt from Parity’s Terms of Website Use:

Recourse against Parity may be difficult as it appears that users of the site would have agreed to the Terms of Website Use. Depending on the state or jurisdiction, such limitation of liability clauses may be disfavored or even unenforceable. Some US states have refused to enforce the clauses for a number of reasons, including finding the clauses violative of the specific state’s anti-indemnity statute, or holding that they are unenforceable as against public policy.[2] Whether or not the Terms and/or the GPL will override any negligence claims will be a question for the relevant courts to decide.

Elsewhere across the globe, Australian regulators are starting to look beyond the code. Below are recent quotes from the chairmans of the competition regulator (ACCC) and securities regulator (ASIC) suggesting an approach that focuses more on the actions of the technology company:

In Australia, we take the view that you cannot avoid liability by saying “My robot did it” — Rod Sims (ACCC)

[Greg] did not want to see technology platforms of algorithms “shifting risk to consumers and other areas of society”. If an algorithm made a mistake due to an error in its inputs or issues with the code’s design, companies must ensure there are avenues for redress.

… there needs to be a person who is responsible for its design and its outcomes — you can’t just be pointing at the algorithm— Greg Medcraft (ASIC)

What about Devops199?

It appears that devops199 may have breached one of the Terms of Website Use, but for a typo in the terms.

Note to Parity lawyers, you may want to get rid of the word ‘Not’ in that first bullet point — but fear not, because Code is Law, right?

Typo aside, according to the Terms of Website Use, it appears that Parity may choose to take a number of actions against devops199 for the breach including:

Assuming Parity can argue that a breach occurred in spite of the typo, such terms may be useless if the identity of devops199 remains unknown.

Computer Fraud and Abuse Act (CFAA)

The CFAA includes 7 types of criminal activity including intentionally accessing a protected computer without authorization and as a result, causing damage and loss (18 U.S.C. § 1030(a)(5)).

A protected computer is a computer used by a financial institution, or the U.S. Government, or more importantly, a computer affecting interstate commerce or communication, including a computer located outside the United States that is used in a manner that affects interstate or foreign commerce or communication of the United States.[3] An argument could be made that enough value was flowing in and out of the Parity wallets to affect interstate commerce. Furthermore it has been held that people using ordinary internet connected personal computers (and mobile devices) can been subjected to prosecution under the CFAA due to the inherent interstate nature of normal internet communication.[4]

Despite devops199 claiming that he was an ‘eth newbie’ and that he ‘accidentally killed it’, there are reports suggesting that it was a ‘deliberate hacking’.

The fact that devops199 purposely or knowingly made himself an owner of the smart contract in which he is not the owner may be relevant when determining whether the act was done ‘without authorization’:

The CFAA also allows any person who suffers loss or damage as a result of violations of the Act to bring civil actions against the violators for compensatory damages (18 U.S.C. § 1030(g)). The type of damage must fall under one of the listed categories including a loss at least $5,000 in any 1 year period. Note that losses under this category are limited to economic damages. Assuming that the identity of devops199 can be determined, and the ‘protected computer’ definition is satisfied (see footnote 3), it appears that Parity Technologies Limited and each of the wallet owners holding greater than $5,000 of ETH at the time of the ‘hack’ may be able to bring civil actions against devops199 for the amounts lost.

According to Elementus, 60 of the affected wallets have balances greater than $10,000.

Concluding thoughts

This recent case shows the dangers of businesses relying on free and open sourced software for managing crypto funds, whilst being exposed to being sued from their own customers when something goes wrong. Imagine a chain of legal obligations that ends abruptly at the wallet service provider. A hedge fund that holds ETH in a wallet may have contractual and fiduciary obligations to its investors but then have no recourse against the wallet service provider holding its ETH.

Should a software service provider that has the potential to directly cause millions of losses in cryptocurrencies be operating under a OSS license and with zero liability? As this article states, it is far easier to attack a smart contract because you have access to the code of every contract, know how much is in it and can take as long as you want to try to attack it.

Perhaps the real problem is that cryptocurrencies are not money and the usual protections/regulations governing money service businesses, deposit taking institutions, banks, safety deposit services do not apply to cryptocurrencies.

I see three possible solutions to this problem.

  • Critical apps that directly affect crypto holdings above a certain value should no longer operate under OSS licenses or have Terms of Use that limit their liability to such extremes. Introducing responsibility would, in theory, encourage more stringent security measures such as insured funds, frequent/formal/independent code audits, back up reserves.
  • Banks could start providing wallet/storage type services (e.g. South Korea’s Shinhan Bank recent announcement to build crypto wallets for its customers)
  • Institutional investor with at least 10 million dollars of cryptocurrencies could use Coinbase’s digital asset custodian service. This could solve some of the problems mentioned IF there was some sort of guarantee over the funds and/or insurance.

[1] Directly taken from


[3] It is unclear whether the Ethereum network/Parity Ethereum Client/smart contracts would be considered a ‘computer’ for the purposes of the CFAA and even if it were, which component is the ‘protected computer? It may be useful to look at cases involving DDoS (distributed denial of service) attacks that have been found to be a violation of the CFAA. In one case, the defendants had executed a series of coordinated cyber-attacks against victim websites by flooding those websites with a huge volume of irrelevant internet traffic with the intent of making the resources on the websites unavailable to users of the websites:


About me: I am an Australian lawyer living in New York with experience at the Australian Securities and Investments Commission (ASIC). I am interested in the legal questions on whether emerging tech fits under existing laws, policy questions as to what should be regulated, and technical questions as to how uses of tech can be regulated (where necessary).

Add a Comment

Your email address will not be published. Required fields are marked *