Smart Contracts: Where Are We Now And Does AI Have A Role To Play?

What is a smart contract and why use one?

The Law Commission's 2021 report into smart contracts defines a "smart legal contract" as:

"a legally binding contract in which some or all of the contractual obligations are defined in and/or performed automatically by a computer program".

A simple and easily relatable example often used to illustrate the concept of smart contracts is the vending machine. Once an individual satisfies the conditions by selecting a product and inserting money, the machine automatically honours the contract by providing the chosen snack. All smart contracts operate on a similar conditional logic – if X, then Y (the X in this vending machine example being the selection and payment and the Y being the automated provision of the chosen snack).

Legal landscape

The 2021 Law Commission report concluded that the current legal framework is able to facilitate and support the use of smart contracts and that current legal principles can apply to smart contracts in the same way as they do to traditional contracts. This is a helpful confidence-building step, but as we explain below, it doesn't mean there aren't any issues holding back widespread adoption of smart contracts.

There are also related issues where the legal issues may benefit from clarification – so the legal landscape continues to evolve. For example, in July 2024, the Law Commission also published "Decentralised autonomous organisations (DAOs): A scoping paper" which considers the regulatory position for DAOs, including their interaction with, and reliance on, smart contracts. DAOs are discussed further in section 2 and in the Glossary.

Why use a smart contract?

By definition, a smart contract executes some or all of the contractual obligations automatically, without human intervention. This allows them to be performed:

faster i.e. at machine speed (rather than human speed, which is typically slower)
more efficiently and, in theory at least, more cheaply (because there are no labour costs – just the costs of the relevant technology)
with more certainty, as parties know that once the "trigger event" occurs, the contract will perform the associated obligation – and can be expected to do so with fewer errors than a human would typically make.

Such automation is on a spectrum and many existing contracts already involve elements of standard automation that we are familiar with. One example would be paying for a streaming service subscription by direct debit, where the automated direct debit can be regarded as a "smart element" of an otherwise "non-smart" contract (i.e. for provision of the streaming service).

Distributed ledger technology (DLT) and Blockchain

Some smart contracts – particularly in the financial services sector – also use blockchain and distributed ledger technology ("DLT") which can provide additional benefits.

What is DLT?

In simple terms, a distributed ledger can be likened to a spreadsheet recording data (for example, ownership of assets or account balances) which is held in multiple places (nodes) at the same time. Unlike a traditional spreadsheet, which is held and updated by one central party, updates to a distributed ledger are subject to a consensus mechanism. This means that, depending on the precise consensus mechanism, the information held in a distributed ledger may be extremely hard to alter - please see the Glossary for more detail. Throughout this article, we refer to DLT rather than Blockchain and DLT separately as these terms are often used to refer to the same things.

What are the benefits of DLT?

Benefits provided by using DLT include greater transparency as transactions recorded on DLT can be viewed by participants (and in the case of a public DLT system, any other person). By definition, DLT is distributed, meaning that it is more secure as there is no single point of failure at which the ledger may be hacked. There is also a consensus mechanism (see Glossary) which means that users do not need to trust one single authority to validate a transaction. This can make records very difficult to alter, which helps to promote confidence in the accuracy and security of the register. Finally, transactional costs may be lower, as there is a reduced need for intermediaries.

What can smart contracts be used for?

The following use cases illustrate where using a smart contract may benefit the contracting parties when compared to a traditional contract:

Royalty payments

Smart contracts have been used within the Non-Fungible Token (NFT) space to ensure that the original creator receives royalty payments from any onward sale of their NFT (see below for an explanation of NFTs). This application could be used more generally where a party is licensing its IP to another party in return for royalty payments, with the smart contract providing for automatic royalty payment. Parties using a smart contract may therefore experience better cash flow, lower costs in verifying (by removing the need for audit provisions or requirements to appoint a third-party auditor) and a reduction in human errors.

What is a Non-Fungible Token (NFT)?

A Non-Fungible Token or NFT is a unique digital identifier recorded on a distributed ledger. NFTs have been reasonably widely used for digital art to certify ownership and authenticity. They typically confer a licence to access a particular instance of a digital artwork. This allows artists to establish their authorship of the work and to prove authenticity to consumers.

Insurance

