My last article examined smart contracts through the lens of a canonical vending machine example to explain how blockchains provide a mechanism for automating trust. I will now zoom out and examine some high level design patterns found in the application of smart contracts. Blockchain based smart contract systems generally fall into three broad categories: blockchain native, smart property and algorithmic management. I will start with some common patterns found in blockchain native applications.

Blockchain native applications are typically financial in nature and focus on rules around changing the ownership of a cryptocurrency itself. For example, in Bitcoin even a simple payment is accomplished through a smart contract. Every bitcoin balance on the blockchain is associated with a script (ie. smart contract) that defines what conditions must be satisfied to change the ownership of that balance. The simplest spending condition is that the current owner of the public key associated with the balance must supply an associated signature in order to assign a new public key to it. If the new public key corresponds to a private key controlled by a different person, then we say the bitcoin has been spent. Control of it has moved to a new person by changing the smart contract that governs that balance.

Smart contracts can include additional conditions to accomplish more complex tasks. For example, you can add a condition that restricts spending until some amount of time has passed. This works like a time vault in a convenience store where even if a thief has the combination, it won’t unlock the safe until until the next morning. In the case of smart contracts this sort of condition is often used to add a refund condition when two parties are negotiating a new contract. Assume two people create a contract that locks funds at a particular address so that it will require both to sign to spend from it. The first person to transfer their funds into this address would have their funds locked and unspendable if the second person disappears. To solve this, the two parties first sign a contract that allows the value to be refunded from the shared address after some agreed timeout. Once that refund contract has been signed, then funds can be safely transferred without the risk that the other party can unilaterally refuse to cooperate. This simple time-lock pattern is a critical component of the Bitcoin Lightning Network.

Instead of an address controlled by just two parties, you can also create accounts where any two of three signers can transfer funds. This pattern has various uses depending on the third party to the smart contract. If two people wish to execute a large real world purchase of something like a house, then the third party would be an escrow agent that can step in to execute the transfer with the seller, or sign to refund the balance to the buyer based on pre-agreed rules. The International Blockchain Real Estate Association (IBREA) and the company HouseHodl are actively researching how to apply smart contracts to real estate transactions. The Bitrated web site uses this pattern for general escrow and HodlHodl and Bisq use it specifically for non-custodial bitcoin trading. By “non-custodial” we mean that these exchanges act as arbitrators for two parties who wish to directly trade cryptocurrency for a national currency or exchange two different cryptocurrencies, without ever taking custody of the balance. Instead of a centralized brokerage holding the balance, the blockchain holds the value in a multisignature account until the two parties agree, or the arbitrator sides with one of the two parties on a particular outcome for the trade.

Additional signers could also be included to provide security in the case that the owner of cryptocurrency is afraid of having their single spending key lost or stolen. When used this way, the owner of the funds will contract with a service that agrees to follow certain security rules before cosigning any spending transactions. For example, the service might agree to call the customer to verify requests to spend any amount over some threshold. This sort of security arrangement adds protections similar to what banks and credit card companies currently provide. Companies like Casa and Xapo offer custodial services to banks and individuals using this multi-signature pattern.

Prediction markets can also use multi-signature smart contracts. In this case, the third party would be a so-called oracle. While an escrow agent or arbitrator co-signs individual contracts, an oracle publishes their signature to verify a predefined fact or range of outcomes that any number of smart contracts can have written into their scripts. For example, an oracle could cryptographically publish the closing price of IBM stock. Any two traders can now write a smart contract to make a bet on how the price will change. Each trader would add some value to a shared address and sign smart contracts that use the price data published by the oracle to determine at the end of the day how much each trader gets from the shared address. If the IBM stock price goes up, more value goes to the trader that predicted the price would rise. Tadge Dryja’s Discreet Log Contracts (DLC) project is a promising examples of how this kind of system could be implemented.

Smart contracts that use oracles to interpret real world situations can also implement different kinds of parametric insurance contracts. For example, the company World Cover has examined how blockchains can improve the privacy of parametric crop insurance. This type of insurance can also operate in a similar way to our stock trading example, but instead of publishing the price of IBM stock at the close of the day, a weather oracle would publish specific rainfall numbers for different locations at the end of each growing season. The goal of using smart contracts for crop insurance would be to make it more accessible to farmers in the poorest parts of the world by lowering management costs and expanding the potential pool of investors and policyholders.

All the contracts described above ultimately only move native blockchain value from one account to another. However, through the safety of time locks and the external control provided by multi-signature signing authority we can construct a wide variety of practical smart contracts. From buying a cup of coffee to insuring the coffee bean harvest, blockchain native smart contracts can serve many important real world use cases.