This series of posts is meant to act as an overview of the structuring of blockchain transactions and platforms from a general governance and contracting perspective.
Some of the earliest commercial uses of blockchain technology thus far have addressed the recording of data to effectuate business processes. Parties receiving data validated through a blockchain protocol can rely on it to set in motion business processes “off-chain.”
An example can be a commercial loan. Multiple parties in a syndicated loan transaction can access data validated through the use of a blockchain protocol (e.g., the terms of the loan). Once the lending entities receive the validated data (e.g., the agreed amount of the loan, the interest rate, the payment terms, etc.) the loan can be made to the borrower utilizing traditional means (e.g., a wire transfer of fiat currency from the accounts of the lenders to the accounts of the borrower).
In this simple example, neither the contract for the loan nor the cash owed are “transacted” using the blockchain protocol. Nevertheless, the availability of validated data has provided efficiencies to a process that traditionally would have entailed several manual steps to confirm with certainty the information recorded in the data structure maintained by the blockchain protocol (e.g., phone calls, wet signatures, faxes, e-mails…etc.).
In parallel to the storage of validated data, institutions are interested in using blockchain technology to transact value. This can be done through the creation of ‘tokens.’ Generally, tokens are data entries in a blockchain-based ledger that can be used to track present-day financial instruments.
There are three main categories of tokens*:
1. Tokens that represent a claim on an asset, e.g., where precious metals are held by a custodian;
2. Tokens that represent a claim against, or interest in an entity, e.g., where a bond’s value is derived from the credit of the company standing behind it; and
3. Tokens whose value is set by supply and demand, e.g., cryptocurrencies such as Bitcoin and Ether (note: not a present day financial instrument).
*(for more information, see 10 Law Firms Walk Into A Room… (R3 Legal Center of Excellence + Thomson Reuters Practical Law collaboration)
The transfer of a token that is representative of value from the “account” of one entity using a blockchain protocol to that of another entity using the same protocol can create efficiencies in markets. However, currently, the settlement of any rights or obligations represented by such a token would need to take place “off-chain.”
For example, payments owed to the owner of a “tokenized” bond by the issuer of that bond would need to occur using traditional means (e.g., ACH).
Accordingly, the next step after initial tokenization entails the operationalization of certain rights and obligations relating to the use of tokens.
For example, the owner of a bond token could receive any coupon payments due to the owner automatically through the receipt of other tokens that represent value (e.g., tokens that represent claims on cash held in a deposit account of a bank).
More critically, using standard contracting, there is no practical way of automating the various obligations between them in a way that allows both parties to have equal confidence in the outcomes of the automation.
The use of permissioned blockchain protocols can greatly facilitate automated contracting. Once a contractual relationship has been formed, the counterparties can then automate their various obligations. When combined with data validation and the use of tokens, this becomes a powerful step forward in the evolution of business.
Smart contracts, as that term is used in the technological sense, deal with computer programs that automate processes. Generally, a smart contract is when there is an input (X), which triggers an action (Y), and ends with an output (Z). At its most fundamental, a vending machine is an example of a smart contract: you insert money and press a button (X), the machine dispenses the snack into the tray below (Y), then you retrieve the snack (Z). Another example is the ‘sort’ function in a column of an Excel spreadsheet: you input numbers into a column and press ‘sort’ (X), that sorts the numbers in descending order (Y), and the output is a sorted column (Z).
A smart legal contract is formed when a smart contract rises to the level of forming a binding and legally enforceable agreement.
To understand the evolution of the smart legal contract space, we can start to view the type of transactions entered into as a distinction between contractual obligations and settlement.
As unique (non-token) components of data are transmitted, the smart contracts that rely on such data components can start to do more than just execute existing business processes: their real contribution to the evolution of business is that of recording contractual obligations that exist between parties.
For example, a contractual obligation states that “Alice will pay Bob $100.” Bob can now take this contractual obligation and, subject to the governance model used in a specific network, go to a mediator/arbitrator/judge and claim his rights to payment.
Once these contractual obligations are recorded, the next step is to settle them. Settlement is where tokens come in the picture.
For example, settlement is when Alice actually pays Bob $100.
Where smart legal contracts become increasingly efficient is when the contractual obligation is recorded, and the settlement of the contractual obligation takes place instantaneously at the time when the contractual obligation becomes due.
For example, “Alice will pay Bob $100” and Alice actually pays Bob $100 at the time that the contractual obligation must be filled (which may be at the point of execution of the contract, or at a later agreed upon date).
As discussed, the first instances of blockchain for contracting are meant to act as a novel way to address contract formation. The clauses of the contracts are not operationalized.
The next iteration is when the smart legal contracts begin to have contractual obligations that are triggered by data inputs.
For example, Alice agrees to pay Bob $100 when it rains. A weather service provides data to the contract that it is raining on Monday. Alice now owes Bob $100. The settlement of the $100 happens ‘off-chain’ through traditional means (i.e. Alice delivers to Bob a bag of cash). In the event Alice fails to pay Bob, Bob can bring this contractual right to payment to a mediator/arbitrator/judge.
Lastly, the final iteration is when the smart legal contracts begin to have contractual obligations that are triggered by data inputs instantaneously settled by tokens.
For example, Alice agrees to pay Bob $100 when it rains. A weather service provides data to the contract that it is raining on Monday. Alice now owes Bob $100, and payment is made at the time this contractual obligation arises through a $100 token being sent from Alice to Bob. In the event Alice fails to pay Bob, Bob can bring this contractual right to payment to a mediator/arbitrator/judge.
These evolutionary categories matter because, prior to knowing how something should be governed, we need to know what it is! The governance of data, value and smart legal contracts should take into account varying considerations.
In the next post, we will try to visualize where these various considerations come into account from a hierarchical perspective and will walk through some general considerations regarding governance on blockchain platforms (and why the use of Corda on the Corda Network is the optimal choice!).
Stay up to date on the latest news and articles related to R3.