Smart legal contracts in Australia, what they are and whether they're enforceable

Your supplier's system sends an automatic payment the moment a delivery sensor at your warehouse confirms the goods arrived, with no invoice, no phone call, and no one checking the paperwork. If that behaviour reflects an agreement between you and the supplier, you are already dealing with a smart legal contract. Businesses are increasingly being asked to accept terms like these, and it is worth knowing what they actually are, whether they hold up in Australian law, and where the risk sits when the code does something unexpected.

What is a smart legal contract?

A smart legal contract is a legally binding agreement in which some or all of the terms are defined in, and performed automatically by, computer code. The UK Law Commission, which has done the most detailed official work on the topic, defines them as legally binding contracts in which some or all of the contractual terms are defined in and performed automatically by a computer program. In plain terms: the parties still reach a real agreement, but parts of its performance are run by software rather than by people.

It helps to separate this from the looser term "smart contract". In technology circles, a smart contract is simply code that executes automatically, often on a blockchain, when certain conditions are met. That code may not be a contract in any legal sense at all. It may have no identifiable parties, no offer and acceptance, and no intention to create legal relations. The label "smart legal contract" exists precisely to mark the difference: an agreement the law would recognise, with code doing some of the work.

In practice these arrangements sit on a spectrum. At one end is a conventional written agreement with a clause saying payment will be made automatically once delivery is confirmed. At the other is an arrangement recorded entirely in code, with no natural language at all. Most commercial uses fall in the middle: a written contract with code performing defined steps.

Whatever form the arrangement takes, the ordinary building blocks of a contract must be present for it to be enforceable: offer and acceptance, consideration, and an intention to create legal relations, with terms that are sufficiently certain. Code does not replace those elements. It performs them. If the code is all there is, a court will still need to be satisfied that the parties actually agreed to be bound.

Are smart legal contracts enforceable in Australia?

The starting point is statutory. Section 8 of the Electronic Transactions Act 1999 (Cth) (the ETA) provides that, for the purposes of a Commonwealth law, a transaction is not invalid merely because it took place wholly or partly by means of electronic communications. Each state and territory has a mirror law to the same effect. There is no general requirement that a contract be on paper.

The ETA also speaks directly to automation. Under s 15C, a contract formed by the interaction of automated message systems, or between an automated system and a natural person, is not invalid, void or unenforceable on the sole ground that no natural person reviewed or intervened in the individual actions carried out by the systems. That is the provision that most clearly contemplates self-executing arrangements. Australian statute law already accepts contracts that form and perform themselves.

So the blunt answer is that smart legal contracts are capable of being enforceable in Australia, in the same way any electronic contract is. A court would apply the ordinary rules of formation, interpretation and remedies. What the law has not yet done is define a smart legal contract, or settle how a conflict between the natural language and the code should be resolved. No Australian court has squarely ruled on one, and there has been no Australian equivalent of the UK Law Commission's review, which concluded in November 2021 that the existing law of England and Wales could accommodate smart legal contracts without legislative reform.

The practical consequence is that enforceability in a particular case will usually turn on interpretation. If the written terms and the code disagree, which one expresses what the parties actually agreed? The safest drafting answers that question in advance.

Who is liable when the code gets it wrong?

The realistic risk is not that the whole contract is unenforceable. It is that the code performs something other than what the parties agreed. Take a common example: the written agreement says payment releases only after the buyer inspects the goods, but the code releases payment the moment delivery is confirmed, so the money goes out before anyone has looked at the shipment.

There is no Australian authority that says where that loss falls. A court would work through the ordinary tools: what the contract says, who wrote or selected the code, what warranties the developer gave, whether a party misrepresented how the automation worked, and whether anyone was negligent. If the code came from a third-party vendor, the vendor's licence or services agreement will usually allocate much of this risk. That agreement deserves as much attention as the contract itself.

