Smart Contracts In New Zealand: Enforceability, Legal Risks And Key Terms

Smart contracts are getting a lot of attention in New Zealand because they promise something every small business wants: faster transactions, fewer manual steps, and less room for misunderstandings.

But once you move from "cool tech" to "we're actually relying on this to pay suppliers / deliver services / release funds", you're in legal territory. And the key question becomes: are smart contracts enforceable in New Zealand, and what risks do you need to manage before you use them?

In this guide, we'll walk through what a smart contract is (in plain English), how NZ contract law applies, common legal risks for businesses, and what you should build into your smart contract setup so you're protected from day one.

What Is A Smart Contract (And What Isn't It)?

A smart contract is a piece of code that automatically performs certain actions when pre-set conditions are met.

For example, you might set up a smart contract so that:

• a payment is released automatically once a delivery is confirmed;
• a subscription renews and charges the customer on a schedule;
• a refund is triggered if a service isn't provided by a certain date;
• a revenue share is distributed automatically between partners.

It's easiest to think of smart contracts as "if this happens, then do that" rules that run automatically.

A Smart Contract Is Not Automatically A "Legal Contract"

This is where businesses can get caught out.

A smart contract (code) can implement an agreement, but it doesn't automatically mean the parties have a legally enforceable contract in the traditional sense. In practice, many commercial arrangements end up being a mix of:

• legal terms written in normal language (e.g. a service agreement), and
• smart contract code that automates parts of performance (like payments or access).

That "mix" is often the safest approach for small businesses, because when something goes wrong, your written terms can fill the gaps that code can't deal with (like disputes, mistakes, and edge cases).

Are Smart Contracts Enforceable In New Zealand?

In many cases, yes - smart contracts can be enforceable in New Zealand if they meet the usual requirements of contract law.

New Zealand doesn't have one single "Smart Contracts Act" that decides enforceability. Instead, we generally look at standard contract principles, as well as the rules that support electronic contracting and electronic records.

What Makes A Contract Legally Binding In NZ?

At a high level, a contract is usually enforceable if there is:

• offer (one party proposes terms),
• acceptance (the other party agrees),
• consideration (something of value is exchanged),
• intention to create legal relations (it's meant to be binding), and
• certainty of terms (the obligations are clear enough).

If a smart contract arrangement can show those elements, it may be enforceable - even if some or all of the "terms" are embedded in code.

Do We Need A Written Contract Or Signatures?

Not always. Many contracts in NZ can be formed without a signature, including online contracts, email agreements and click-wrap terms.

In addition, the Electronic Transactions Act 2002 supports the use of electronic communications and (where the Act applies) allows legal requirements for "writing", "signatures" and "originals" to be met electronically, as long as certain conditions are satisfied.

However, some transactions have additional formality requirements (for example, certain dealings with land), and even where a signature isn't strictly required, having clear written terms makes disputes much easier to manage.

If your arrangement still includes a signed document (for example, a master agreement plus a smart contract schedule), make sure your signing process is clean and consistent. If you're unsure about execution steps, it helps to confirm how to sign a contract properly for your situation.

Smart Contracts And The Contract And Commercial Law Act 2017

In some business-to-business settings, the Contract and Commercial Law Act 2017 (CCLA) may be relevant - particularly where your arrangement overlaps with areas the Act covers (for example, aspects of sale of goods and certain commercial remedies).

A smart contract doesn't "avoid" these laws. If your smart contract is used to sell goods or provide services, the legal rules that normally apply can still apply - even if the transaction is automated.

Key Legal Risks For Businesses Using Smart Contracts

Smart contracts can be efficient, but they're also unforgiving. If the code executes, it executes - even if the real-world situation is messy or unfair.

Here are some of the biggest legal risks we see for small businesses.

1) The "Code Is Law" Problem (Mismatch Between Code And Commercial Intent)

A classic smart contract risk is a mismatch between:

• what you and the other party thought the deal was, and
• what the smart contract actually does.

For example, you might agree "payment is released when delivery is made", but the code might rely on a particular data input that doesn't reflect reality (or can be manipulated). If the code releases funds early (or doesn't release them at all), your dispute is no longer just commercial - it becomes technical and legal.

This is why many businesses use a written Service Agreement (or supply terms) to set the legal intent, and then treat the smart contract as the performance tool.

