Three common misconceptions about smart contracts

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, Ethereum’s native cryptocurrency) – this is the digital equivalent of putting money into a vending machine.

So, far from self-executing, smart contracts don’t run unless someone initiates them. And when they do run, they don’t 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. Bitcoin’s 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 isn’t 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 it’s 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, we’ve been able to automate processes ever since we’ve 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 R3’s 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.