Do you need a smart contract?

What a smart contract is, and whether it is a legal contract

A smart contract is a program stored on a blockchain that runs exactly as written when someone calls it, and on its own it is not a legal contract. On Algorand, smart contracts are called applications and are written in Algorand Python, Algorand TypeScript or a lower-level language called TEAL (Algorand Developer Portal, Smart contracts overview, checked 3 October 2026).

Code can still form part of a binding agreement. In England and Wales, the Law Commission advised the Government on 25 November 2021 that the current legal framework is "clearly able to facilitate and support the use of smart legal contracts", without new legislation. It built on the UK Jurisdiction Taskforce's 2019 statement that smart contracts can in principle create binding obligations, and named deeds and jurisdiction as the two areas needing further work (Law Commission, Smart contracts, checked 3 October 2026).

For an issuer the practical result is two artefacts. The legal agreement is read by people, interpreted by a court and can be varied or waived. The code runs whatever anyone later decides the agreement meant. Where the two disagree, a holder has a claim under the agreement and the code has already executed. Every line of custom code is another place where that gap can open, which is why the first question is whether you need any.

What Algorand does without a smart contract

On Algorand, the controls most tokenisation programmes need are built into the protocol and set by configuring the asset, not by writing code.

A token on Algorand is an Algorand Standard Asset, created with a single transaction. Its total supply and number of decimal places are set at creation, and the documentation states that the total "cannot be changed after creation" (Algorand Developer Portal, Algorand Standard Assets, checked 3 October 2026). An account must opt in before it can receive an asset, so nobody ends up holding units they did not agree to hold.

Four control addresses carry the powers an issuer may need. The freeze address can freeze holdings in any account, and a frozen account can neither send nor receive the asset. An asset can be created frozen by default, so every new holder has to be unfrozen first: this is how an issuer admits only verified holders. The clawback address can move units out of any holder's account, which is how a mistaken or unlawful transfer is corrected. The manager address can change the other addresses or destroy the asset. Leaving an address empty removes that power permanently (same source; Asset operations).

Grouped atomic transactions handle delivery against payment. Up to 16 transactions are submitted as a unit and the whole batch "either passes or fails" (Atomic transaction groups; protocol parameters), so a buyer's payment and a seller's units move together, with no one holding either side in between.

Most of what an issuer needs is configuration. A contract is for what has to wait or calculate.

Trusty Digital's Issuance product issues standard assets on Algorand MainNet in exactly this way, without a custom contract. Each control address is a decision in the issuer's configuration, and a role the issuer does not select is created empty, so no freeze or clawback power exists unless someone chose to create it.

A decision test: does your programme need custom code?

Your programme needs a smart contract only if something must wait, depend on an outcome, sit under rules or follow a formula without anyone's discretion; if none of these applies, the right amount of custom code is zero.

Does anything have to wait? An Algorand transaction is valid for at most 1,000 rounds, under an hour at current block times (protocol parameters). A subscription window, a lock-up or a vesting date that runs for weeks needs either a contract or a person who acts on the day.

Does the result depend on an outcome nobody knows yet? "Release the funds if the target is reached by the deadline" cannot be signed in advance as a group of transactions, because at the moment of signing nobody knows which way it will go.

Must money or units be held in between? If something has to sit somewhere until a condition is decided, either a person or company holds it, with the trust, operational and regulatory consequences that brings, or a contract holds it under rules anyone can read.

Is there a formula across many holders? Pro rata distributions, tiered payouts and conditional vesting can be computed by an administrator under the agreement. A contract makes the calculation verifiable, but every branch of the formula becomes code.

Four questions decide whether a programme needs custom code.

If every answer is no, use the protocol. If one is yes, ask next whether a person can do that job more cheaply and with less risk: a quarterly distribution to forty holders is often better run by an administrator than by code that nobody can easily change. The case for a contract is a job that has to run without anyone's discretion.

Trusty's own planned work shows the yes case. A reward campaign that collects supporters' contributions until a deadline, releases them only if the target is met and refunds everyone otherwise answers yes three times: it waits, it depends on an outcome, and the money has to sit somewhere under rules until the outcome is known. That is why Trusty is designing an escrow contract for it, while the reward tokens themselves remain standard assets.

What a smart contract cannot do

A smart contract cannot see outside the blockchain, cannot exercise judgement, and cannot give anyone a remedy when it goes wrong.

It cannot see the outside world. A blockchain knows its own state and nothing else. Whether rent reached a bank account or a building passed an inspection is invisible to a contract until someone reports it on the chain. That reporter, called an oracle, is a party you have to trust, and price oracle manipulation is second in the OWASP Foundation's list of the ten most critical smart contract weaknesses (OWASP Smart Contract Top 10, 2025). The same trust problem sits at the centre of cross-chain bridges.

It cannot exercise judgement. "Reasonable endeavours", "material adverse change" and "good faith" cannot be written as code. Real agreements contain such terms because the parties could not foresee everything.

