From Smart Contract to Interpol Red Notice – Developer Liability

Where a smart contract does not operate as intended or if the code has been poorly written and includes security flaws allowing hackers to compromise the smart contract, an affected user could consider bringing a claim in negligence against the developer. For a claim in negligence an affected user must (i) show the developer owes a duty of care to the user (ii) prove the developer breached the duty of care and (iii) that breach caused loss to the user.

• A duty of care - Australian courts do not automatically recognise a ‘duty of care’ owed by software developers to users. As such, an affected user needs to establish that the developer had a duty of care to the user when developing the smart contract. This might not be straightforward. For example, where an affected user suffers economic loss, the question of whether the user was vulnerable, in the sense that they were unable to protect themselves from a coder’s failure to take reasonable care, will be an important issue.
• Breach of duty - The affected user will also need to show that there has been a breach of the duty of care. It does so by showing that the developer did not use reasonable skill and care in coding the smart contract. The standard of care applied is that of a reasonable developer of similar software. Doing so in relation to a smart contract might be made easier where the code for that smart contract is open source and available for others to read. However, a developer can mitigate their risk by taking preventative steps that are established by good smart contract development practice, such as having their code audited by a reputable third party prior to release on the blockchain.
• Causes loss - Causation of loss may be obvious if the smart contract fails to provide an advertised outcome but would be more complex for a claim in which the smart contract is hacked by a malicious third party The second example could involve questions on whether the poor security of the smart contract caused the loss or if it was only because of the actions of the hacker.

Actions taken by others involved in the code development process can also be relevant to the question of causation. Given that multiple people might be involved in this process, the question of whether it was the code developer that caused a user to suffer loss is unlikely to have a straightforward answer.

Ultimately, a claim in negligence against a coder or other person involved in the development of a smart contract would be novel and would certainly raise some difficult legal issues.

Consumer laws around the world can provide consumers with the benefit of implied warranties for the goods and services that they acquire. These implied warranties often override any less favourable terms and conditions provided by a business and generally cannot be contracted out of. These laws typically provide protections for people that enter transactions as consumers, rather than as a business user. Acting as a consumer can also include for the purpose of investment. 

In Australia, there is no guidance on whether smart contracts or dApps constitute “goods” or “services” for the purposes of the Australian Consumer Law (ACL). Although the ACL expressly includes “computer software” in its definition of “goods”, the term “computer software” is not defined in the ACL. Australian Courts have however provided guidance that computer software is effectively instructions or programs that make hardware work, as opposed to non-executable data. Given the uncertainty, it is possible that the consumer guarantees for both “goods” and “services” under the ACL will apply to smart contracts, but only as long as these are supplied to a consumer, an important issue particularly given that a smart contract can be uploaded to a public blockchain for use by anyone. Whether a smart contract is a good or a service and whether it can be supplied to a consumer for the purposes of the ACL are issues that have not yet been considered by the courts.

Under the ACL, goods must be of acceptable quality. In the case of smart contracts, some considerations include whether they are fit for the purpose for which they are supplied, and free from defects based on an objective test of what a reasonable consumer would regard as acceptable. Although there is no Australian Court authority on this point, given the relative youth of smart contract application on blockchains, we expect that a developer could argue that a “reasonable consumer” is aware that computer code, specifically code on a blockchain, is not foolproof. However, when defects in the code corrupts the main purpose of the smart contract function, it would be open to an affected user to claim that the developer responsible for the code should be held liable for not complying with the consumer guarantee of acceptable quality.

The ACL also provides that services must be rendered with due care and skill and be reasonably fit for any purpose that the consumer makes known to the supplier. Although the standard of “due care and skill” is a common law negligence standard (see above), unlike in negligence, developers cannot limit their liability for contravention of a consumer guarantee by contract terms (see below).

If defects in a smart contract constitute a failure to comply with the consumer guarantees, then consumers may have an action under the ACL to recover damages for their losses suffered. In Australia, these laws provide strong protections to consumers as any attempt by a developer to limit or exclude their liability by contract will be void under the ACL. In addition, attempts to exclude liability can lead to contravention of other provisions under the ACL, including prohibitions on engaging in misleading or deceptive conduct or making false or misleading representations concerning contract rights.

