A smart contract is simply a computer protocol designed to automate the performance of a contract. While the concept is popularly tied to publicly traded cryptocurrencies such as bitcoin and eth, in the business context smart contracts and distributed ledgers are employed on a private, permissioned basis without the use of cryptocurrencies or tokens of any sort.
My company, Data Gumbo, provides a platform for the creation and execution of industrial smart contracts. Think of smart contracts as computer code that captures the business rules and logic of an existing natural language smart contract and uses data collected from the field to calculate payments. In most B2B situations, the smart contract does not replace the legal contract, rather it complements its execution. Whether smart contracts are legally binding as standalone constructs depends on both the situation and the jurisdiction[1], but from our experience, the intent is to use the smart contract to improve the execution of a traditionally conceived legal contract.
In addition to the commercial business case for utilizing smart contracts touched on in the first post, the use of smart contracts drives additional business benefits:
- Automation of the transaction tends to eliminate human error
- Removes many inefficiencies and unnecessary process steps
- Forces parties to agree on black and white terms, then automatically enforces those terms
- Allows for testing using historical data to ensure the business logic functions as agreed
- Creates a shared, immutable audit trail for all parties
- Creates a shared, immutable record of the final transactions with evidence to support them
- All data and results encrypted end to end
Smart contracts typically collect data from various systems utilized by buyers, sellers and third parties like trucking companies, drilling contractors or railways as inputs for business logic. The exact sources of data will vary by the use case but are generally digital. I’ll go into more detail about how to approach data acquisition in a subsequent post. In a Data Gumbo smart contract, the high level flow of information looks like this:
- Key commercial data is collected from buyers, sellers and third parties via application programming interfaces (APIs) or system specific data collectors. Data sets could be anything from sensor events like “a truck crossed the geofence” or “the drill bit moved 1108 meters on this run” to data from standard digital reports filled out by field personnel. Whatever data the parties agree to provides the source of truth for a particular contract
- The data is mapped into a standard set of data base tables maintained by Data Gumbo – this allows a smart contract to be written once and applied to many buyer / seller combinations without requiring constant code changes
- The smart contract contains business logic that includes payment triggers – anything from “once a day” to “upon completion of a well” or “upon meeting the minimum required offtake for the month”
- Once a trigger occurs, the smart contract applies the business logic agreed between the parties to then calculate the correct payment. Inputs to this include price books, special pricing rules (ie Holiday pay or prices indexed to external data feeds), purchase orders and sales orders, or manual one-off pricing
- For each transaction, usually at the most granular level the data allows, the smart contract writes a “charge block” with standard metadata and relevant attachments to show how the calculation resulted from the agreed field data
- These charge blocks are then rolled up on a pre-configured set of triggers into “invoice blocks” which contain all the necessary meta data and payload information to a) be auditable and b) feed directly into payment systems such as Enterprise Resource Planning (ERPs) like SAP or payment rails provided by a financial institution
- The blocks are written to specific ledgers shared by buyers and sellers. The entire system is private, permissioned, and encrypted. There are no crypto currencies, tokens, “mining” or anything irrelevant to B2B transactions. Critically, each party to a smart contract gets a complete, separate copy of the ledger, so that even if one party is no longer using the system, or the parties are suing each other, they both retain complete, identical and immutable records of their shared transactions
At a high level, a smart contract system itself looks like this:
The creation of a new smart contract starts with the contract analysis of the existing natural language contract.
While most companies believe that their contracts are unique and special, when looking at it from a coding perspective, contracts tend to be the same to the extent the goods and services they cover are similar, with variation around the edges such as performance payments or key performance indicators (KPIs). Even KPIs tend to be very similar (even if weighted or paid differently) within a given industry.
Here’s an example from a drilling services contract we analyzed, breaking different services down by the type of transactional metrics / triggers the contract’s language described:
In this case some of the products and services had multiple ways in which they might be charged depending a set of rules or the requirement for a combination of equipment, consumables and qualified personnel on site at the drilling location in order to trigger payments.
Once the initial analysis sorts out the different types of contract terms, business analysts can then group specific contract clauses together into blocks that calculated the same way – for example paying for services by the meter. Here is an example tracing the start/stop trigger for a meter rate transaction, the various potentially applicable modifications to the rate, and the rule to trigger an invoice:
The subject matter experts (SMEs) from buyer and seller will then agree on a black and white definition for each set of clauses tied to data collected at the point of service delivery. This is a critical step because the smart contract is in fact a collection of dumb scripts – completely deterministic and incapable of nuance. We find this is the aspect that audit teams value the most. At Data Gumbo, we find it useful to take the agreed logic that results and turn it into logical flow diagrams that are clear enough that the SMEs can read and agree upon, but also detailed and logical enough for a programmer to turn into code. Here is an example of a logical flow diagram for wireline logging showing inputs, calculations, and outputs:
The team then repeats this process for the rest of the contract, identifying the required data for each type of product or service. A simple example is a smart contract for the delivery of production chemicals to a remote location:
The team identified the inputs, the business logic including triggers, points of validation, calculations and invoicing rules. The smart contract then continuously on data provided both the parties:
Which produces transaction blocks and invoice blocks:
A key point here: The smart contract produces the invoice objects that the parties need on a configurable basis. Rather than checking a manually created invoice, in most cases the smart contract uses agreed data, logic and pricing to synthesize a pre-reconciled, pre-approved invoice ready to post in the buyer’s accounts payable and seller’s accounts receivable systems.
There are some key exceptions to the automation flow:
- Smart contracts use dispute resolution workflows to resolve discrepancies. Examples include delivered quantity exceeding ordered quantities, calculated charges exceeding purchase order values, or a truck ticket delivery location not matching the GPS coordinates supplied. In this case the parties agree to a set of resolutions such as Accept Charge, Reverse Charge, Reprocessing (in case of changed underlying data), Adjust Charge or Modifying Quantities. The original transaction block remains unchanged and depending on the resolution the smart contract creates adjustment blocks. In most cases both sides must agree to the resolution. The invoicing logic excludes any charge flagged with a discrepancy until resolved.
- Delegation of Authority. Many companies require higher level approval the larger the value of the invoice. B2B smart contracts produced invoices worth millions of dollars and some companies may require manual review of high dollar invoices until they become comfortable with the accuracy and dependability of the smart contracts.
- Two over Two. Many companies also require multiple approvals for any given invoice. Our general recommendation is to treat the smart contract as the first layer of approval and retain any additional workflows in the payment system of record rather than accommodate them in the smart contract system.
In conclusion, smart contracts are simply computer code that automates the execution of a legal contract between parties. Creating a smart contract requires interpretation of existing contract language, selection of source data, agreement on business rules, and integration to existing legacy financial systems. But that’s the easy part. In the next section, we’ll discuss what we’ve learned about the organizational change management necessary to embrace and implement the opportunity created by smart contracts.
[1] https://harrisbricken.com/blog/are-smart-contracts-legal-contracts/