Where an insured event occurs, a smart contract can enable the automatic payment of the insurance cover. For example, a flight insurance product may provide cover if a flight is delayed by more than two hours. A smart contract can be used to verify the delay and then automatically make the payout. This saves the claimant the time and effort of submitting a claim and associated paperwork. It also saves the insurer the costs of processing it. This B2C example demonstrates that the benefits of smart contracts are not exclusive to sophisticated B2B transactions. A product of this type backed by major insurer Axa appears to have been successful in terms of a "proof of concept", but was discontinued owing to insufficient consumer take-up.

Service level default

IT services agreements often provide for the payment of service credits if the relevant service levels (such as minimum uptime %) are not met. A smart contract can be used for the automatic payment of the service credit where the service level is not met without any party having to take any action or make a claim. The advantages are similar to those set out above for royalty payments.

Decentralised Finance

Decentralised finance relies on the use of smart contracts to provide financial services, based on peer-to-peer transactions. As explained above, this has a number of advantages; as well as reducing costs for the contracting parties, it may also make infrastructure more resilient as there is no reliance on a centrally held register or ledger. A further advantage is certainty because code which is published on a DLT as a smart contract is immutable and is performed automatically. However, this does not mean that a smart contract will always behave in the same way. For example, there may be encoded rights which mean that one (or both) parties are able to terminate the contract, the contract might allow for upgrades, and there might also be external dependencies, for example, where input is obtained from an external data source (known as an oracle). Whilst transactions are executed automatically on a peer-to-peer basis, a decentralised finance system may be offered by a single actor, or decentralised "autonomous" organisation (a DAO) in practice controlled by a small number of actors. These different permutations illustrate how, in the financial services sphere, smart contracts have been deployed to achieve a level of complexity which, at first sight, might appear to be beyond the "If X, then Y" logic outlined in section 1 above.

FinTech as a trailblazer – but slower take-up elsewhere

More generally, FinTech will likely spearhead the adoption of smart contracts. It could act as a trailblazer for the development of smart contracts in other areas, even though financial services are heavily regulated (which could slow down the adoption of smart contracts). For further discussion of the role of smart contracts within the derivatives space, please see our article: Trends in the Derivatives Market and How Recent Fintech Developments are reshaping this Space. However, if we put FinTech to one side, we are not yet seeing particularly significant take-up of smart contracts for aspects of commercial contracts. This seems to be partly due to lack of demand, as highlighted by the Axa insurance product discussed above. However, it may also be due to concern over some of the problems with smart contracts, which are discussed below.

Problems with smart contracts

The potential legal problems of using a smart legal contract vary, depending on the nature of the smart contract and its reliance on code. Some smart contracts will be a natural language contract in which some of the contractual obligations are performed automatically by computer code (an example would be the use of a smart contract for service levels in an outsourcing contract, with the remainder of the contract being "non smart"). Alternatively, at the other end of the spectrum, there will be contracts in which all the contractual terms are defined in, and performed automatically by, code.

Does the code accurately reflect the parties' intentions?

As the smart contract is self-executing, it is imperative that the parties ensure that the computer code responsible for the execution of the contract accurately reflects the intentions of the parties. Given that most lawyers and business people are not programmers, this is likely to involve the appointment of an expert to create the relevant code. But how will the parties know that the programmer has accurately translated the parties' intentions into code? Additional programmers could be engaged to review the first programmer's work on behalf of each party, but this involves yet more cost.

A possible way around this problem would be to develop industry standard templates for particular activities which businesses wish to automate through smart contracts; this would give parties comfort that various experts had already examined the code and were satisfied that it achieved a particular objective. However, this requires a willingness on the part of industry participants to devote time and energy to the development of such templates.

Reliance on external data sources

In many cases, there will also be a reliance on oracles or other external data sources. For example, in the insurance example given above, there will need to be a reliance on an external data source to provide the input (that the flight is delayed) that triggers the required action from the smart contract (i.e. paying out of the insured individual). The parties will need to be satisfied that the data is generally accurate and reliable. Costs may have to be incurred both to gain access to the data and to write software to link the data source with the smart contract.

Implied terms and variations