The ETA's only error provision, s 15D, deals with a narrower situation. A natural person who makes an input error while dealing with an automated system may withdraw the affected communication, provided they notify the other party promptly and have not received any material benefit from the goods or services. The provision does not cover a software bug or a bad data feed. That is where the written contract has to step in.

A well-drafted contract should say what happens when the code fails or produces a result inconsistent with the written terms, including reverting to manual performance; who warrants that the code matches the agreed terms; who carries the risk if the data feeding the code is wrong; and how errors are corrected and disputes resolved. Leaving those questions open is how a malfunction becomes a lawsuit.

How does a smart legal contract know what is happening in the real world?

Code can only automate what it knows. For a payment to release on delivery, something has to tell the system that the delivery happened. That information comes from connected devices: sensors at a warehouse, GPS in a truck, temperature monitors in a shipment, payment messages from a bank. The general term for these devices is the internet of things, and third-party services called oracles can feed verified data into the system.

Consider a supply agreement that requires goods to arrive by 6 am. The supplier's truck enters the buyer's yard, a gate sensor records the time and transmits it to the system, and the smart legal contract compares that time with the term. It either records the delivery as on time or triggers the breach provisions automatically. Nobody keys in the arrival time, and that is the point.

As connected devices become cheaper and networks such as 5G carry more data more quickly, these data feeds become practical for smaller businesses, not just large logistics operators. But the dependence cuts both ways. Performance is only as good as the data. If the sensor is wrong, or the network drops out, the code performs on wrong facts. Who operates the devices, what counts as reliable evidence of an event, and what happens when a feed fails are allocation questions the contract should answer before the system goes live.

What is changing in skills and regulation?

Building and maintaining these systems takes people who understand both code and contract. Australia's technology workforce is growing toward a target of 1.2 million technology jobs by 2030, a goal set by government and industry and tracked by the Tech Council of Australia. Demand for developers who can work alongside legal teams is part of that picture. Lawyers, for their part, are increasingly expected to review automation before it is deployed rather than after something goes wrong.

On regulation, no Australian regulator has yet issued guidance on smart legal contracts themselves, and no statute defines them. The attention so far has been on digital assets. ASIC's Information Sheet 225 explains when crypto and other digital assets amount to financial products under the Corporations Act 2001 (Cth) and trigger licensing obligations. The UK Law Commission's conclusion that existing contract law could cope suggests Australia is likely to develop along similar lines: regulation around the edges, such as financial products and consumer protections, rather than a new law of smart contracts.

How a commercial lawyer helps you use smart legal contracts safely

The judgement calls in this area are exactly what a lawyer is for. Before you deploy automation, someone should check the code, or the vendor's description of it, against the terms you actually agreed, so the automated performance matches the deal. The contract itself should say what happens when the code and the words conflict, who warrants the code, and who carries the risk of malfunction and bad data.

When you are on the receiving end of a counterparty's smart contract terms, the question is what you are actually agreeing to. Automated payment and termination mechanisms can bind you faster than a person would, and often with less room to argue about it later. Artificer Legal's commercial team can review proposed automation, draft the clauses that allocate the risks described above, and help you work through the vendor agreements that sit behind the code.

The code-contract gap is the risk to manage

The most common misstep is treating the code as if it were the agreement. It is not. A smart legal contract is an ordinary contract with software performing parts of it, and the danger is the gap between what the parties believe they agreed and what the code actually does. Automated performance is fast and hard to unwind. A divergence that would be a simple administrative fix in a paper contract becomes a payment or delivery that has already happened. The contract that anticipates that gap, and says what happens when it opens, is the one that will hold up.

In short: a smart legal contract is a legally binding agreement whose terms are partly defined and performed by code; the ETA confirms that electronic and automated contracts are valid; the genuinely unsettled questions are interpretation and liability when code diverges from the agreed terms; these systems depend on real-world data; and both the skills base and the regulation are still developing. If you are considering automation, or have been asked to accept a counterparty's automated terms, have the agreement reviewed before the code starts running.