The three parts of a transacting system can be expressed as three roles:

1. A first-person role – “I” want to write a program that describes the transaction and will cause it to occur. For instance, I want to buy something by selecting the item, specifying the price and delivery, and clicking “order.”

2. A second-person role – “I” need to communicate this to the relevant “you,” and have “you” understand and agree.  If I’m using your website, you website handles this. A blockchain provides a way that is shared, consistent and neutral, where you and I are peers.

3. A third-person role – If “we” have a disagreement, then there must be a third-person who reviews the facts and decides. The third-person may be abstract – a community – and is not always very sharply defined. At the outset, it might even be the second-person, thinking more deeply.

Conventionally, this third-person is often implicit.  Both parties may know people in common, live in the same community.  Our reputations precede us and will be affected by our behavior.  In more formal relationships, the third-person role can be a company supervisor, a school principal, a police officer or court.

In any dispute, there is the problem of proving “facts”, knowing rules and the availability, patience, competence, cost and neutrality of the decision-maker.

Blockchains address some of these problems in a way that can be applied across a very wide domain. For the first-person, the author, blockchains provide patterns for transactions, often called “smart contracts.”  For the interaction with the second-person, they provide a communication method and reliable records, including signature.  For the third-party role, they provide a community that validates the state of the record (the documentary facts) and can automatically enforce some types of interactions, notably operations on tokens.

Blockchains of course address only some of the facts and some of the enforcement that is relevant for “real world” transacting. For contracts that touch on outside “reality” (the world we live in), the parties must depend on people and institutions for facts and trust. The documentary trust function and token escrows that a system of records provides can be very important in reducing disputes, but when the performance involves facts or actions that are not merely records, the ultimate trust lies in these conventional third-persons.

Because blockchains have significant disadvantages from the perspective of information security, speed, cost and flexibility, they will supplement, not fully-supplant conventional systems such as databases, email, web interfaces and newer systems such as IPFS and graph databases.

CommonAccord generalizes the first-person role – authorship or programming of transactions. It provides a common data model for referencing both prose and code aspects of transactions, independent of the platform.

In the Ricardian paradigm, it simplifies programming/authoring as the creation of a “record” consisting of parameters and references to the context of the record.  Most records will resemble credit card receipts – a list of a few key facts – and a link to the context.  The references will have a “prose” component and a “code” component.  By referencing them using names that are independent of the infrastructure (e.g., by hash), they can be used across different platforms. The code – smart contracts – can become commoditized and standardized in a granular, iterative manner, as can the prose.  The granularity resembles the Unix model of small modules with discrete functions, chained together.

Because this record format can work with blockchains and conventional IT systems, it can knit them together.  Blockchains will fill the gaps that conventional systems have left.  But blockchains, as the standard for interoperability, will cause standardization of the conventional systems.  Enterprises will be re-automated from the outside, as a result of their need to work with their customers and suppliers.  The blockchain movement can be the cause of the transformation of all of IT and law, even as it is only a part of the solution.

The combination of blockchains, decentralized access management systems, IPFS and graph databases, can make a truly peer-based system of transacting.  This can encourage the democratization of transaction “programming”, greatly reduced complexity in IT and legal, and reduce the need for centralized “hubs” – both human and tech – to manage people’s affairs.