Parties sometimes consciously accept a degree of ambiguity in their contractual terms because it suits their interests at the time. This might be because they are prepared to compromise in return for getting what they want in other provisions of the contract or simply because the relevant issue is not particularly susceptible to precise drafting. With software code, deliberate imprecision of this type is not really an option as it is likely to result in the programme failing to function as intended. This highlights how code is inherently less flexible than human language. In addition, the same security characteristics which make smart contracts residing on a blockchain appealing also create difficulties for parties looking to amend a contract. All this raises the stakes in terms of the importance of getting the code for the smart contract right first time – because if it isn't right, it may be difficult to change it (either by variation or by a court agreeing to imply terms to "fill gaps" in the contract).

Automatic execution: not always a good thing

Lastly, automatic execution also means that a party may not be able to excuse a contractual breach by the other party even where the innocent party wishes to do so. In practice, we sometimes see parties excusing a contractual breach because the innocent party values preserving the relationship over the benefit it stands to receive from enforcing the breach. The automatic enforcement may also change the risk profile of a contract, and this higher risk premium may be reflected in the price. All that said, in appropriate use cases, automatic execution may lower costs and reduce "risk premium" element of pricing – an example being that the beneficiary of a direct debit is more confident it will be paid, so will often lower the price in return for payments by direct debit. In many contexts, it may also be possible to include functionality in the code so that the innocent party retains the option of effectively accepting the breach.

For further discussion about the limits of smart contracts from an enforcement and rule of law perspective, please see our article: "Smart contracts and the limits of the 'rule of code'".

AI and smart contracts

In some ways, artificial intelligence – particularly generative AI – could be seen as being at the opposite extreme from smart contracts. For example, smart contracts are best suited to operations characterised by simple, clear logic and defined parameters ("if X, then Y"). These are much more straightforward to "translate" into the very precise instructions of computer code. Tools such as ChatGPT, on the other hand, are designed to handle queries and generate outputs using the language that we as humans use – which is inherently far more ambiguous and highly context-dependent. As such, the two would seem to have relatively little in common.

However, as explained above, the use cases for smart contracts have typically been for operational clauses which the parties wish to automate (so as to reduce costs, increase efficiencies and so on). It is possible that AI could be used in a similar way, alongside smart contracts, to assist with non-operational clauses which may require subjective determinations, such as considering what is reasonable within a certain situation.

Could AI be used to "automate" certain types of expert determination?

For example, in commercial contracts, we often see provision for an expert determination if the parties cannot agree. In situations where the dispute is quite technical and there is a well-established methodology for how to arrive at an appropriate determination, it might be possible for an 'AI expert' to be trained to carry out that task (subject to being provided with appropriate data by the parties). This could be a faster and in some cases cheaper solution than a human expert - in much the same way that a smart contract is typically faster and cheaper (as explained above). However, for reasons outlined below, such software is probably some way off becoming a reality.

Challenges facing AI expert determination

Developers would first need to be persuaded that the market for such specialised software was sufficiently lucrative to justify their investment. They would then need to overcome a number of potentially significant obstacles, including the following:

Training data: Businesses are unlikely to be willing to switch away from human experts unless and until they are satisfied that the results from an AI expert are as good, if not better. This is likely to depend on the AI tool being "fed" with high quality training data – which may be an issue in practice, because most expert determinations are confidential (and even where that is not the case, many well regarded experts may be understandably reluctant to allow their decisions to be used to create an 'AI expert' which could put them out of work).
Regulation: Providers and users of an AI expert would need to comply with the relevant regulatory frameworks – for example, under the EU's AI Act, it seems likely that such software would be regarded as being in the "high risk" category (which not only covers use of AI by judicial authorities to interpret facts and law and apply the law to a set of facts but also AI used "in a similar way in alternative dispute resolution").

Right to review the decision of the AI expert

Parties are also likely to want some form of right to have the determination reviewed – albeit that the scope of this right will need to be fairly limited, to avoid undermining the key intended benefit of having the issue resolved quickly and efficiently. Typically the only ground for review in most expert determination clauses is "manifest error". But if an 'AI expert' were being used, we would also expect to see parties wanting to include a right to review where the AI's decision was one that no reasonable human expert in possession of the same information would have reached.

Glossary

Unless otherwise stated, the definitions provided in the glossary below are extracted from the Law Commission's 2021 report into smart contracts.

How we can help

We have a number of experts who can advise on the legal issues around both smart contracts and AI. For more detailed insights, see:

In addition, we are often assisted by input from our award-winning Legal Technology team, giving our lawyers a valuable insight into how legal advice can be translated into pragmatic solutions that will work effectively in practice.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

Contributor