The plot sounds like something from right out of a movie. In the dead of the night, computers have been doing their thing — buying and selling cryptocurrencies based on maths and science. One morning, a human checks in and realises that something has gone very wrong. A glitch in the algorithm caused a product to be sold by more than 250 times its “normal” price. The human frantically calls the other human to say there is a “major breakdown”. The market operator reverses the transaction, but the other human thinks there is no mistake. 3085 Bitcoin (about USD$28 million at the time of writing) is worth going to court for.

I take that back. It would only be an interesting movie for robots.

For the rest of us humans, this is the case of Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2. Given the involvement of Bitcoin and Ethereum, this is one of the most high profile cases before the Singapore International Commercial Court to date. The SICC involves international judges, so it features two very famous names in the common law world, the ex-Chief Justice of Australia Robert French and Lord Mance from the UK.

The Court held in the end that there was no mistake and the cancellation of the transaction by the market operator was wrong.

Thing 1: It’s not cool, it’s a vintage contract law problem#

It’s easy to get excited over the words used in the judgement — “cryptocurrency”, “algorithm trading”, a “deterministic” algorithm. The court has never dealt with this sort of thing before!

Unfortunately, this is an age old problem in contract law. It deals with mistake in contract law. One type of problem involves a rouge. The rouge pretends to be someone else and buys a car on a hire purchase with his stolen identity. The rouge then sells the car to an unsuspecting buyer. Should the original seller be able to reclaim the car, or should the unsuspecting buyer, who has no knowledge of the scheme, be allowed to keep it?

Doing justice is not so straightforward here. Should one leave the loss where it lies, or intervene? If one wants to intervene, it has to be based on reasoned grounds, otherwise the courts will be inundated with claims of people being “mistaken”.

I view the court as trying to make a reasoned decision not to intervene. It’s very thorough and I felt that justice done was all right in this case.

However, not all mistakes are equal. If a mistake causes a loss beyond the contemplation of all reasonable parties, shouldn’t there be a remedy? This is where Lord Mance’s dissent comes in.

There is nothing surprising, impermissible or unworkable therefore about a test which asks what any reasonable trader would have thought, given knowledge of the particular circumstances.

Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 2 at [200]

I’ll admit it’s appealing and cuts through the morass in this troublesome area of law. However as long as judges have different senses of what justice entails, the majority’s analysis is the best we are going to get. Until we live in a better world, anyone operating a software which might be buggy has to draft a bulletproof terms of use to allow them to reverse any obvious error.

Thing 2: The programmer’s thoughts are relevant?#

This is an interesting idea. In order to figure out whether a party using a computer program has taken advantage of a mistake, we have to look into the programmer’s state of mind.

In this case, why does the trader’s algorithm add a “virtual price”? Is it meant to mislead the platform’s platform? Expert testimony was used to explain what the algorithm does in this case.

When I program, documentation is a chore. It would not say I was taking advantage of some system flaw in the normal course of business. Programmers already have to ensure that their work is secure, privacy first etc. Having them to write accurate documents about their state of mind may be too far. If the documentation is not clear, other aspects such as testing and internal plans come into play. I am not sure this is a world I would like to live in.

The only comfort I have is that programming mistakes which will become serious court cases are few and far in between. The primary reasons why people document their code are still relevant, like maintaining code. I do not think we need to pay more attention to documenting the design of code.

However, in particularly high risk situations, it may pay to document how your algorithm works carefully in view of future litigation. Although it worked here, our design decisions may not always be understood correctly in hindsight or by a judge.

Thing 3: Terms of use did not save the day#

In Thing 1, we concluded that given the state of the law, there is a big risk that the court would not undo transactions even if they resulted in an extreme outcome. Platform owners may be exposed to losses no one could expect.

The most straightforward way to deal with it is to change your terms to allow you to reverse any transaction at your discretion. For almost all platforms, your users are going to click accept anyway.

Quinone seems to have taken this to heart in March 2017 before the disputed transactions happened. They introduced an “Aberrant Value” clause in its terms of use on its website. The terms of use also includes a very common clause

You agree that [Quoine] reserves the right to change any of the terms, rights, obligations, privileges or institute new charges for access to or continued use of services at any time, with or without providing notice of such change. You are responsible for reviewing the information and terms of usage as may be posted from time to time. Continued use of the services or non-termination of your membership after changes are posted or emailed constitutes your acceptance or deemed acceptance of the terms as modified.

The Court held that even though the terms above did not require the provision of notice, the platform is still required to bring notice of changes to its users.

Furthermore, the “Aberrant Value” clause was interpreted strictly against the platform such that it did not exclude this kind of mistake.

The above illustrates the challenges of using terms of use as a way to protect a platform. One has to be an expert draftsman. One has to involve effort in highlighting changes to a user.

Above all, one has to be prescient about what kind of troubles a platform can bring. Given that software today interacts with many different kinds of users and software, this is hard, if not impossible.

Conclusion#

This is an exciting case which I am sure many law students will be reading from here on. Sitting in front of my computer now, I do wonder if the courts are able to resolve issues involving today’s technology. It’s no wonder that there is always some clamour for regulation. However, laws are not always forthcoming. Perhaps, in this area, one has to live with risk.

What do you think?