Smart contracts are utterly dependent on quality data to function. As with anything else digital, garbage in, garbage out! At a high level, smart contracts require data that is:
- Available digitally
- Standardized in format
- Agreed by both parties to be an acceptable source of truth for the contract
Additionally, to the extent the smart contract can get closer to the point of service delivery, the fewer opportunities for error from manual entry. Ideally, buyer and seller each bring some data to the table so that each transaction has multiple checks. For instance, a production chemical provider may provide a digital field ticket with time stamp, latitude and longitude of the delivery and volume of product delivered, while the operator provides fill events calculated from the tank level sensors on their pad as a check and confirmation of the location, time and volume of product received.
The smart contract platform consumes data via application programming interfaces (APIs), with the party that submits the data signing that data with their own encryption key. Our experience shows that while some sophisticated companies push all relevant data from their systems to our APIs, in most cases we must also deploy data collectors to various source systems to gather the data required for the smart contract. Below we walk through some of the common sources we utilize and what data they provide.
Enterprise Resource Planning (ERP)
The ERP systems of buyers and sellers provide critical information for billing. For the smart contract to produce pre-reconciled accounts payable and receivable invoices, it must have the required structure and fields from the parties’ financial systems of record. Additionally, depending on the level of integration and automation the parties desire, it may consume objects such as price books, purchase orders, sales orders and notices of payment directly from the ERP systems, and push objects such as service entry sheets and invoices back. We have primarily worked with SAP systems but also touched Oracle, Great Plains, Epicor, and even Quickbooks. Key data types:
- Project IDs
- Purchase Order numbers
- Contract IDs
- Vendor IDs
- Pricebooks with line item information
- Vendor Part numbers
- Cost center information
- Asset information
- Invoice fields
Daily Drilling Reports / Morning Reports
In the oil and gas drilling space, both the drilling rig contractor and the oil company that has contracted the rig produce daily reports of activity. The drilling contractor will typically use an International Association of Drilling Contractors (IADC) branded Daily Drilling Report (DDR), and the operator will typically use a morning report that is similar but in a separate system customized for their use. These reports typically typed into one of the common software packages (listed below) each morning by the rig crew and operator’s representatives and submitted to their respective higher echelon organizations. They capture each side’s view of what activity occurred on the rig over the prior 24 hour period, usually running 0600 to 0600 local time. Key information includes:
- What well and section(s) were worked on
- Breakdown of activity over the 24 hours with a coding system and comments
- List of personnel on the rig
- Bottom Hole Assemblies – what tools were in the hole
- Runs of tools into and out of the hole
- Consumption of various materials and chemicals as well as fuel
- Safety incidents
- May also contain data on drilling “mud” usage
- May also contain data on additional equipment rentals or services
This data provides the core information required to start automating drilling and drilling services contracts. The DDR is typically signed by both parties, while the operator’s morning report is only “signed off” by their representative. However, it is quite common for the operator’s representative to solicit input from the service providers for their report. Ideally this is a collaborative effort and the two reports should match closely. When they don’t their will typically be a billing discrepancy that must be resolved.
Common providers of operator morning reports include:
Common providers of daily drilling reports include:
Control System / IoT Data
The next key source of smart contract data is sensors from facilities and control systems. A key point here is that the smart contract should not be in the control loop of any supervisory, control and data acquisition (SCADA) system, rather the smart contract is downstream of the system on the other side of an API. Facility and asset owners will typically already have these systems in place for operational reasons, and leveraging that same data for commercial contracting purposes requires only a bit of additional IT work rather than deployment of new systems and sensors. Rather than attempt an exhaustive list of sources, here are some examples:
Tank volumes
Whether for measuring deliveries or pickups, 15 minute interval data from tank volume sensors is a fantastic source. Methods vary but typically a sensor place on the top of a tank points downward and measures the distance to the contents of the tank, then using tank geometry to calculate a volume. These sensors are then networked to a modem either individually or as part of the larger facilities’ SCADA system. Smart contracts aren’t concerned with the continuous data stream, but instead are looking for volume events – fills, withdrawals, and daily total usage. Example providers:
Rig Control Systems
Some drilling contracts are key performance indicator (KPI) heavy, to an extent that becomes onerous and contentious for personnel to manually calculate and then litigate via excel and email. One approach is to take data directly from the drilling data recorder or control system of the rig itself to calculate KPIs such as tripping speed, connections times etc. In cases where managed pressure drilling equipment or the mud tanks are networked into the system, this can also serve as an excellent data source for drilling mud volume compensation contracts. Ideally, the metrics are calculated in an industrial PC on the rig itself and only the calculations are then replicated back to the cloud for the purposes of the smart contract. In our experience, both buyers and sellers are willing to stipulate the general accuracy of data coming directly from the control system. Example providers:
Field Ticketing Solutions
Digital field ticketing solutions provide another key source of data for smart contracts. Whether for oilfield services, last mile logistics or various types of commodity haulage, the digital field or truck ticket captures critical data for payments as well as emissions calculations. Typical data points collected include:
- Customer / Job number / Purchase order number
- Line items of goods / services with part numbers
- Pick up and drop off location
- Start and stop time and date
- Waiting or demurrage time
- Mileage
This data, combined with agreed price books or purchase orders, as well as coding for special rules such as holiday pay or max trip distances, can generate highly accurate invoices approaching 98% accuracy without any manual intervention. One note here is that historically we’ve found it very difficult to efficiently consume handwritten field tickets or printed and scanned tickets. Although various companies are now making great progress with AI / ML to parse these tickets into something useable, we have not yet seen it reach the 95%+ accuracy needed for smart contracting. Example providers include:
The data sources we have consumed are many and varied depending on the use case. However, it would be remiss of me not to touch on the ultimate bogeyman – excel. Every organization we work with relies on some level of emailing excel spreadsheets around to make the contract execution process work. Our approach is that if the parties can commit to a standardized set of column headers, we will commit to ingesting excel spreadsheets. This can be done via manual upload, submission to FTP site or API, or even an email with an attached sheet to a specific email address tied to the contract. We have used this approach for various key smart contract data such as price books, per job pricing, equipment availability and data quality.
As long as you can get the data digital, standardized and agreed between parties, you can implement a smart contract for your use case.