It cannot give a remedy. If the code does the wrong thing, the holder's recourse is against a person, under the legal agreement, in a court.

It cannot be changed unless it was built to be. On Algorand, updating and deleting an application are transaction types that the contract's own logic accepts or refuses (Algorand Developer Portal, Applications). A contract that refuses them is permanent, defects included. One that accepts them gives whoever is authorised the power to change the rules for every holder. Both are decisions made before deployment, and both have to be disclosed.

Where custom code goes wrong

Custom code mostly fails through ordinary mistakes, such as a missing permission check, wrong arithmetic or a step that can be repeated, and on a public chain those mistakes are visible to attackers and usually permanent.

In a Trusty Digital analysis of DefiLlama's public database of hacks, 1,293 incidents to 1 October 2026 account for $21.07bn (DefiLlama hacks database, downloaded 3 October 2026; US dollars at the time of each loss). The five categories DefiLlama uses for flaws in contract code (access control, protocol logic, reentrancy, input validation, and token and share accounting) cover 692 incidents, 54% of the total, and $4.88bn. Improper access control alone, code that lets the wrong account call a function, accounts for 141 incidents and $1.19bn. It is also first in the OWASP list.

Value lost by cause, 1,293 incidents to 1 October 2026. Trusty Digital analysis of DefiLlama data.

The largest single cause by value is not code at all. Compromised private keys account for $8.95bn across 158 incidents, 42% of the total. That matters for programmes with no contract too: the freeze, clawback and manager addresses are keys, and whoever controls them holds those powers. Decide who holds each one, and how many people must approve its use, before the asset is created.

Upgrade routes are an attack surface of their own. DefiLlama records 16 incidents and $628m in which attackers hijacked a contract's upgrade mechanism or found one left uninitialised.

Algorand is not immune to contract defects. The protocol checks that transactions obey its rules; it cannot check that a contract's own arithmetic is right. In January 2022 Tinyman, an exchange built from Algorand smart contracts, lost about $3m to a flaw DefiLlama classifies as incorrect share accounting.

Audits help and do not settle the question. Algorand's own development guide recommends internal review and third-party audits, and warns that because the chain is immutable a deployment mistake "can be costly or permanent" (Algorand Developer Portal, Development lifecycle). An audit is a time-limited review by people: evidence of care, not a guarantee.

If you write one: keeping the code and the agreement in step

Where a programme genuinely needs a contract, most of the work that protects holders is governance rather than engineering.

The agreement governs. State in the documents that holders' rights come from the legal agreement and that the code is a means of performing it. Then check that it does.

One person owns the reconciliation. A named person checks that every change to the agreement is reflected in the code, and the reverse. In most failures of this kind, nobody held that job.

Upgrade power is disclosed. If the contract can be updated, say who can update it, by what process and with what notice. Record every update as you would a change to the articles.

The failure path is tested as hard as the success path. In an escrow, the refund after a missed target is the branch that runs least often and matters most. Test it with the same care as the release.

The contract stays small. Put in code only what the protocol cannot do. Issue the tokens as standard assets and settle with atomic groups, so the contract decides when something may happen and the protocol does the rest. Every branch you avoid is one fewer to audit.

The same questions about who can change the rules arise in decentralised autonomous organisations, where code and members' rights also have to be kept in line.

Is a smart contract right for your programme?

A smart contract is right when the arrangement has to wait, decide on an outcome or hold assets under rules, and nobody should have discretion over the result; otherwise the protocol does the job with less code, less cost and less risk. Start from the legal structure and work towards the code, never the reverse, as What is asset tokenisation? sets out.

Questions people also ask

Is a smart contract legally binding in England and Wales? It can be. The Law Commission concluded in 2021 that existing law can support smart legal contracts without new legislation. Whether a particular arrangement is binding depends on the usual tests of contract formation, which a solicitor should confirm for the facts.

What is the difference between a smart contract and a legal contract? A legal contract is an agreement that a court interprets and can vary or set aside. A smart contract is code that runs as written. A programme can use both, with the agreement setting the rights and the code performing some of them.

Can a smart contract on Algorand be changed after deployment? Only if its own logic accepts an update transaction. Whoever is authorised to send that update holds power over the rules, so the choice should be made deliberately and disclosed.

Do I need a smart contract to tokenise an asset? Usually not on Algorand. Issuance, supply, transfer restrictions, corrections and settlement against payment all work at protocol level. A contract becomes necessary when something must wait for a deadline or depend on an outcome.

The short version

Most tokenisation programmes should write less custom code, not more. On Algorand, a fixed supply, approved-holder restrictions, corrections and settlement against payment come from configuring the asset, and the keys behind those controls deserve more attention than any code. A contract earns its place when money or units must wait under rules for a deadline or an outcome, as in an all-or-nothing campaign with refunds, and then it should be small, tested on its failure path, and governed by the legal agreement.

To see where these choices sit in a full project, read What is asset tokenisation?.

This article is general information, not legal, tax or investment advice.