Developers of smart contracts will often publish details describing their smart contract or dApp and how it is intended to operate. This can be in the form of a website to promote the dApp, promotional advertising, social media postings or in the form of a white paper as was the case for Do Kwon and his colleagues at the launch of the UST stablecoin project. A user of the dApp that relies on the description of its intended operation or other promotional statements before engaging with it may have grounds to bring a claim for misleading and deceptive conduct under the ACL against the person who made those statements. To do so, the user will need to demonstrate:

• that the representations made by the developer were done so in trade or commerce;
• that the smart contract or dApp did not operate as represented by the developer; and
• because the user relied on the developer’s misleading representations, the user subsequently suffered a loss. 

In other jurisdictions, a customer relying on statements describing a smart contract may be able to bring claims against the developer on the grounds of misrepresentation.

A complicating feature of blockchain technology that will likely impact on the application of the laws mentioned above (and others) is that control of smart contracts or dApps can be relinquished by a developer once a protocol is operating on a blockchain. Sometimes this control is given to a DAO that manages changes to a dApp in a community-driven way. Whether an original developer can remain liable for a dApp once it has changed and is managed by others is yet to be determined but we suspect questions of liability will turn heavily on the circumstances of each particular case.

Smart contract developers can consider applying legal/contractual terms of use to their smart contracts. In addition to covering issues specific to the functionality and performance of the smart contract, the terms of use can seek to exclude liability. This approach has been successfully followed in open-source software (OSS) licensing for many years, where standard OSS licences typically exclude all liabilities for the developers. It does not yet appear to be standard practice for smart contracts, for example we could not locate any terms of use that relate to the use of UST.

Terms of use can exclude or limit liability for contract breaches but also in respect of other types of liability such as negligence. This type of contractual exclusion or limitation of liability is not always effective. For example, they may be invalid and unenforceable by virtue of a consumer law, such as they cannot exclude the developer’s liability for breach of consumer guarantees under the ACL. Further, terms of use cannot exclude liability to the state for breaches of regulatory laws or in respect of criminal liability.

To be effective, the terms of use need to be brought to the attention of the user prior to or at the time the user engages with the smart contract or dApp. This is essential for the terms to have any contractual effect and creates a potential difficulty for developers. More specifically, code placed on a blockchain by its developer might be accessible directly, but it might also be accessible through a web or mobile interface that was not necessarily created or approved by the developer of the underlying protocol. Unless a developer was able to devise a method for including terms of use in the underlying code that could always be brought to a user’s attention, then a disclaimer of liability contained on the web interface created by the developer might not always be effective. Regardless of these apparent challenges, developers should at least consider implementing mechanisms to disclaim their liability at the early stages of designing a smart contract.

Do Kwon is accused of breaches of Korea’s capital markets regulations. Similarly in Australia, the financial services regulator ASIC has recently brought proceedings against certain companies for allegedly engaging in conduct in breach of financial services regulations. One such proceeding relates to a crypto-asset token called Qoin and the other relates to a variety of fixed yield earning crypto-asset token products. These situations highlight the tendency for national regulators across all sectors (eg financial services, energy or communications) to apply existing laws to new situations emerging on web 3.0 - developers should therefore carefully consider how these existing regulations might apply to the applications that they are creating as sector specific regulation will typically impose additional obligations and requirements.

In other cases, regulatory authorities have noted that smart contract developers might not themselves directly breach the applicable regulations but have enabled others to do so, as is the apparent case with Alexey Pertsev, supposedly detained by the Dutch authorities for concealing criminal financial flows and facilitating money laundering through the Tornado Cash dApp.

To mitigate the risks of incurring liability for facilitating others to breach applicable regulations, a developer may seek to apply lessons learnt from previous case law dealing with novel technologies, such as peer-to-peer file sharing. From those cases it would be beneficial for the developer if:

• the smart contract is capable of substantial non-infringing use;
• the developer can provide evidence that it has not deployed the smart contract with the object of promoting it to allow others to infringe laws; and
• the developer should not have knowledge of any specific infringements using the smart contract or, if it does have knowledge, that it is not able to prevent them.

However, this approach is not legally tested in relation to smart contracts.

The above approach will not provide protection from criminal acts undertaken by the developer itself. For example, the charges against Do Kwon apparently include fraud.