Long reads

When Smart Contracts Go Wrong

Stephen Elam

Stephen Elam

Partner, Cooke Young & Keidan

This article was co-authored by Stephen Elam, partner, and Elizabeth Meade, senior associate, Cooke Young and Keidan LLP.

What is a smart contract?

Smart contracts are computer code that automatically run when certain conditions are met, thereby executing all or parts of an agreement. Their use is widespread use in transactions on cryptocurrency exchanges, gaming, in the buying and selling of NFTs and in online gambling – and will only increase. They are quick and efficient, and because smart contracts are digital and automated, there’s no paperwork to process and no time lost reconciling any errors from manually completed documents.

Smart contracts exist on a spectrum of automation. Some are natural language agreements where the obligations are performed by code. When something goes wrong, parties can go back to and interpret the natural language. But where contracts are entirely written and performed by code – and no natural language for contracting parties to fall back on – what happens when things don’t go to plan?

How can a smart contract ‘go wrong’?

Smart contracts might not execute as expected. Take a simple example: a coding error results in a mis-placed decimal point and a transaction moves 100 BTC between wallets instead of, say, 0.1 BTC. The problem will almost certainly only be spotted after the transaction is effected. If the error is obvious, the parties might agree to effect another transaction reversing the error. But what if the recipient doesn’t rush to return the 100 BTC, or – more likely – the ‘error’ and its consequences are more nuanced and there’s no easy agreement on how to rectify? Remember that there is no natural language document to help the parties.  

On our example, the paying party will no doubt shout “mistake”, and assert a claim for return of the 100 BTC (less the 0.1 BTC). But English law (assuming it is: see below) will generally hold parties to what they agreed, i.e. the code, unless the concepts of common mistake or unilateral mistake can be found to apply.

A common mistake requires both parties to have a mistaken belief that the contract gives effect to their common intention. For conventional written agreements, this is notoriously difficult. You effectively need a mistake by both parties such that the contract is essentially impossible to perform (for example, because the subject matter of the contact turns out not to exist). It isn’t enough that the contract is more onerous than expected.

For unilateral mistakes, the mistaken party will usually be bound by the contract, unless it can show that at the time of contracting, the other party knew of the mistake.  A smart contract may, in principle, be void for a unilateral mistake, but how do you determine knowledge and by whom?  Can the non-mistaken party have the knowledge, when a computer programme is behaving as it should?

The Singapore courts (Quoine v B2B2) have considered this and contracts with diminishing human involvement in the context of algorithmic trading. The Court’s view was that the relevant individual whose knowledge was to be assessed is the programmer, and the court must consider whether such a programmer had actual or constructive knowledge.

What can be done about mistakes?

If a Court finds that there has been either a common or unilateral mistake, rectification may be available. This is where a contract is corrected so that it reflects the parties’ intentions. However, an immutable smart contract cannot be amended or ‘rectified’. Instead, a Court may need to order parties to deploy new code to correct the obligation in the original code considered to have gone wrong. This points to increased use of a different, novation-type, remedy.

And what about the return of the BTC in our example?  The Courts can order its return: a party can be awarded restitution for the unjust enrichment of the other party. Again, the concept is to reverse the enrichment, and effectively assume the original transaction did not occur. This conflicts with the essence of an immutable ledger, recording the transaction executed by the smart contract.

This involves the ‘fiction’ that the initial transaction never took place. But where there is an immutable ledger, there are clearly two transactions. That raises some difficult questions: who owns the BTC between the two transactions? The answer may be critical if the contract ‘gone wrong’ leads to defaults under additional contracts (smart or otherwise) before the wrong is put right.

Where and how…

Traditional contracts will generally stipulate which court should have jurisdiction over any dispute that arises, and which law will apply. Smart contracts come into their own in adding efficiency to cross-border transactions. Parties shouldn’t risk ruining that by failing to factor this into their code.

Without that, how is this determined? UK lawmakers have identified ‘digital location’ as problematic, deciding where digital assets - or particular acts on a ledger - are located. So far, the answer may be to look at where the asset’s owner is located. But what if the smart contract error means that ownership is unclear?   

There is no doubt that smart contract use in international transactions will continue to expand and develop, with real reason to be excited about the efficiencies they bring. But questions remain as to how courts will deal with errors that arise. Those operating in the smart contract space should be encouraged to take pragmatic approaches to resolving issues when they do arise, as these will not be straightforward and quick questions for judges to deal with.

Comments: (0)