Smart contracts have become popular due to the extensibility of the Ethereum blockchain beyond its main foundation as a cryptocurrency platform, where it competes with Bitcoin. The phrase ‘smart contract’ caught on in the popular imagination. After all, contracts are important mechanisms for transacting business, and what better than to make our contracts smart with computers and artificial intelligence.

Unfortunately, the glib phrase ‘smart contracts’ hides the ugly truth, which consists of three fallacies:

1. Smart contracts are smart
2. Smart contracts are contracts
3. Smart contracts are comprehensible

Smart contracts are approximately dumb

There’s nothing smart about smart contracts. Perhaps ‘smart’ is a matter of definition, so let me rephrase. If a simple “Hello, World!” program is considered smart, then so is a smart contract ‘smart.’ Maybe we can raise the bar one notch. Let us consider a simple program that, when you access it, determines the time of day (wherever the server on which the program runs or perhaps the browser from which a user invokes it). The code in the program implements the following logic:

If Time >= 6:00 am AND Time < 11:30 am THEN say “Hello, good morning!”

If Time >= 11:30 am AND Time < 3:00 pm THEN say “Hello, good afternoon!”

If Time >= 2:00 pm AND Time < 9:00 pm THEN say “Hello, good evening!”

If Time >= 9:00 pm AND Time <= 12:00 am THEN say “Good night, sleep well!”

If Time > 12:00 am AND Time < 6:00 am THEN say “Hi, you are up late – or did you get up early?”

The above are examples of what is called an IFTTT or “If This Then That” code. This is a bit more intelligent, but just barely. However, this is not necessarily smart enough in the financial world. The ERC-20 and its derivatives in the Ethereum world would have, one hopes, a bit more complicated IFTTT ‘rules’. For example, the protocol has a function that checks to see if the sender of the cryptocurrency actually has the amount in their account. This check is obviously important and a ‘smart’ thing to do. But, this type of check is performed by your bank when you use your bank’s debit card or credit card. However, banks don’t call their cards ‘smart cards’, even though there is more intelligence built into card processing than we give credit for.

In the age of artificial intelligence and machine learning, calling the above types of simple functionality ‘smart’ is an insult to the definition of ‘smart’. Even the earliest examples of AI software of the 60s were smarter. So, calling these ‘smart contracts’ smart is a throwback to prehistoric days of software engineering.

Incidentally, the moniker “IFTTT” is a bit of intellectual plagiaristic packaging passing off as a recent innovation. In reality, IFTTT has been around ever since the very first days of computing. All programmers know this, as well as it’s cousin, IFTTTE, which is “If This Then That Else.” Enough of this remarketing of old and well-known programming constructs.

Smart contracts are not contracts

Technologists who drool over smart contracts are obviously unfamiliar with what constitutes a contract. A loose definition of ‘contract’ may be fine for most casual applications, but for the financial world, the definition has to be legal and enforceable. Legally enforceable contracts have certain specific characteristics without which they don’t stand a chance of being defensible or enforceable. These characteristics include offer and acceptance, competence, unforced, mutual consideration, legal intent, and enforceable.

Transactions involving cryptocurrency or security tokens do not automatically become contracts because the transactions may violate one or more of the above provisions.

1. Offer and Acceptance: One of the parties must make an offer; the other must accept it. The offer and acceptance are subject to the other requirements of contracts. For example, if someone comes up to your car when you are stopped at a red light, polishes your windshield without your consent, and demands payment, it does not obligate you, legally or morally, to pay; there was no offer of a service and you did not consent to the polishing of your windshield.
2. Competence: Both parties must be of sound mind and competent to enter into a contractual relationship. For example, those who are mentally incompetent (in the legal sense) and minors may not enter into contracts. This assumes that the identity of the parties is known to each other and each party – or perhaps an intermediary – can assess competence. This may not be true in a decentralized crypto world.
3. Unforced: Both parties must have entered into the contract of their own free will and knowledge. This may not be true in the crypto world where cryptocurrency can be stolen, forced at gunpoint, or mistakenly sent to another party. In all cases, the sender (or victim) has no recourse or recovery.
4. Due mutual consideration: All parties to the contract must receive something in return in this exchange; transactions cannot be one-sided (gifts are not contracts, by definition, but otherwise perfectly legal). In a crypto world, there may not be clarity about exactly what this due consideration is and if it was mutual.
5. Moral and legal intent: A contract to kill someone or commit an immoral act is null and void. A payment for such an action is illegal and does not constitute a contract. Obviously, this may not be easy to detect in a crypto world.
6. Enforceable: The performance of the terms of the contract must be enforceable and observable. None of this may be true in the crypto world, because in a decentralized system with no governance, no auditing, and indeed no identity, who could observe and who could enforce?

