Smart contracts and the Electronic Transactions Act 2010
Read the PDF edition (2 pages)
Can code be a contract?
A smart contract is a program on a blockchain that executes predetermined actions when specified conditions are met. Whether it is also a contract in law depends on whether the ordinary elements of offer, acceptance, consideration and intention to create legal relations are present in the parties' dealings. Singapore law has no rule that a contract must be in natural language. The Electronic Transactions Act 2010 provides that information is not denied legal effect solely because it is in electronic form and that contracts may be formed by electronic communications. A contract formed by the interaction of an automated message system and a natural person, or between automated message systems, is not denied validity solely because no natural person reviewed each action.1
The Act gives three further tools. Section 13 attributes an electronic communication to the person who sent it or on whose behalf it was sent, which allows a transaction signed with a private key to be attributed to the key-holder.2 Section 16 allows a natural person who makes an input error in an exchange with an automated message system to withdraw the erroneous portion. The conditions are that the system gave no opportunity to correct the error and that the person notifies it promptly without having benefited from it.3 Section 16 is a narrow consumer-protection provision. It does not help a trader who misprices an order on an exchange that offered a confirmation screen. The 2021 amendments added Part 2A on electronic transferable records, which implements the UNCITRAL Model Law on Electronic Transferable Records and allows bills of lading, promissory notes and similar instruments to exist in electronic form where a reliable method establishes exclusive control.4 The First Schedule continues to exclude wills, the creation of certain trusts and powers of attorney, and contracts for the disposition of immovable property from the Act's recognition provisions, which matters for the succession questions in Chapter VII.5
Code, intention and the governing text
Three problems recur. The first is intention. Many on-chain interactions, such as swapping tokens on an automated market maker, involve no identified counterparty and no communication beyond the transaction itself. Whether a contract arises between the user and the liquidity providers, between the user and the protocol's governing entity, or with nobody at all is a question that Singapore courts have not answered. The Swiss Federal Council's analysis of decentralised finance, discussed in Part D, Chapter V and Part E, Chapter IX, concludes that in many cases there is no contractual counterparty. The user is then left with claims in unjust enrichment or tort if anything goes wrong. A Singapore court would in my view reach the same conclusion on the same facts.
The second problem is the relationship between code and natural-language terms. Where a token sale is documented by a purchase agreement and executed by a smart contract, the two may diverge. The agreement may promise a vesting schedule that the contract does not implement, or the contract may contain a function allowing the issuer to mint further tokens that the agreement forbids. The sensible drafting answer is a hierarchy clause stating which prevails. In its absence a court will construe the agreement and treat the code as the mode of performance, so that a divergence is a breach by the party responsible for the code. The third problem is defects in code. A bug that allows a third party to drain a pool is an event the parties did not intend. Whether the loss falls on the user, the developer or the governing entity depends on contract where there is one and on tort where there is none (Chapter VI).
Practice note
A client who deploys a smart contract that other people will use should publish natural-language terms alongside it and should link to them from the interface and, where practical, from the contract's metadata. The terms should state who the contracting parties are, which text prevails if code and prose diverge, what the user accepts as to the risk of bugs, and which law and forum govern. A client who uses someone else's smart contract should assume that no contractual counterparty exists unless the terms say otherwise, and should size the exposure accordingly.
Notes
- Electronic Transactions Act 2010, ss 6 (legal recognition of electronic records), 11 (formation and validity of contracts) and 15 (use of automated message systems for contract formation). Section 2(1) defines an automated message system as a program or automated means used to initiate an action or respond to data messages without review by a natural person. ↩
- Electronic Transactions Act 2010, s 13 (attribution of electronic communications). ↩
- Electronic Transactions Act 2010, s 16 (error in electronic communications), implementing art 14 of the UN Convention on the Use of Electronic Communications in International Contracts 2005. ↩
- Electronic Transactions (Amendment) Act 2021, inserting Part 2A (electronic transferable records) into the Electronic Transactions Act 2010 with effect from 19 March 2021. ↩
- Electronic Transactions Act 2010, s 4 and First Schedule (excluded matters). ↩
For general information only. This article does not constitute legal or tax advice, does not replace advice on an individual case and creates no lawyer-client relationship. It reflects the legal position as of October 2026.