Smart contracts and the uses of digital currency

1. The need for programmable money and establishing legitimacy

1.1. Smart contracts and smart money

The case for digital currencies has not been helped by the fragmented and polarized discussion regarding their uses. Central Bank Digital Currency (CBDC) has been discussed primarily as a replacement for cash in contexts where the use of physical cash is declining (e.g. Sweden)[1], in other words as settlement for simple and mostly petty transactions.

At the other extreme the consensus principal use-case for Bitcoin is censorship resistance. Censorship resistance has positive connotations that are associated with totalitarian contexts but also involves money laundering, terrorism finance, sanctions avoidance, as well as avoidance of capital controls and tax evasion.

Both of these standpoints fail to address high-value, main stream, economic applications. Thus, the question continuously posed in relation to digital currencies remains that what are the legitimate, institutional uses?

The key aspect missing from much of the discussion is a focus on the characteristic of digital currency as programmable money, which in turn leads to a novel ability to restructure currently costly intermediation of complex transactions.

The programmability of the currency is the ability to attach a series of conditions to the execution of a transaction. The transaction self-executes and settles as agreed, but only if, and when the conditions have been met.

The set of coded conditions (or conditionalities) are commonly known as a smart contract[2]. However, as is unfortunately common in the Alice-In-Wonderland world of crypto, a combination of related terms and concepts including agreement, transaction, condition, code, self-execution, codified law have been aligned together under one misnomer– whereas the result typically is neither smart nor a contract, nor enforceable under law[3].

Contracts are not just agreements

Contracts are both far more and far less, than a series of self-executing encoded IF…THEN statements combined with a digital payment mechanism. Practical contracts need to reflect the intent of the parties, typically expressed in the conditions of the agreement, combined with verification, execution, adjudication and enforcement.

However, some of the functions of a contract may be delegated to external systems, including encoded scripts running on the blockchain. In other words, the smart contract may be a subsidiary element of a real-world contract, tied to a natural language contract, with external verification of states, and subject to real-world adjudication and enforcement.

A model of delegating contractual elements to an encoded smart contract, which in turn is combined with a digital collateral and payment function, is potentially revolutionary (in a positive sense) and has significant real-world attraction and multiple potential use cases.

On one hand, it allows for the cost-effective and efficient collateralizing of small(er) transactions, which nevertheless are long-term in nature and/or should be subject to performance obligations. On the other hand, it allows for the efficient structuring of contracts involving multiple parties with performance obligations and respective collateral needs.

There is an argument that all this is redundant as financial intermediaries (banks and insurance companies), already intermediate such contracts and provide insurance or collateral for non-performance. However, the point is that smart contracts allow this to be done on a smaller, cost effective scale by introducing replicable elements and automating significant parts of both contracting and settlement, as well as a self-executing process which does not require constant involvement of the parties.

This, in short, is the promise of smart money.

1.2. Some practical examples

A) Alice sets up an auction for her apartment in Stockholm; the estate agent collects bids from potential buyers over an (un)determined period of time. At some point Alice decides to accept Bob’s bid, and the estate agent communicates to Bob that there is an agreement. However, as it stands neither Alice has an obligation to sell nor Bob to buy at the agreed price. After the agreement Bob decides that he is in fact no longer interested and Alice does not know what to do.

This is a setting where the auction conditions would be easy to encode, including the requirement for all parties to provide performance collateral. Moreover, all parties might find a ‘smart contract’ run auction to lead to a more speedy, transparent and satisfactory outcome.

B) Alice contracts Bob to renovate her bathroom. Bob undertakes this as a fixed price contract, promising to complete the project in 4 weeks. Bob begins work, dismantles the bathroom and moves on to another more urgent project. 6 weeks later Alice’s bathroom is still out of use, Bob’s work is still in progress and Bob comes back requesting a 25% increase in the agreed amount due to what he claims is extra work.

