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.
There have been a number of articles and reports that have been written discussing governance as it relates to blockchain platforms. Many correctly note that governance is a major component to ensuring successful adoption of the technology (see: Blockchain in Finance: Without better governance, it’s not going anywhere).
The reasoning is clear — if parties are meant to transact on an immutable ledger that sets out the understandings of the collective, then any transactions based on these understandings, and any alterations to the manner in which a shared understanding is derived, must be agreed upon in an equitable and reasonable manner.
As blockchain platforms mature and onboard increasingly sophisticated users and contracts, businesses will require predictability in the way in which they contract. Parties will turn to the governance mechanisms of blockchain platforms to elicit clear and predictable outcomes in the event of a future conflict.
The ‘governance issue’ is one which the R3 ecosystem is equipped to answer through its robust use of a contractual hierarchy — the “Corda Contractual Hierarchy.”
The Corda Contractual Hierarchy, as illustrated in Diagram 1 above, is reflective of a ‘self-contained governance’ model. What is meant by ‘self-contained governance’? It means that each rule that parties intend to govern a blockchain transaction, and the manner by which to resolve each issue that may arise, is laid out in a privately negotiated set of terms contained at some level of a governance framework, thereby making it unnecessary to look for guidance outside the framework.
As evidenced in recent news related to blockchain transactions, there are a litany of issues that arise as it relates to governance. Some of these issues are:
1. What happens if I send my tokens to the wrong person?
2. What happens if someone steals my private key?
3. How do I know to whom I am sending my tokens?
4. How do I know who is validating my transactions?
5. What law governs the transaction?
6. What happens if something else goes wrong?
Now, it may not be evident that the above points are governance issues, but in all of them, clear governance is the solution.
The purpose of any ‘self-contained governance’ model needs to be legal finality.
Legal finality is the means by which two or more parties transacting something can feel confident that: (i) a valid and binding contract has been formed, (ii) the contract is complex enough to record all material terms, and (iii) there are readily identifiable means by which to resolve disputes.
Given the issues that the blockchain space presents, every platform should consider legal finality as an end goal.
Let’s look at a transaction in the physical world. Alice is holding an item (let’s say a water bottle), and Bob has currency (let’s say fiat currency, e.g. cash). Bob wants to purchase the water bottle from Alice in exchange for the cash.
The transaction steps are as follows:
1. Alice names a price she’d be willing to accept for the water bottle;
2. Bob names a lower price;
3. Alice and Bob negotiate and agree on a price
4. Alice and Bob shake hands;
5. Alice hands Bob the water bottle; then
6. Bob hands Alice the cash.
Now, what if, when the parties decide to walk away, Alice decides she wants her water bottle back. Can Alice take the water bottle back?
Well — the short answer is ‘no.’ That is because Alice and Bob have entered into a legally binding contract.
There are generally four (4) elements that need to be satisfied to evidence contract formation: 1. Offer, 2. Acceptance, 3. Consideration, and 4. Mutual Assent.
In the above example, they have been satisfied in the following ways:
1. Offer — Bob offered a set amount of cash for the water bottle;
2. Acceptance — Alice agreed upon that set amount of cash;
3. Consideration — Cash in exchange for the water bottle is a transaction of value; and
4. Mutual Assent — the handshake.
So — even though Alice may want her water bottle back, there is an express contract which ensures that she is not entitled to take it back (provided she does not have any arguments to make regarding the formation of the contract).
However, there is a fundamental concern: the terms of the contract are extremely simple — they do not encompass all of the terms necessary to resolve issues that could arise in the future. In addition, there is no document that they can reference. And yet, a contract still exists — because the legal system says it does.
In the digital asset space, companies are looking to create the digital version of these items. So how would this example play out?
Well, let’s say Alice has a tokenized water bottle in her wallet, and Bob has tokenized cash in his wallet. Alice would send her token representing the water bottle to Bob, and Bob would send his token representing the cash to Alice. Let’s say that Alice would want to get her token back. Similar to the physical space, an express (and simple) contract ensures that she cannot (provided the contract is found to have been properly formed).
Without anything further governing the transaction, this token exchange is subject to the terms of the transaction, as evidenced through the code of the transaction. Specifically, Alice and Bob would look to the code for evidence of an agreement. Here, the notion that “code is law” is embodied in the express contract.
Okay great — there is a validly binding contract.
However, issues around governance can still play out as follows:
1. Alice claims she meant to send the water bottle token to Carl (not Bob);
2. Alice claims that Dave stole her private key and sent the water bottle token on her behalf without her knowledge;
3. Alice claims that she thought she sent the water bottle token to Bob, but it ended up in Carl’s wallet;
4. A node from a sanctioned country validated Alice’s transaction, thereby implicating AML/KYC issues;
5. Alice and Bob live in different countries when an issue arises; and
6. Alice and Bob used an exchange which didn’t send either of their tokens to the other party.
What is the process by which Alice and Bob can resolve the issues above?
If the contract is based on the exchange of tokens and is not governed by any other terms (read: a simple contract), the answer unfortunately is litigation — a court will determine what the appropriate procedure is and fill in any terms that the parties left out based on the law the court determines is proper to apply. This is not a good answer, especially in the context of commercial agreements. Ask any commercial entity, and the last place they want to end up in is a courtroom. Litigation is expensive, time consuming, and the parties never truly know which way things will end up. Alice and Bob are missing something crucial: at the point of exchanging the tokens, they are missing legal finality.
So, what is the answer to the litigation problem? How can parties truly achieve legal finality? In a word: governance. In more words: a ‘self-contained governance’ model. In even more words: expressly written contracts operating within a hierarchical structure contained within a ‘self-contained governance’ model.
Let’s break this down:
‘Expressly written contracts’
The answer to the contract whose terms must be implied by a court is the expressly written contract. It is no coincidence that commercial parties enter into expressly written contracts when transacting with each other. Expressly written contracts provide legal finality by satisfying the requirement that a validly formed contract has been entered into, completing all terms of the contract, and, if the parties so choose, the private means by which to resolve a dispute (e.g. mediation or arbitration).
‘Operating within a hierarchical structure’
In the real world, in many instances, the expressly written contract could be enough to provide for legal finality. However, there is a nuance in the software space, specifically around blockchain, and that revolves around how blockchain platforms and applications are structured.
From a software perspective, blockchain platforms like Corda operate at the very bottom of the ‘software stack.’ Corda has a purpose: to facilitate the creation of tokens.
Corda has built-in functionality that allows for the attachment of legal prose to tokens (see Corda Key Concept: Legal Prose)
R3 has recently released the Corda Token SDK for standards around the creation of tokens on Corda
An initiative with which R3 is involved for inter-chain standards around the creation of tokens is the Token Taxonomy Initiative (TTI).
As you move up the stack, technology developers utilize Corda to build applications known as ‘CorDapps.’ ‘CorDapps’ use Corda’s functionality to transact tokens among end users.
See The Road to Blockchain Governance Part 1: Evolution of the Blockchain Space — Data, Value and Smart Legal Contracts for a view on the progression towards smart legal contracts for the transaction of tokens
An initiative with which R3 is involved for standards around the transaction of tokens (through the use of smart legal contracts) is the Accord Project.
Both the creation and the transaction of tokens within a ‘CorDapp’ are governed by the contract that parties enter into to use the ‘CorDapp’ — as illustrated in Diagram 1, this is known as the Business Network Rulebook.
(Note: The Business Network Rulebook is to be negotiated and structured by those entities operating Business Networks, taking into account considerations applicable to the specific ‘CorDapp’ (e.g. by reference to use case, jurisdiction…etc.); R3 intends to provide open source standards for consideration during the structuring of these rulebooks)
Lastly, end users may have a need to transact tokens between ‘CorDapps.’ This is where Corda Network enters — the purpose of Corda Network is to ensure interoperability between ‘CorDapps’ to allow for the transaction of tokens. Part of this purpose is accomplished through the introduction of ‘Governing Documents’ which provide legal finality between distrusting parties.
‘Contained within a ‘self-contained governance’ model’
A ‘self-contained governance’ model is what brings this all together. The purpose of the model is to ensure that legal finality is reached. At each step in the process, the various terms that the parties have entered into interplay to ensure that the parties have entered into validly binding contracts, and each party knows the dispute resolution processes that need to be followed in the event an issue arises.
The purpose of laying out the hierarchy is to attain a holistic view of where different concerns would need to be addressed in a blockchain transaction. Diagram 2 below shows how the hierarchy would generally apply to issues that may arise.
As we can see, each issue is governed by a different level of the hierarchy. When viewed with this perspective, it is evident that each participant in the ecosystem needs to take certain (and varying) considerations into account.
The result: the transaction of digital assets within a ‘self-contained governance’ model through the utilization of privately negotiated terms thereby assuring legal finality — and the avoidance of litigation!
Coming up in this series, we will focus on considerations surrounding the token layer of the Corda Contractual Hierarchy — and will then work our way up the stack!
January 11, 2021
December 20, 2020
December 16, 2020
Stay up to date on the latest news and articles related to R3.