Amid a lack of viable blockchain solutions and numerous and oft-competing platforms, digital tools — dubbed “smart contracts” and typically accessed via blockchain — offer container shipping a way to streamline payments and tether those payments to physical movements.
The tools are designed to replace traditional contracts for a host of reasons: to reduce latency in payment, to eliminate discrepancies in the invoicing and payment process, and to link processes to real-world physical events. The goal of a smart contract is essentially to make contracts self-executing and enforceable, which is to say automated. Theoretically, if a smart contract is properly set up, processes are automatically initiated.
Smart contracts — just two parties needed to start one
The reason smart contracts are more tangible is that they can be agreed upon by as few as two parties, just as with traditional contracts. So, even though a blockchain may require, say, 30 parties to make it valuable, any two parties on that platform can engage in a smart contract that’s not visible to the other 28 parties.
The challenge of taking blockchain pilots and proofs of concepts to wide-scale adoption is that the latter requires a broad adoption from a range of parties. In a chicken-or-egg scenario, there needs to be enough parties using a blockchain platform to make the solutions on the blockchain valuable to those parties.
That’s daunting because it requires buy-in from a large number of stakeholders. Some of those stakeholders are directly competitive in nature (think shippers in the same industry), some have adversarial commercial relationships with each other (think shippers and liner carriers), and some are competing for the same set of customers (think liner carriers and non-vessel-operating common carriers).
In logistics terms, the easiest way to think about a smart contract is a scenario where a process is triggered by an event. For instance, the event could be receipt of a container at a distribution facility, triggering an electronic payment from one party to another at a specific date. The value in that scenario is the elimination of the time required to produce an invoice, manually initiate a payment, and resolve billing discrepancies.
The optimal trigger — a digital event
The most optimal trigger is a digital event. In the container receipt example, that would mean a sensor (often referred to as an Internet of Things [IoT] device) sends a message that the container has reached a geographic threshold, initiating the process (instructions that one party pay the other electronically). The less optimal scenario would see a more manual trigger, such as a signature on an iPad, initiate the automatic payment.
The reason smart contracts are tied to blockchain is that blockchains are intended to provide a greater level of trust in the data contained within them, a vital component when payment is being rendered. According to advocates of smart contracts, parties can take any terms and conditions from a traditional contract and bring them into a smart contract. Alternatively, they could stipulate in a traditional contract that a smart contract be the mechanism used to transact.
It’s important to note that smart contracts are essentially pieces of code, not just electronic versions of paper contracts. In programmatic terms, they’re set up as “if-then” scenarios — if something happens, then something else happens. Those scenarios can involve one step or multiple steps, depending on what is in the contract and how many parties are involved.
Aside from providing a mechanism to improve efficiency of transactions, proponents of a smart contract also tout its ability to eliminate terms in traditional contracts that aren’t enforced. For instance, if two parties agree to boilerplate language in a contract, but enforcing an aspect of that contract is commercially not viable or impractical, the two parties would just eliminate that term in a smart contract. That elimination would not just happen for efficiency’s sake — in programmatic terms, if any part of a smart contract is not fulfilled, the contract wouldn’t be executed.
The minimum quantity commitments (MQCs) negotiated in annual ocean freight contracts between shippers and ocean carriers springs to mind as a contract clause that is never enforced by carriers for fear of damaging the commercial relationship with a customer.
If that annual contract was executed on blockchain, the carrier would have to exclude the MQC unless it was willing to have it be enforced. Similarly, the shipper would have to agree to the MQC and any resultant penalty in a smart contract. More likely, the two parties would drop the clause and focus the terms of the contract on areas that they both agreed to enforce.