Under a smart contract, Alice’s payments to Bob would be dependent on performance, and Bob would be expected to provide collateral as a guarantee for said performance. The contract would pre-assign an oracle (a nominated 3rd party) to determine whether the performance criteria had been met. If Bob failed to perform, Alice would claim the performance guarantee and terminate the contract.

C) Alice’s firm orders 1,000 units of components from Bob. Bob requires 20% payment on order and the balance to be paid on delivery. Alice assembles the components into final products, which she sells to Carol. Carol determines that 10% of the products do not function and Alice traces the problem back to the components provided by Bob. Alice makes a warranty claim but Bob fails to respond to any of Alice’s communications.

Under a smart contract, the entire transaction could be structured as a supply chain agreement with collateral provided by all parties for performance and deferred payment clauses for warranty claims. In case of failure to perform, parties would have an immediate remedy, as opposed to a lengthy and costly adjudication process and uncertain enforcement.

In principle, all of this could be done today but the costs of doing so are prohibitive. The issue smart contracts are solving is reducing friction to the point of enabling actions that were previously un-viable. In economic terms, this is a classic example of adding significant value by reducing transaction information costs.

However, none of this can be achieved if focused on a naïve belief that it is sufficient to encode the conditions into the smart contract, without consideration for the other elements that are required. On the contrary, achieving the above requires building an environment with multiple contributing parties, also known as intermediaries.

2. Working towards a solution

The core element of smart contracting is the smart money — the combination of a digital payment facility with a programming facility for terms and conditions leading to conditional but self-executing contracts. Additionally, this needs to be combined with elements such as:

1. A natural language contract which expresses the intent of the parties and which delegates certain functions to the smart contract;
2. External Oracles that verify the state of the contract;
3. The facility to establish real identities and confirm intent (signatures) of the parties;
4. An adjudication mechanism to resolve unforeseen issues and disputes, which may be an arbitration facility or default to a specified court of law;
5. A financial intermediary that brings the relevant parties together and underwrites the accuracy of the Ricardian contracts (essentially that the code matches the intent); also known as a smart contract broker.

At some future point in time all of the above elements may be digitalized and automated. For the time being most of these elements take tangible form as real-world institutions that need to be interfaced into the system, in order to create the reduction in friction that is aimed for.

Below is one visualization of a contracting architecture.

2.1. Necessary attributes of a digital currency

For a digital currency that is underpinning a smart contract environment there are some necessary attributes:

1. A stable, credible source of value;

2. Transparent governance;

3. A link to real-world legal identities and signatures, which make contracts enforceable and enable them to be considered for adjudication;

4. A decentralized structure where the ability to establish contracts is not dependent on a single intermediary but rather there is a multilateral network of intermediaries;

5. And, of course, programmability that enables smart contracts (the state engine).

The first attribute is somewhat critical, as it underpins the entire credibility of the rest of the system. A Central Bank Issued Digital Currency (CBDC) would fulfil this. However, assuming central bank issuance is necessary is false. Moreover, from the perspective of the overall environment central bank issuance would be problematic as it would likely seriously disrupt the fundamentals of current deposit taking financial institutions[4].

Privately issued digital currencies however need to conclusively resolve the challenge of value, stability and governance; and this is likely to require solutions that are explicitly asset-backed rather than algorithmic.

The fourth required attribute of identities, signatures and adjudication involves significant further complexity, and has been one of the key stumbling blocks for developing real-world applications.

3. Why even smart contracts require recourse

Once an exchange involves anything of value, the transacting parties must retain the ability to ask external parties, including the courts, for assistance in the event something goes wrong. Many of the propositions made in the blockchain and crypto space portray courts, legal principles and financial or legal intermediaries as inconvenient legacies to be made redundant.

This abjectly fails to appreciate complexity of a modern economy and the institutions that have been formed to intermediate that complexity. It also confuses institutions and functions and rejecting institutions does not mean that the functions are redundant. Instead, the question should be that how is the required functionality recreated in a new decentralized digital system. This is not a trivial challenge; centralized hierarchical structures with human input are very good at handling specificity in ways that decentralized algorithmic structures are not.