2) Mistakes, Bugs And Unintended Outcomes

Traditional contracts can be interpreted and adjusted by negotiation (or a court) when something goes wrong. Smart contracts, by design, may execute automatically even where there's a mistake.

That raises questions like:

• Can you pause performance if there's an obvious error?
• Who bears the risk of a coding bug?
• What happens if the wrong wallet/account is used?
• Can you reverse a transaction?

From a legal perspective, issues like mistake, misrepresentation and remedies may come into play - but you'll be in a much stronger position if your written terms clearly allocate responsibility and set an agreed process for errors.

3) Consumer Law Exposure (If You Sell To Consumers)

If your business sells goods or services to consumers (even if the transaction is "automated"), you still need to comply with:

• Fair Trading Act 1986 (misleading or deceptive conduct, representations in advertising), and
• Consumer Guarantees Act 1993 (guarantees around acceptable quality, fitness for purpose, and remedies).

Smart contracts can create consumer law headaches if they:

• make it hard to provide refunds where required;
• auto-renew subscriptions without clear disclosure and consent;
• lock customers into outcomes that conflict with their legal rights.

In other words, automation doesn't remove consumer obligations - it can amplify the risk if the "machine says no" when the law says "you must".

4) Privacy And Data Security Risks

Many smart contract setups involve collecting, processing or linking data (even if it's "just" identifiers). If you're handling personal information (for example, customer records tied to transactions), you need to think about compliance with the Privacy Act 2020.

Even if the smart contract itself doesn't store personal information, your wider system might (for example, your website, CRM, or payment flow). It's usually worth having a properly tailored Privacy Policy and making sure it matches what your tech actually does.

5) Jurisdiction And Cross-Border Issues

Smart contracts often involve parties in different countries, global platforms, and decentralised infrastructure.

That can raise practical questions like:

• Which country's law governs the contract?
• Where can disputes be heard?
• How do you enforce rights against an overseas counterparty?
• Are there sanctions, tax, or regulatory issues depending on location?

If your small business is contracting with overseas suppliers, developers, or customers, a clear governing law and jurisdiction clause is not a "nice to have". It's one of the simplest ways to avoid expensive arguments later.

6) Regulatory Risk (If Cryptoassets, Tokens Or Financial Services Are Involved)

If your smart contract involves cryptoassets/tokens, holding or transferring value for others, or anything that looks like issuing or dealing in financial products, you may also need to think about regulatory compliance - even if the arrangement is automated.

Depending on the model, this can include obligations under the Anti-Money Laundering and Countering Financing of Terrorism Act 2009 (AML/CFT), and potentially financial markets and financial services regulation. The details are highly fact-specific, so it's worth getting advice early if you're building anything beyond a simple internal automation tool.

What Should Businesses Include When Using Smart Contracts?

If you're going to rely on smart contracts in your operations, think of your legal setup like guardrails. You're aiming to:

• make the commercial deal clear;
• reduce the chance of disputes;
• give you options if the technology fails; and
• avoid locking your business into a bad outcome with no off-ramp.

Here are the key items many NZ businesses should include.

1) A Written "Wraparound" Agreement (That Sits Above The Code)

For most small businesses, it's risky to rely on code alone. A written agreement (even a short one) can clarify the commercial intent and cover what the smart contract can't.

Depending on your use case, that might be:

• a Goods and Services Agreement for supply and delivery arrangements;
• a service agreement for ongoing services or subscriptions;
• terms and conditions for online customers (especially if you're operating an e-commerce flow).

Your written terms can also define which parts are automated and which parts require human approval.

2) Clear Definitions (So Everyone Agrees On What Triggers What)

Smart contracts run on triggers. Your legal document should define those triggers in plain language, including:

• what counts as "delivery", "acceptance", or "completion";
• what evidence is required (and who provides it);
• timeframes and time zones;
• what happens if data is missing or delayed.

This is especially important if the smart contract relies on external inputs (for example, a system or data feed that tells the contract when to execute). If the trigger is vague, you'll end up arguing about it after the fact.

3) An Audit, Testing And Change-Control Process

From a legal risk point of view, you want to be able to show that you took reasonable steps to avoid avoidable failures.

In your documentation (and your internal processes), consider including:

