.

By Richard Stobbe

In Part 1 (Can Smart Contracts Really be Smart?), we looked at “smart contracts”, what might be called “programmatically executed transactions” or PETs. This concept refers to computers programmed to automatically executes certain transaction steps, provided certain conditions are met, illustrated by the vending machine analogy.

In Part 2 (Smart Contracts (Part 2): Intermediaries? We Don’t Need No Stinkin’ Intermediaries!), we pointed out that users of private shared (DLT) ledger systems must be aware of the attendant costs of switching to new intermediaries, and the legacy costs of continued dependence on old intermediaries.  To borrow a phrase from The Who, “Meet the new boss… same as the old boss.”  In other words, don’t be fooled into thinking that intermediaries will disappear; they merely change. Managing the intermediaries remains a challenge.

In this final instalment of our series, we look at the opportunities and limits of smart contracts. I want to emphasize a few points:

1. Placing Smart Contracts in Context: First, it’s worth emphasizing that smart contracts or PETs are merely one element of the whole DLT permissioned ledger ecosystem. The smart contract enables and implements certain important transactional steps, but those steps fit within the broader context of a matrix of contractual relations between the participants. Many of those relationships will be governed by “traditional” contracts. This traditional contract architecture enables the smart contract workflow.  The take-home point here is that traditional contracts will remain a part of these business relationships, just as intermediaries will remain part of business relations. Let me provide an example: the Apple iTunes ecosystem contains a number of programmatically executed transactions. When a consumer chooses a movie rental, a song download or a music subscription, the order fulfilment and payment processing is entirely automated by software. However, users cannot participate in that ecosystem, nor can Apple obtain content from content producers, without an overarching set of traditional contracts: end user license agreements, royalty agreements, content licenses, agreements with payment providers. Those traditional contracts enable the PET, just as the PET enables the final transaction fulfillment.
2. Changing Smart Contracts:  Once a PET is set loose, we think of it as a self-actuating contract: it cannot be changed or altered or stopped by humans.  The inability of humans to intervene is seen as a positive attribute - it removes the capriciousness of individuals and guarantees a specific pre-determined machine-driven outcome. But what if the parties decide (humans being humans) that they want the contract to be suspended or altered? Where humans control the progression of steps, they can decide to change, stop or reverse at any point in the workflow. Of course we’re assuming that this is a change or reversal to which both parties agree. But what is the mechanism to hit “pause”, or change a smart contract once it’s in midflight?  That remains a challenge of smart contracts, particularly as PET workflows gain complexity using blockchain-based technologies.
   • One solution may be found within those traditional contracts, which can be drafted in such a way that they allow for a remedy in the event of a change in circumstances to which both sides agree, even after the PET has started executing the steps it was told to execute. In other words, the machine may complete the tasks it was told to do, but the humans may decide (contractually) to control the ultimate outcome, based on a consensus mechanism that can override the machine after the fact.  This does have risks – it injects uncertainty into the final outcome. It also carries benefits – it adds flexibility to the process.
   • Another solution may be found in the notion of “hybrid contracts” which are composed in both machine-readable form (code) and human-readable form (legal prose).  This allows the parties to implement the consensus using a smart contract mechanism, and at the same time allows the parties to open up and change the contract terms using more traditional contract methods.
3. Terminating Smart Contracts:  Finally, consider how one party might terminate the smart contract relationship. If the process is delegated to self-executing blockchain code, how can the relationship be terminated?  Again, where one party retains the ability to unilaterally terminate a PET, the final outcome is uncertain, and one of the chief benefits of smart contracts is lost. Too much flexibility will undermine the integrity of the process.  On the other hand, too much rigidity might slow adoption of certain smart-contract workflows, especially as transaction value increases. A multilateral permissioned mechanism to terminate the smart contract must be considered within the system. Participants in a smart contract permissioned ledger will also have to consider what happens with the data that sits on the (permanent, immutable) ledger after termination. When building the contract matrix, consider what is “ledgerized”, what remains in non-ledgerized participant databases, and what happens to the ledgerized data after contract termination.

If you need advice in this area, please get in touch with our Emerging Technology Group.

Calgary – 07:00 MST