What Exactly is a Smart Contract?

By Thio Shen Yi, SC
and Kevin Elbert

What these obscure lines of code actually do, and how did they precipitate the spectacular US$45 billion collapse of TerraUSD and Luna?

The esoteric world of cryptocurrency was sent into a tizzy this May when the supposed “stablecoin” token TerraUSD (UST), ostensibly pegged at US$1, suddenly tumbled and became worthless. US$45 billion in value evaporated over two weeks, wiping out entire life savings. One Singaporean has reportedly sued UST founder Do Kwon for fraud.

The UST collapse also led to the failure of its sister token, Luna. UST and Luna are algorithmically linked – for every UST minted, the equivalent of US$1 in Luna will be destroyed, and vice versa. That is how UST’s value is held “stable” in theory: by increasing or decreasing UST’s supply through its coupling with Luna, whose price is, on the other hand, market determined. These transactions are automatically executed through a smart contract.

So, whenever UST was valued at more than US$1, traders would incentivised to burn Luna and mint UST, selling the UST. This process would increase UST supply, correcting its price back to US$1.

The UST meltdown was catalysed by various withdrawals of UST totalling approximately US$500 million. There was also a bank run on Anchor – a UST-based high-yield staking product – with users rushing to swap out of UST. Traders then redeemed UST for Luna, which they sold, leading to its significant price drop, which necessitated more Luna being minted for each UST burned, creating a “hyper-inflationary loop” in Luna’s supply. Because of the smart contract’s architecture, a “death spiral” became inevitable.

Is a smart contract truly smart? Is it even a contract in the first place?

Smart contracts are self-executing lines of code that are carried out when specific conditions are met. They normally comprise “if-then” statements, which in computing mean that “if” a condition is met, “then” an action is performed.

These lines of code are distributed and decentralised across the blockchain network, can automatically – without any middleman – perform and execute the transactions, which are immutable and irreversible.

In reality, a “smart contract” is a misnomer – it is not a contract; at least not in the way one normally understands (or what the law requires) a contract to be. Under Singapore law, a legally binding and enforceable contract requires these elements to be present: offer, acceptance, consideration (legal-speak for something of value that is exchanged between parties) and an intention to create legal relation. None of these is present in a “smart” contract.

The classic example of a “smart contract” is a vending machine. This is not a contract. You insert the required coins into the vending machine, and the product is theoretically dispensed.

Here, “if” you had paid 50 cents (the condition), “then” the machine dispenses a can of soda (the action).

It is that easy. But does it make a smart contract smart? Or a contract? Not really.

While a smart contract’s immediate execution is an attractive proposition, the transaction’s irreversibility is not always convenient – you cannot return the product and get your money back. Assuming that a transaction had been accidentally or unintentionally executed, what recourse does one have? Assuming that there is a dispute as to the terms of the contract, how is it stopped? Ultimately, an off-chain intervention is required, for example, the recipient has to voluntarily take steps to reverse the transactions.

That’s the rub.

If the recipient refuses to comply, off-chain resource (usually legal) may be required. Using the vending machine example, if the product gets stuck, you have to call the hotline and ask for a refund. In a blockchain transaction, there is no hotline to call because you might not even know the identity of the recipient.

Limitations of a smart contract

Implicit from the above is the importance of the data input. A smart contract’s performance depends on the triggering of specific conditions. But the limitation is that the code can only identify objective conditions – code cannot deal with subjectivity and struggles to determine usual contractual considerations such as reasonableness, good faith, best endeavours and material adverse change. This limits its utility of contracts to those that can be expressed in “if-then” statements. And even then, it cannot deal with issues of termination, breach, recession, frustration, misrepresentation – all daily fodder to the civil litigator.

A smart contract, by design, also operates in a closed loop. It is unable to obtain information from the “real world”, for example, the price of certain stocks, or a location’s temperature at a certain time. This is a feature of the system, not a bug. The blockchain is meant to be a closed loop: introducing and relying on external information could jeopardise consensus, which is important for security and decentralisation.

A way around it is to use oracles. Oracles act as a bridge that can digest external information into a format that a blockchain can understand and if conditions are met, execute the transactions. But oracles are not always wise, and give rise to the “oracle problem”, that is, if the oracle is compromised, so is the entire contract. The conundrum is this: the parties to the smart contract must trust the outside data source, but there is no one single source that is perfectly trustworthy. While the use of multiple oracles does go towards mitigating the risk of corrupted data from one source, there remains a threat of modification or falsification of data from the oracle by a malicious third party hacker.

Finally, as with all things digital, there are always issues with bugs and security. It was reported that due to a “simple smart contract error”, US$34 million in Etherium (ETH), a cryptocurrency, was locked away during the launch of the Akutars non-fungible token (NFT) of artist Micah Johnson. (Very simplistically put, NFTs are tokens that owners rely on to prove ownership over an asset.) Even when there were “some sort of safeguards in place”, an anonymous user named USER221 exploited the vulnerabilities in the smart contract, halting both ETH withdrawals and refunds.

When the Akutars NFT was already up and running, another bug was discovered in smart contract. The smart contract “failed to account for multiple NFT mints within the same transaction” and the contract requires certain line of codes to line up properly to enable any withdrawals. This error in the codes of the smart contract caused 11,539 ETH (worth about US$34 million) to be permanently locked in the smart contract.

Why smart contracts can be useful

What are we to conclude? With all its limitations and vulnerabilities, is a smart contract as smart as people think it is? Perhaps not. But this does not diminish its utility. For simple transactions that operate on a conditional statements, a smart contract may be useful – where the value is low or where the input and the conditions required to trigger the smart contract are objective and easily determined. A smart contract could provide value for the most traditional type of insurance cases, i.e. “if X, then Y” (though X will probably have to be determined by an oracle); or in a closed blockchain ecosystem, for example, crypto-assets conversion, yield farming, and so on.

In 2017, AXA launched Fizzy, an automated parametric flight delay insurance platform. It records and connects information of policyholders’ flight details to global air traffic controller databases to check on the status of the flights. If a policyholder experiences a delay of two or more hours, as reported by the airport, the smart contract automatically triggers the mechanism for paying the insured.

But we are certainly far from making a smart contract the default platform to transact. Contracts, like human beings, are nuanced, and complex. That is good news for lawyers.


TSMP law corporation