Three common misconceptions about

smart contracts
Posted on March 7, 2017 by antonylewis2015

There is a lot of misleading commentary about smart contracts, leading to

confusion about what they are and what they can do. Here are three of the
most common myths that I have noticed. This builds on a previous piece, a
gentle introduction to smart contracts.

Myth: Smart contracts are self-executing bits of code

This is not true. Just like you put money into a vending machine to make it
vend, with public blockchains you need to pay to run the contract. With a
blockchain such as Ethereum, you initiate a smart contract by paying it ETH
(Ether, Ethereums native cryptocurrency) this is the digital equivalent of
putting money into a vending machine.

So, far from self-executing, smart contracts dont run unless someone
initiates them. And when they do run, they dont run themselves
somewhere in the cloud they run simultaneously on all machines
participating in validating the blockchain. In public blockchains, that is a lot
of computers (currently there are about 6000 Bitcoin validators according to
Bitnodes, and about 8,000 Ethereum validators according to Ethernodes).
With the same code and the same inputs, the network comes to a
consensus about the results of the code.

Myth: Smart contracts can make payments in normal currencies

I often read blockchain or smart contract examples denominated in fiat

currencies, for example A smart contract can pay out $20. This is not true.

Currently smart contracts can only make payments in cryptocurrencies

(BTC, ETH, etc), and other balances stored on blockchains, sometimes
called coins or tokens. Bitcoins contracts can make BTC payments.
Ethereum smart contracts can make ETH payments, or move around
coin/token balances which are recorded on Ethereum.

Smart contracts cannot make payments denominated in fiat currencies

(GBP, SGD, USD, etc), because digital fiat currencies, in general, reside in
bank accounts, and bank accounts are currently recorded on private
ledgers not distributed ledgers.

So currently, the closest you can get to automated payments is to have a

smart contract do something on a distributed ledger, which is detected by a
separate system (presumably centralised) which then creates a bank
payment message or SWIFT message, which is then fed to the relevant
system or portal, which will then determine whether it is a valid payment or
not, which then creates a debit/credit in the relevant bank ledger. This isnt
that profound or game-changing.

Smart contracts will only be able to make fiat currency payments

when some representation of fiat is put onto a blockchain or distributed
ledger, by an entity with the legal ability to do this, whether its a commercial
bank or central bank or payments institution. This is why getting a
representation of fiat currency on distributed ledger is so important to
realising the promise of smart contracts and distributed ledgers.

Myth: You need smart contracts to automate processes

I often read commentary saying that smart contracts on a blockchain

can automate a business decision (an insurance payout, the results of a bet,
etc) implying that basic business logic was somehow not possible before
smart contracts.

In reality, weve been able to automate processes ever since weve had
computers. If you read something and come to the conclusion that you need
smart contracts to automate trivial logic like make a payment based on a
share price on a particular date, you have been misled. Financial market
trading businesses at investment banks have been making automatic
payments based on share prices or other data for many years now.

So what is the point? What are smart contracts good for?

Smart contracts are computer programs that are shared between

participants and then run independently, simultaneously(ish), then
automatically cross-checked. A distributed ledger guarantees that all
relevant participants have the same code, and also guarantees that the
inputs to the program are identical when the program is run. Participants
should run the program and come to the same conclusion which is
recorded on the distributed ledger.

On a public blockchain such as Bitcoin or Ethereum, all validators run the

code to create a network-wide consensus about the result. On a more
selective distributed ledger such as R3s Corda, only the parties relevant to
the smart contract run the code, and create consensus on the results of the
code between those who are affected.

This gives a level of comfort to all participants that the answers or

conclusion seen in their own systems is the same as what other relevant
participants see in their systems. This in itself is a big deal, as
inconsistencies create risks which can translate into costs.

What about the disruption? Can smart contracts replace the need to trust a
third party? Yes for some functions such as basic fund escrow, a
transparent program can be set up that can make payments based on
certain criteria being met. Participants would audit and trust the code,
instead of trusting (and paying) a third party. And as the technology
matures, more uses for smart contracts will be found. But there are other
parties to consider: who would be running the code, and who would be
feeding in the business-critical criteria?
Upshot: Currently, businesses agree on deals in prose (human language),
perhaps capturing it in a legal contract, and then independently write their
own computer code to automate the logic. Smart contracts on a distributed
ledger can support these business agreements between multiple parties.
Smart contracts replicate the automated business logic across the
participants, ensuring a closer alignment of understanding, a smaller chance
of disagreement, and more robust results.