- How a smart contract actually runs
- When the code becomes a contract
- Consumer protection: the Australian Consumer Law stays switched on
- Privacy: blockchain data is very hard to delete
- Financial services, AML/CTF and tax: when the token is the product
- Where smart contracts typically go wrong
- When a lawyer earns their fee
- The question to answer before you deploy anything
A smart contract is a self-executing program that runs on a blockchain or distributed ledger. Instead of a person pressing approve or pay, the code automatically performs a defined action once pre-set conditions are met. A payment can be released to a supplier, a licence can be activated, or an escrow balance can be unlocked, all without a human touching a keyboard at the moment of execution.
The appeal for an Australian business is easy to see: routine transactions settle faster, administrative back-and-forth drops away, and the blockchain leaves a durable, tamper-evident record. But the code is only one layer of the arrangement. This guide walks through how a smart contract actually operates, when it becomes a legally binding contract under Australian law, the compliance layers that stay switched on, where the mechanism typically goes wrong, and when a lawyer earns their fee.
How a smart contract actually runs
The mechanism is simple in outline. Someone writes code that states conditions in the form of if-then logic, and deploys it to a blockchain. When the coded conditions are satisfied, the network executes the programmed action and writes the result to the ledger. Because the ledger is designed to be append-only and tamper-evident, each step leaves a time-stamped record that is very difficult to alter or reverse.
The players involved are worth mapping, because each one is a potential point of failure:
- Your business: deploys the contract and defines the rules it will follow. You choose what is automated, what stays manual, and what data the contract is allowed to act on.
- Counterparties: interact with the contract through wallets, orders, approvals or signatures. Their interaction is what usually constitutes acceptance of the arrangement.
- Oracle providers: feed outside data into the contract, such as delivery status, market prices or identity checks. A contract can only act on the data it receives, so an inaccurate or compromised oracle flows straight into execution.
- Network operators and validators: process and confirm transactions. On a public chain there is no single operator to call when something goes wrong; on a permissioned or private network there usually is, which changes your recovery options.
- Regulators and courts: enter the picture when automation crosses consumer, privacy, financial services or anti-money laundering lines, and when the parties fall into dispute about what they actually agreed.
Transparency sits on a spectrum. On public blockchains, transactions are visible to anyone, although the parties may be pseudonymous. On permissioned chains, access is restricted by design. Either way, what is visible depends on the network and on what you choose to record on-chain, so the architecture decision is itself a legal decision.
Australian law has long anticipated machines acting without human review. The Electronic Transactions Act 1999 (Cth) defines an automated message system as a computer program or other automated means used to initiate an action or respond to data messages without review or intervention by a natural person. The definition was written for ordinary e-commerce, but it describes a smart contract neatly.
When the code becomes a contract
A smart contract is not automatically a legal contract. It becomes one only if the ordinary requirements of contract formation are present: an offer, acceptance, an intention to create legal relations, and consideration in the form of value exchanged. Those elements can be expressed in code, in a written agreement that references the code, or in a mix of both.
The intention requirement is assessed objectively. The High Court confirmed in Ermogenous v Greek Orthodox Community of SA Inc (2002) 209 CLR 95 that the question is whether the parties' words and conduct, viewed from the outside, show an intention to be legally bound, rather than what they privately thought. The same lens will be applied to a smart contract: a court looks at the whole arrangement, code included, and asks what the parties objectively agreed to.
Electronic form is not a barrier. Under s 8 of the Electronic Transactions Act 1999 (Cth), a transaction is not invalid merely because it took place wholly or partly by electronic communication, and writing, signature and document-production requirements under Commonwealth laws can generally be met electronically. Each state and territory has a mirror Act doing the same for its own laws.
One provision matters directly for open smart contracts on public chains. Section 15B of the Electronic Transactions Act 1999 (Cth) provides that a proposal to form a contract which is not addressed to specific parties and is generally accessible is treated as an invitation to make offers, unless it clearly indicates an intention to be bound on acceptance. In other words, an open contract sitting on a public blockchain will usually be an invitation to treat, and the deal is formed when a specific party interacts with it on the published terms. This matters for working out when acceptance happens and which version of the terms applies.
No Australian appellate court has yet decided a case squarely about smart contract formation, so there is an element of prediction here. Courts will apply the ordinary principles to the facts, and the safest design assumption is that everything the parties said and published, in code or in prose, is evidence of the bargain.
Most businesses in practice use a hybrid structure. A plain-English master agreement sets out intent, roles, pricing, triggers, governance and a fallback process, while the smart contract handles execution of clear, objective steps. That raises the interpretation question: if the code and the written terms conflict, which one wins? The answer should be drafted in advance, together with a governing law clause and a dispute resolution process. In cross-border transactions, being explicit about which law applies and where disputes will be heard avoids a costly fight about jurisdiction before the merits are ever reached.
Consumer protection: the Australian Consumer Law stays switched on
Automation does not excuse misleading conduct. Section 18 of the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)) prohibits conduct in trade or commerce that is misleading or deceptive or likely to mislead or deceive. The prohibition is not limited to what your smart contract does; it covers everything you publish about it, including website copy, whitepapers, FAQs and marketing materials. Regulators and courts assess those statements the same way for automated products as for anything else.
The Federal Court's decision in ASIC v BPS Financial Pty Ltd [2024] FCA 457 is a working example. BPS promoted a digital token called Qoin, and the court found it had contravened the Corporations Act 2001 (Cth) by issuing a financial product without an Australian financial services licence and had engaged in misleading or deceptive conduct through statements on its website and published documents. Statements about how a token or automated system works are not marketing puff; they are enforceable representations.
Consumer contracts also carry the unfair contract terms rules. Under s 23 of the Australian Consumer Law, an unfair term in a standard form consumer or small business contract is void if the contract cannot operate fairly without it, and since the 2022 amendments, proposing or relying on an unfair term can itself attract civil penalties. Long, one-sided terms buried in a click-through flow are exactly the kind of thing those rules target, so the terms a customer accepts before interacting with your smart contract deserve real drafting attention, not a paste from a template.
Privacy: blockchain data is very hard to delete
If your smart contract collects or handles personal information, the Privacy Act 1988 (Cth) applies to you. The Australian Privacy Principles require you to manage personal information openly, collect only what you need, keep it secure, and allow individuals to access and correct it.
Blockchain design sits awkwardly with some of those obligations. Data written to a public chain is persistent and effectively impossible to remove, which collides with the expectation that individuals can have their information corrected or deleted. The notifiable data breaches scheme in Part IIIC of the Privacy Act 1988 (Cth) adds a practical edge: if there are reasonable grounds to suspect an eligible data breach, an entity must carry out a reasonable assessment within 30 days, and if a breach is confirmed, it must notify affected individuals and the Office of the Australian Information Commissioner as soon as practicable. If personal data is sitting on a public blockchain, there is often no way to contain the exposure once it happens, so the assessment becomes academic.
The practical answer is to minimise what goes on-chain. Store personal information off-chain, record only hashes or tokens on the ledger, and treat pseudonymity as what it is: a screen name, not protection. If your business holds personal data, a privacy impact assessment before deployment is cheaper than a data breach notification after it.
Financial services, AML/CTF and tax: when the token is the product
The moment a smart contract touches payments, tokens, custody or investment-like returns, financial services law can bite. Carrying on a financial services business in Australia requires an Australian financial services licence under s 911A of the Corporations Act 2001 (Cth). ASIC's Information Sheet 225, "Digital assets: Financial products and services", sets out the regulator's view of when digital assets and related products fall within the Corporations Act, and it is the right starting point for any business considering a token, an initial coin offering or a platform that holds or deals in digital assets. The BPS Financial case shows the consequences of getting this assessment wrong: ASIC pursued the operator, and the court found the unlicensed conduct and misleading statements contravened the law.
Anti-money laundering obligations have expanded to match. The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth), as amended in 2024, now regulates services involving virtual assets. The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) defines a virtual asset as a digital representation of value that functions as a medium of exchange, store of value, unit of account or investment, and Part 6A establishes a Virtual Asset Service Provider Register. Digital currency exchanges and wallet providers are within scope, and the new obligations have been phased in from 31 March 2026. If your smart contract moves value, check whether you are carrying on a designated service before you launch, not after AUSTRAC comes calling.
Tax is a separate layer. Since 1 July 2017, digital currency has not been treated as money for GST purposes, so using crypto to pay for goods or services does not create a second GST liability on the currency itself, and digital currency is generally treated as a capital gains tax asset when it is disposed of. The rules are detailed and change, so this is general information only: a tax adviser should look at your specific transactions.
Intellectual property completes the picture. The code itself is protected by copyright under the Copyright Act 1968 (Cth), so confirm you own the code or hold licences for every library and template embedded in it, and think about who owns improvements made by contractors or employees. Your brand, name and logo are separate assets worth protecting with trade marks if the product will be marketed under them.
Where smart contracts typically go wrong
The failure modes are predictable, and most are design problems rather than legal problems:
- Oracle risk: a contract acts on the data it receives, so an inaccurate, delayed or compromised feed produces the wrong execution. If the oracle is wrong, who carries the loss is a question your written terms should answer.
- Bugs and immutability: errors in code, edge cases or integration mistakes can cause unintended outcomes, and once executed, an on-chain transaction is very hard to reverse. A court may be able to order compensation, but it cannot usually press undo on the ledger.
- Governance and upgrades: if the code needs to be paused, patched or upgraded, who can do it and on what conditions? Without clear governance, a bug you can see becomes a bug you cannot fix.
- Transparency: public chains can expose commercial information you never meant to share, while permissioned chains can make it hard for counterparties to verify what happened. Neither extreme is safe by default.
- Pseudonymous counterparties: you may not know who you are dealing with, which makes enforcement against a defaulting party harder and argues for identity verification before high-value transactions.
- Code and text drift: if the written terms and the deployed code fall out of sync, disputes follow. Version control over both is a legal task, not just an engineering one.
When a lawyer earns their fee
The value of legal input concentrates in three places. First, drafting the hybrid master agreement and mapping each automated step in the code to a clause in the written terms, so there is no gap between what the machine does and what the contract says. Second, the regulatory assessment before deployment: whether the arrangement creates a financial product, triggers AML/CTF obligations, carries unfair terms, or puts personal information on-chain. Third, the incident response: a lawyer who already understands the architecture can move quickly if an oracle fails, a breach is suspected, or a counterparty disputes what the code did.
Getting this done early is far cheaper than unwinding a deployed contract or defending a regulator's investigation. A focused review of the contract stack, the compliance layers and the governance rules before launch is the difference between a smart contract that reduces risk and one that creates it.
The question to answer before you deploy anything
The risk concentrates where code meets regulated activity, and where the written terms and the code disagree. Before you deploy, you should be able to answer two questions in writing. First, what happens if the code and the contract say different things, and which one prevails? Second, when something goes wrong, who can stop the machine, and what is the fallback process? If you cannot answer both, the contract is not ready for production, regardless of how well the code is written.
The first step is a map: every automated action the code will take, matched to a plain-English clause that says who is responsible, what the trigger is, and what happens on failure. Have the consumer, privacy, financial services and AML/CTF layers checked against that map before the first transaction runs. A conversation with a commercial lawyer about the structure and the compliance layers is usually all it takes to find the gaps, and it is a much smaller cost than the first dispute.