3.1. Establishing legal parties

The first challenge of smart contracts is that Public Key Identities (PKIs) need to be recognized as valid legal persons and digital signatories according to the law. Instead of searching for complex workarounds, the simple and obvious solution is to use approved identity schemes to establish and verify the true identity of the counterparties in every transaction and thus establish the legally binding nature of the transaction or contract.

Several countries have passed legislation regarding digital signatures and they are widely used in the Nordic and Baltic countries as well as elsewhere. Within the EU the eIDAS regulation defines the conditions on which digital signatures are binding even across borders.

Legally binding digital signatures can be made with approved, regulated digital identity schemes that fulfil the criteria for eIDAS high/ LoA-4 safety. In these, if you have digitally signed a contract with your PKI-identity, the burden of proof shifts to the signer to show that the digital signature is not valid, for instance due to the malfunction of the identity scheme. Implicit in these, is that the PKI signatory is associated with the real-identity of a legal entity. The recipient of the signature can trust that the signed contract is legally binding and enforceable.[5]

3.2. Managing ambiguity and uncertainty

Contracts represent the intentions of the transacting parties and the commitments they bindingly agree to make. Some of these intentions and commitments may be expressed in code, which becomes the self-executing smart contract. But the challenge remains that not all contract states can be modelled or codified. There are simply too many edge and corner cases to allow a deterministic modelling and description of every possible state.[6]

Furthermore, circumstances may change (including force majeure conditions) leading to a need to re-negotiate, terminate the contract or enforce collateral. Finally, certain concepts are contextually dependent, e.g “good faith” or “reasonableness”. This has a related consequence, that not all contractual remedies can be modelled. Ideal remedies may change if circumstances change.

Thus, there is an inherent need for adjudication, including the ability to consult the parties for preferences.

Any system which does not facilitate for contract adjudication will likely remain a non-starter. However, contrary to nay-sayers on both sides of the spectrum, it is entirely possible to institute a smart contract system which facilitates legally binding smart contracts relating to real assets and includes appropriate adjudication.

3.3. Matching code with intent

The third challenge of smart contracts is that it is highly unlikely that the parties will be proficient in expressing their intents in code (let alone code only). Hence, the concept of the Ricardian contract, where the contract expressing intent is drafted in natural language, with specific elements delegated and encoded into the smart contract.

Still, the parties may balk at the coding challenge. Which creates the need for a contract broker who not only intermediates the contract between the parties, but assists parties in ensuring that the coded obligations reflect their agreement. Given simple probabilities, it is likely that this process will still incur errors, or ambiguity which will require interpretation. Thus, the need for recourse is again paramount.

4. In conclusion

There are three points to raise in conclusion.

Digital currency and smart contracts can transform the structuring of high-occurrence everyday use cases. Refusal to acknowledge this is natural for businesses seeking to protect their current franchise but is still short sighted.

The potential of digital currency cannot be realised without instituting a system of some complexity, involving also non-digital intermediaries. The value of the new technology is maximized when integrated into existing contexts.

Insisting on decentralized digital purity will only perpetuate the current state of affairs in which smart-contract relevance is mostly limited to the conditional assignment of crypto-kitties and other on-chain digital assets, and where the legitimacy of digital currencies continues to be fundamentally questioned.

[1] Stefan Ingves on Going Cashless http://www.imf.org/external/pubs/ft/fandd/2018/06/central-banks-and-digital-currencies/point.htm

[2] Technically abstracted this is comparable to state transition and smart contract platforms are also referred to as state transition machines

[3] For an analysis from a legal perspective see Mik, Eliza. Smart contracts: Terminology, technical limitations and real world complexity (SMU 2017). https://ink.library.smu.edu.sg/sol_research/2341/

[4] Bank For International Settlements: Central bank digital currencies. https://www.bis.org/cpmi/publ/d174.pdf

[5] With reference to Janne Jutila, Internospartners.

[6] Again with reference to Eliza Mik. https://ink.library.smu.edu.sg/sol_research/2341/