Legal Considerations Around Smart Contracts: Contracts Between Computer Programs

Algorithmic trading—where two computer programmes deal directly with each other—is a commonplace of modern securities trading. However, in general such trading occurs under a framework contract which establishes the legal nature and effect of the transactions concerned. When computer programmes purport to deal with each other outside such a framework the legal position becomes considerably more complex. In our recent note ‘Legal Considerations Around Smart Contracts: Contracts Between Computer Programs’ we have sought to identify the issues which would benefit from clarification in order to enable such trading to flourish. This seems particularly important since the rise of artificial intelligence and smart contracting means that contracts of this kind are likely to become considerably more common in the future.

The two issues we identify are capacity to contract and reversibility of performance.

1. Capacity to contract

Can the interaction of two pieces of software create a valid contract in the absence of human intervention? English contract theory is based on the idea of agreement between parties. It is clear that a contract can come into existence where only one party is aware of the fact—this is the Shoe Lane principle, and is widely relied upon today in situations where software makes prices and offers available on the internet such that these offers can be accepted by users and therefore create contracts. However, this principle does not apply where neither party is aware of the contract. More importantly, at English law a matching offer and counter-offer do not in principle create a contract—a contract, in theory, only comes into existence where there has been offer and acceptance. It is clear that the parties could agree between themselves that such matching offers would create a contract, but that would necessitate a separate ‘framework’ contract which would have to be created by a traditional offer and acceptance route. Without such a contract, the position is unnecessarily unclear.

In such a case, if the intention of both parties was that contracts should result from such software interaction, a court would unquestionably seek to find that the arrangement between them was an enforceable contract. It would be helpful if this were clarified.

2. Reversibility of performance

The second question concerns the consequences of a successful challenge to such a contract once made. There are a variety of mechanisms by which the validity of a contract can be challenged (mistake, undue influence, lack of capacity), and at English law a successful challenge involves the unravelling not only of the contract but of any property transfer made pursuant to it. This is problematic for financial markets, and legislators have generally sought to protect them by enacting settlement finality legislation, whose effect is to preserve the validity of a transfer even in the face of a successful challenge to the transaction concerned. However, settlement finality legislation is generally confined to regulated markets.

Where a contract is made between two pieces of software, it is generally executed immediately and automatically—indeed, the ability to do this is one of the primary reasons for employing such software in the first place. However, such instant execution is only useful if it has some sort of settlement finality protection. Otherwise the unravelling of one contract could result in the unravelling of a string of other contracts in respect of the underlying property, with potentially systemic consequences.

The issue here is whether it should be possible for parties dealing outside established markets to be able to bring themselves within such a regime, by agreement or otherwise.

Simon Gleeson is a Partner at Clifford Chance.