A recent article by Bill Li, Chief Network Architect at MATRIX AI, entitled “Intelligent Contracts — the AI Solution for the Issue of Security and Smart Contracts” highlighted two very significant flaws in smart contracts: 1) they are not smart enough and 2) they have poor security mechanisms and tools. The article went on to deep dive into various examples of smart contract security loopholes recently exploited by hackers, and then parlayed their intelligent contract solution which deals with said security flaws.
At Seal, we fully endorse the need for intelligent contracts as a superior execution method over smart contracts. We differ from MATRIX AI in that their focus is on the weakness of smart contract coding and design, whereas ours is on the flexibility of the data and the real-world problem of encoding a digital contract. Both are compatible and harmonious. The examples Li gives are predominantly focused on the transfer of cryptocurrency, triggered by a smart contract, and the loopholes hackers have exploited. These examples are necessarily straightforward – if event Y happens, then transfer X sum of crypto from Actor A to Actor B. In more complex transactions the scope for failures is more acute. Think about a complex financial transaction like a QFC or a large MSA for a large infrastructure building project, then the issues are magnified.
When we at Seal talk about Intelligent contracts, we are talking about coding key metadata and KPIs (such as payment terms or termination notice periods) onto the blockchain so that each party (and there may be more than one) can subscribe and ambiguity is removed. However, we keep the actual clauses and the actionable data off-chain. This hybrid model serves several purposes. Firstly, it avoids the block size and performance limitations of blockchain implementations. Secondly, the off-chain storage option supports the capability to learn and analyse contract versioning, categories and the interrelationship between contract documents (e.g., a MSA, change orders, SOWs, etc.). Thirdly, and most importantly, it obviates the need to try to encode highly ambiguous clauses into a smart contract. Essentially smart contracts need to be encoded as conditional expressions, which is all well and good when the options follow distinct IF – THEN – ELSE patterns. However, where it fails is the need to deal with ambiguity.
Consider this very common clause in a procurement contract: “Supplier will deliver the product that is acceptable to the buyer at its sole discretion.” Often this is a clause forced on the supplier because the customer demands their paper is used as the template. So, how do you encode the ambiguity of what is deemed “acceptable”? Essentially, you cannot. One of the design tenets of Ethereum, the most prevalent platform for smart contract execution, is that of immutability. Once the contract has been encoded it cannot be changed (well certainly not without the consent of the other participants in the permissioned distributed ledger). So “coding to grey” is required. This is borderline impossible as every potential outcome must be catered for in the code. There are plenty of other examples – “supplier will make best efforts….”, “…whichever the customer deems relevant…” and so on. Read a few contracts yourself and try and spot clauses which are either blatantly ambiguous or at best still open to different interpretations by the two parties. I am sure you will find many examples.
Therefore, to encode this clause into a smart contract, this ambiguity must be eradicated. There are two possibilities here. Firstly, contracts can be rewritten to be so watertight and buttoned down that all ambiguity is removed. This is obviously an ideal model; contracts written without ambiguity are encoded on the blockchain making interpretation and execution quite simple. One of the reasons that the average enterprise leaks nearly 10% value out of their contracts is because they are poorly written. So, tightening them up would be a good thing. In practice, however, there will always be ambiguity and the need to negotiate a clause meaning post contract execution. So, the second option is implementing an intelligent contract platform like Seal, that takes account of ambiguity by encoding contract metadata but not the actual clauses. The ledger remains immutable whilst the clauses and actionable data are maintained off-chain. This model enjoys the advantages of an immutable blockchain and post-execution negotiation. In addition, Seal provides contract holders with the capability to apply AI analysis models to the data off-chain. This type of analysis is not feasible on current blockchains. The results of the analysis capabilities are insights that enable better predictions and more precise ways of understanding the opportunities to save money and time or generate value.
So, whilst the security flaws in smart contracts are real as evidenced by recent hacks, to effectively encode business contracts something more is needed, and that is an intelligent contract approach.
At this time of year, when soccer clubs are promoted and relegated into their leagues, it is often said by the fans of those who fail to win and are destined for a lower league next season:
“It is the hope that kills you.”
In the world of smart contracts, we can finesse that aphorism too:
“It is the ambiguity that kills you!”
1990 N California Blvd., Suite 500
Walnut Creek, CA 94596
Tel: +1 650 938 SEAL (7325)
1-2 Hatfields, Waterloo
London SE1 9PG
Tel: +44 203 735 9898