The first time I heard about the automation of contract negotiation and agreement in 2001-2002. It was written in ebXML (backed by OASIS and UN/CEFACT).  It was an amazing achievement because the first SML Conference took place just in 2001. The endeavour fails because of two major reasons, as I learnt later:

1. Business people did not accept automation without their involvement in such a lucrative and luxury process as a contract signing off
2. Security protection of XML was still weak and not standardised yet.

Recent splash of interest to automated contract negotiation, agreement and enforcement, now under the name of Smart Contract (SC), has been facilitated by the practice of using SC in Blockchain for cryptocurrency and attempts to use SC for other different types of assets. After 18 years, I am curious what industry has gained with SC and how much smarter it becomes than old ebXML solution.

What’s What?

I have found several definitions and explanations of SC. This means, there is no standard commonly acceptable understanding of this matter and it mainly depends on the execution context. Since the industry has started adopting SC outside of technical Blockchain and digital currency, one of the most important and influential definitions comes from Investopedia [], “Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network.”

To me, this is quite confusing – if the network is not a “blockchain network” do we have an SC or do we not? I think we can omit ‘blockchain’ and continue analyse the SC smartness.

Investopedia also states that SC “permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. They render transactions traceable, transparent, and irreversible.” I have stumbled at “anonymous parties’. If parties are anonymous, how would we know who is actually in the contract and who has which obligations? It is well confusing.

Here are a few more attempts to explain SC, now from the technology viewpoint. “A smart contract is “a computerized transaction protocol that executes the terms of a contract“. Then, “A smart contract is a set of computer code between two or more parties that run on the top of a blockchain and constitutes of a set of rules which are agreed upon by the involved parties. Upon execution, if these set of pre-defined rules are met, the smart contract executes itself to produce the output”. This definition decouples SC from Blockchain, and this is the first good news. Also, “Smart contract is a protocol intended to digitally facilitate, verify or enforce the negotiation of a contract. It also facilitates the credible transaction without the involvement of third party”. One moment, this sounds more as a wish than a truth. We need to dig deeper into what  “digitally facilitate”, “verify” and “enforce the negotiation” mean before going forward.

First of all, let’s look into an SC. It includes legal clauses, templates and business rules that manage contract formation by users. The parties should know each other and, moreover, agree on the contract statements. This will be visible to everyone on Blockchain, which contradicts business privacy.

In OASIS RAF SOA standard (developed to mimic business and technology worlds in the service-based interactions, two types of the consumer-provider contract were defined:

1. Explicit service contract (ESC)
2. Implicit service contract (ISC).

(It is a different topic why modern developers are practically unaware of this).

The ESC required a direct and precise agreement between negotiating parties. It is a common practice to negotiate and have business contracts confidential. The ISC needs only one party to declare the contract clauses and rules while another party needs only agree with them by default to start using the service. Usually we use ISC when shopping in stores.

So, can an SC be implicit? I do not think so. Assume that one party has defined all business rules, clauses and template libraries. The second party has legally agreed with them. But the contract as a protocol or a set of code cannot work. The second party has had to prepare its software to be accessible and responsive to the contract invocations and commands (enforcement) and this is much more work than to establish and agree on the contract.

In other words, both parties have to explicitly prepare their technology means for the contract. If they want to participate in another SC between them, they have to perform another preparation. This also relates to the case where any one of the initial participants wants to into a contract with a third-party. I think it is apparent that SC requires an implementation of the choreography pattern with all its terrible downsides of it. I’ve written a few articles about choreography troubles.

What is ‘smart’ about Smart Contract?

We’ll see. “Truly autonomous, smart contracts eliminate the need for human management and significantly reduce risk. Advancements in technology mean that contracts can be coded to communicate with each other, exchange vital information, reflect what influences them, and stay updated with the most current information. Through the use of smart contracts, the business will become faster and more flexible”. This impressive statement also means:

1. As we saw, SC is not autonomous – it requires a lot of preparations in the software systems of both parties.
2. It reduces risks of human errors in the management, but can propagate such security mistakes as inter-contract links via code or legal mistakes in the rules.
3. I read many publications about SC and all of them point to very difficult and highly risky coding of contracts. This means that update SC is a difficult task on both parties, which leads to that “the most current information” can significantly late or even invalidated.
4. All above, plus, an option of deployment on Blockchain, make SC immutable, not flexible at all.

Nonetheless, we can read many incredible pearls like this – “Unlike regular software though, smart contracts are often directly in charge of assets, and once they are written to a blockchain, they cannot be changed. … This makes secure smart contract development essential”. It seems that the one who really made contracts to be “often directly in charge of assets” they are about, has no know basic knowledge about Systems Architecture and commercial practice. The quoted statement creates a bad trap for many people who will follow or repeat this nonsense.

All right, at least someone accepts that SC, especially on a Blockchain, cannot be changed. In the era of highly dynamic and even accelerating markets, who need irreversible contracts?

Unfortunately, this is not the end of the story yet. There are several issues that should stop using SC anywhere but in the Blockchain and, possibly in it as well. Particularly:

1. “A blockchain-based smart contract is visible to all users of said blockchain. However, this leads to a situation where bugs, including security holes, are visible to all yet may not be quickly fixed” .
2. An SC is likely to carry personal information, which according to GDPR, may not be visible to unauthorised people. Thus, this data should be encrypted  and this leads to additional coupling between contract participants on the encryption/decryption solution
3. As we saw, any change in the SC is coder-dependent and constitute a new SC
4. The SC bugs are not fixable without a change (see the previous point)
5. Though we do not know how others develop SC, the control over the coder’s outcome is very difficult for business and they might have a challenge in the UAT before deployment. The same relates to the audit.

In all materials I read through, I have not found any practical consideration of how an SC can help in negotiation between to-be contracted parties. I think this matter is one of the technology dreams, especially on the Blockchain platform. All nice words about fast time to market with SC may be true, but they have to be weighed against troubles they can cause.

For the games in virtual reality, SC are good. However, they are way too immature to be seriously considered for business market. This ignorance of the practicality appearing more and more in technology innovations has become an epidemic illness – development, having minimal commercial knowledge, instead of disrupting business destroys it proposing business unsustainable and inefficient solutions. Things such as SC continue ignoring business execution context and have to go back into either virtual reality or into business-technology incubator. In many cases, fixing problems being already in the market is much more expensive than extending time-to-market a bit to think the innovation trough.