A Gentle Introduction to Smart Contracts

Whats are people talking about when they talk about smart contracts?
In the context of blockchains and cryptocurrencies, smart contracts are:
- pre written-logic (computer code),
- stored and replicated on a distributed storage platform (e.g.. a blockchain),
- executed/run by a network of computers (usually the same ones running the blockchain),
- And can result in ledger updates (cryptocurrency payments etc).
In other words, they are little programs that execute “if this happens then do that”, run and verified by many computers to ensure trustworthiness.
If blockchains give us distributed trustworthy storage, then smart contracts give undistributed trustworthy calculations.
Smart contracts are one of the functionalities that sets Ethereum apart from other blockchains.
I’ve found three helpful ways to bring them to life:
- Bank accounts with embedded instructions.
- Replacing legal-ese with computer code.
- An actual smart contract example.
1.Bank accounts with embedded instructions.
There are some elements of bank accounts that behave like smart contracts. My bank account has a balance. Every month, I have an automated payment that deducts a fixed amount and sends it to AppleMusic®. If there isn’t enough money n my bank account, the payment fails,I get fined, and a another workflow is triggered.
There are instructions which I have set up which are associated with the account.
This is similar to what a mart contract can do, except that a smart contract running on a blockchain is run by many parties rather than being controlled by a single one.
2.Replacing legal-ese with computer code.

A smart contract is some code which automates he “if this happens then do that” part of traditional contracts. Computer code behaves in expected ways and doesn’t have the linguistic nuances of human languages. Code is better, as there are less potential points of contention. The code is replicated on many computers: distributed/decentralised on a blockchain and run by those computers, who come to an agreement on the result of the code execution.
The idea is that you can have a normal paper contract with all the “whereas” clauses that lawyers enjoy, and then a clause that points to a smart contract on a blockchain, saying “this is what we both agreed to run and we will abide by the result of the code”.
3.How is this different to automated banking payments?
Control
My bank is the ultimate guardian of my bank account. It has complete control, and can arbitrarily add money to my account or subtract it. In a correct set-up blockchain-ecosystem, there should be no single source of control. The distributed layout with consensus mechanisms mean that multiple parties are constantly checking and re-checking and updates to the ledgers, and anything that doesn’t conform to pre-agreed rules is rejected by other participants.
Code
With the bank account, there is some logic creating transactions on a monthly basis. That code sits on one computer and is executed by one party (the bank). There are internal controls and reconciliations, but there is no external validation.

With smart contracts running on a blockchain, the logic is run in parallel on all the participating computers, and the results are compared by all participants. Participants only change their own version of the ledger if they agree on the results. No one can cheat a blockchain, in theory.
Transparency
For all participants in a blockchain ecosystem to run the same code, each verifying the other, the logic of the smart contract must be visible to all. This means anyone can look into a smart contact, and if you like the logic, you can use it. If you don’t, you don’t. There will be smart contracts for general usage, and also very specific smart contracts. The transparency is both pro and con. It’s useful to all stakeholders of the contract to agree on what happens; on the other hand, it’s not just the stakeholders that can see what happens — it’s everyone on the network. Privacy in blockchains is a contentious issue. There are solutions to the privacy-vs-validation tension being discussed, some using zero-knowledge proofs; which will be the subject of another post.
Flexibility
The logic that I can run within my bank account is limited to recurring payments, and maybe some other basic things — I haven’t investigated fully. I can’t, for example, automate a payment from my salary account to my savings account every day it is sunny, then have it all sent back when there is a storm(the ‘saving up for a rainy day’ smart contract).
A so-called “Turing complete” smart contract can do anything that a normal computer can do, though the blockchain version will run much more slowly and be more expensive to run than on a regular computer (depending on the set-up of the blockchain), because ultimately you need to pay for all computers on the network to run the code in parallel.
Why are smart contracts useful?
Shared ledgers can be useful when you have multiple parties, who may not trust each other fully, each comparing their version of events with each other.
For example, when two banks do a complex derivative trade with each other that doesn’t go through a clearing house, it is called an “Over The Counter” or OTC trade. These are agreements between the two banks, without third party validation. These trades are usually bets — i.e. variations of “if this happens before the end of the year then you pay me, else I pay you”.
Both parties have a copy of the original trade documents (the terms and conditions of the trade), and they both have a view on the external dependencies of the trade. They should both, therefore, agree on the outcome of the trade i.e. who wins the bet.
However, this is not always the case.
A mismatch or “break” can occur, where parties don’t agree on the outcome of the trade, due to a number of things:
- A mutual misunderstanding of the initial trade terms
- Confusion due to multiple copies of the original trade terms (usually there is back-and-forth on the wording of the documents, with in-house lawyers on both sides trying to protect their interests)
- Or a disagreement with what actually happened in the external dependencies
With a smart contract, there is only one set of trade terms, written in computer code, which is much less fluffy than legal-ese, and agreed upon up-front. The external dependencies (price of oil, the share price of Apple, etc) can be fed in via a mutually agreed feed. The contract will live on a blockchain and run when an event happens or when the bet expires.
The bet payout can be stored in the smart contract itself: the contract is “primed” by both parties funding the account with their maximum loss, and then the payout occurs at the event. This is potentially cleaner than the existing process, however, there remain privacy issues with other blockchain participants having read-access to this contract and being able to see the terms of a bet between two of their competitors. Also, a lot of trades in financial services are currently done on credit and margined or collateralised; the necessity to pre-find the total payout with the full value of the potential payout, in the currency/asset of the payout would not be attractive.
The future of Smart Contracts
There’s also another secret which the industry isn’t talking about: People like optionality. In many contracts, clauses are written into things on purpose to create a channel for arbitration. For example in a flat rental agreement, wear-and-tear from tenants is acceptable, but major damage needs to be repaired. How does code define these things? Force majeure is present in many contracts to allow for wiggle-room for the parties involved. In a smart contract environment, how does one party call that without abusing it or referring to a human arbitrator? So many grey areas, so many things to figure out…

I have no doubt that in the end, shared ledgers will have a role to play in removing the need for trust among multi-party agreements. Smart contracts make sense for all parties by reducing operational risk and can be thought of as automated trustworthy workflow between parties without a central specific co-ordinator. However, there are a number of hurdles to adoption, as with blockchains in general.
What’s the approach? Forward-thinking law firms should future-proof by tooling up and building in-house capabilities for coding smart contracts. Students with legal aspirations should learn dual skills of law and computer programming. Those who can bridge that gap between law and computer science will be highly sought after in the near future.