Smart contracts are incomprehensible

In general, people find regular contracts impenetrable, especially the fine print clauses. The article “Does Anyone Read the Fine Print? Consumer Attention to Standard Form Contracts” (by Yannis Bakos, Florencia Marotta-Wurgler, and David R. Trossen) generally concludes, unsurprisingly, that very few people do so.

In those rare cases when people read contracts, they may not actually understand them fully. Contrary to popular feeling, legal contracts are not obtuse by deliberate intention. If anything, they are as incredibly precise (or at least, strive to be) as possible without the use of mathematics. Despite the attempt at precision, there is still room for miscommunication and misunderstanding, whether that is due to the inexperience of the legal counsel (rare), the inexperience of the participants (very often), or the lack of clarity of the underlying regulation (probably rather common). When the application of the law is unclear in complicated cases, the courts resort to case law. All this points to the difficulty of understanding legal contracts. If that is not persuasive enough, consider that just about in all lawsuits both parties have previously signed contracts that were drafted and reviewed by experienced lawyers on both sides, yet one of the participants had to resort to a lawsuit.

In the case of smart contracts, the primary representation of the so-called contract is not the legal document but the computer program. Even simple transactions, when implemented in code, are very difficult to understand. Computer programmers are notorious for being poor documenters (or for their writing skills in general). What is less well-known is that programmers are deeply reluctant to read other programmers’ code because code is generally impenetrable, even when that code has been written by the same programmer who is reviewing it after a lapse of time.

Lay participants of contracts, such as investors and issuers, are asked to read the code in order to infer the underlying legal provisions! This is several steps removed from the requirement to read the actual legal document itself. Every step in the process has enormous potential for misrepresentation, misinterpretation, information loss, and outright incomprehensibility.

Indeed, the research data shows that many ICOs have “backdoor centralization”, but in the most negative sense of the term (unlike responsibly governed centralization), including pump-and-dump, insider trading, no expression in code of promises made on the website or whitepaper, unauthorized and unadvertised rights of modifiability, and so on. See “New Research Finds Backdoor ‘Centralized Control’ In Many ICOs” for a good summary.

You may think that the situation with smart contracts cannot be direr. But wait, it gets worse! In a 104-page study, “Coin-Operated Capitalism,” by the University of Pennsylvania Law School, “If ICO investors  were scrutinizing smart contract code before buying into an ICO, we would expect to see (all else [being] equal) higher capital raises by teams that faithfully coded supply and vesting protections, and also disclosed their modification powers. We find no evidence of that effect in our sample.”

What this means is that ICO investors are either the dumb money (generally, the uninformed retail investors), highly speculative and risk-tolerant (hopefully in amounts small enough not to matter, or those with intense fear-of-missing-out), or outright criminal in nature with deeper motives. Obviously, this is a general conclusion and does not implicate the legitimate investors who may have invested in ICOs for diversification (though the use of the word ‘invest’ or ‘diversification’ in connection with ICOs is highly suspect).

As far as ICOs go, none of this should paint all ICOs with the same broad brush. But it does call into question the underlying architectural philosophy of smart contracts in general. Smart contracts should be designed by lawyers because smart contracts are primarily contracts. Only when contracts are truly legal contracts can technologists then strive to make them more or less automated and intelligent. All this automation should be wrapped into governance, risk, audit, and manual review functions precisely because even the smartest contracts cannot anticipate all scenarios in the real world.

Now, that’s smart!