• testing requirements before deployment;
• an audit process (especially for high-value transactions);
• who can deploy updates or patches;
• how changes are approved (and how parties are notified);
• version control and record-keeping.

If you're working with a developer or external provider, this is where having clear contractual obligations around deliverables and acceptance testing becomes critical.

4) A "Pause", "Kill Switch" Or Manual Override (Where Appropriate)

Not every smart contract should be unstoppable.

For many real-world business arrangements, you'll want a mechanism to:

• pause execution if there's suspected fraud or an error;
• stop payments if a dispute is raised;
• manually approve a step for high-risk transactions.

This needs to be handled carefully, because too much control can undermine the "automatic" benefit (and may raise trust concerns). But from a business risk perspective, having an agreed circuit-breaker can save you from a very expensive mistake.

5) Dispute Resolution Clauses That Work In The Real World

If a smart contract executes in a way one party says is wrong, you need a pathway to resolve it.

Your written agreement should cover things like:

• notice requirements (how a dispute is raised, and how quickly);
• an escalation process (negotiation first, then mediation, then court/arbitration if needed);
• whether performance is suspended during a dispute;
• how evidence will be assessed (including technical evidence).

These provisions are often the difference between "we sorted it out in a week" and "this dragged on for months".

6) Liability Allocation And Limits

When you automate performance, you're also automating risk. Your agreement should clearly allocate who is responsible for what, including:

• bugs or vulnerabilities in the code;
• losses caused by incorrect inputs;
• downtime or service interruptions;
• security incidents (including unauthorised access).

Many businesses also include limits on liability (where appropriate and enforceable) and exclude certain types of loss. The right approach depends on your industry, whether you deal with consumers, and how much bargaining power each party has - so it's worth getting tailored advice before you "copy-paste" a clause from somewhere else.

7) Confidentiality And IP Ownership (Especially If You're Building Custom Code)

If you're having smart contracts developed for your business (or collaborating with another business on a shared tool), don't leave ownership unclear.

You'll want to document:

• who owns the smart contract code;
• whether your business gets an assignment or a licence to use it;
• what happens to the code if the relationship ends;
• confidentiality obligations around business logic, pricing, customer data and technical details.

This is often handled through a combination of IP clauses and a Non-Disclosure Agreement at the start of discussions.

Smart Contracts And Business Structure: Why It Matters For Risk

Smart contracts can change your risk profile, particularly if you're dealing with high-value payments, ongoing subscriptions, or sensitive data.

That makes it a good time to check whether your business structure still makes sense.

Sole Trader Vs Company (The Liability Question)

If you operate as a sole trader, you and your business are legally the same "person" - which can expose your personal assets if something goes seriously wrong.

If you operate through a company, you generally have limited liability (with some important exceptions), which can be helpful when you're taking on higher-risk commercial arrangements.

This doesn't mean "smart contracts = you must set up a company", but it's a sensible prompt to think through your legal foundations, especially if you're scaling. Depending on where your business is at, you might consider setting up a company and putting the right governance documents in place, such as a Company Constitution.

Working With Co-Founders Or Investors

If you're building a product that uses smart contracts (rather than simply using them as a tool), it's common to bring in co-founders, contractors, or investors. That's when clarity around decision-making, IP ownership and exits becomes crucial.

This is often documented in a Shareholders Agreement, especially once shareholdings and governance start to matter.

Key Takeaways

• Smart contracts can be enforceable in New Zealand, but they still need to satisfy normal contract law principles (offer, acceptance, consideration, intention, and clear terms).
• For most small businesses, relying on code alone is risky - a written agreement alongside the smart contract helps define intent, allocate risk, and handle real-world disputes.
• Common smart contract risks include coding bugs, mismatch between code and commercial intent, privacy compliance issues, consumer law exposure, and cross-border enforcement challenges.
• Your smart contract setup should clearly define triggers, build in testing and change control, include dispute resolution steps, and allocate liability for errors, security incidents, and third-party inputs.
• If you're building or licensing smart contract code, you should document IP ownership and confidentiality early, rather than assuming it's "obvious".
• Using smart contracts can increase business risk, so it's a good time to review your business structure and key documents to ensure you're protected as you grow.

If you'd like help reviewing or drafting the legal terms around your smart contracts (or setting up the right agreements around payments, IP, privacy and risk), you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.