Blockchain technology is much broader than just bitcoin or other digital currencies. Sustained levels of robust security have been achieved by public cryptocurrencies. This demonstrated to the world that a new wave of blockchain technologies can provide efficiencies and intangible technological benefits very similar to what the Internet has done. The blockchain phenomenon is no longer just about bitcoin and cryptocurrency: it’s about “removing friction from any transaction-related process, including the process of reaching contractual agreements”. For this reason it is inevitable to talk about smart contracts. People assume that smart contracts are already becoming a cornerstone for enterprise blockchain applications and will likely become one of the pillars of blockchain technology. But are smart contracts always “smart”? Below I will explore smart contracts, both their legal and practical problems and whether they can be a comprehensive solution for future use cases.
II. Smart Contracts
1. Origin
The term smart contract does not have a clear or settled definition. Basically, smart contracts are computer programs that act as agreements where the terms of the agreement can be preprogrammed with the ability to self-execute or self-enforce itself. It operates mechanically and automatically and no human interference is needed. The main goal of a smart contract is to enable two or more anonymous parties to trade and do business with each other, usually over the Internet, without the need for a middleman. For this reason they are also called self-executing or digital contracts. The smart contract technology makes contracts much simpler to build and deploy.
Computer scientist Nick Szabo first coined the phrase “smart contracts” in his 1997 paper “Formalizing and Securing Relationships and Public Networks”. His goal was to bring what he called the “highly evolved” practices of contract law and related business practices to the design of electronic commerce protocols between strangers on the Internet. His work has been foundational to what smart contracts are becoming in the blockchain era. In his paper Szabo defined smart contracts as “a set of promises, specified in digital form, including protocols within which the parties perform on the other promises”. For him was “the basic idea behind smart contracts that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive…”.
Smart contracts would improve execution of the four basic contract objectives, which Szabo described as observability, verifiability, privity and enforceability. Among other use cases, smart contracts – according to Szabo – would enable both parties to observe the other’s performance of the contract. It would verify if and when a contract has been performed, guarantee that only the details necessary for completion of the contract are revealed to both parties and be self-enforcing to eliminate the time spent policing the contract. Furthermore, smart contracts reduce mental and computational transaction costs.
Traditional physical contracts, such as those created by legal professionals today, contain legal language on vast amounts of printed documents and heavily rely on third parties for enforcement. This type of enforcement is not only very time consuming, but also very ambiguous. Smart contracts have the potential to solve these problems. First, they can reduce costs. Second, they can cut legal paperwork and, consequently, time associated with each transaction. Thus, securing a transaction can take seconds instead of hours through smart contracts (Exhibit 1).
2. Blockchain
With blockchain there has been a renewed interest in smart contracts over the last couple of years. The first use of blockchain technology was the digital currency bitcoin. Systems today operate in a centralized model, which means that parties who wish to transact with each other do so via a central system. This leads to the problem that all parties have to trust this central system. Thus, people are dependent on third parties. Blockchain coupled with smart contract technologies removes the reliance on central systems between transacting parties. Instead of relying on a centralized authority to validate a contract between two counterparties, blockchain relies on digital code to confirm transactions. Therefore, the modern conception of a smart contract typically depends on blockchain technologies in a decentralized system.
Therefore the shared ledger of the blockchain itself is certainly significant, but what it enables matters most: it provides a way to validate transactions through little or no human intervention. Instead of involving lots of humans in the transaction pipeline and paper processes that take days, weeks or months to complete, huge volumes of transactions could be validated automatically.
III. Ethereum
Probably the most famous smart contract application is Ethereum. In late 2013, programmer and co-founder of Bitcoin Magazine, Vitalik Buterin, published a white paper detailing an innovative digital currency-powered technology platform known as Ethereum. It is an open-source, public, blockchain-based distributed computing platform featuring smart contract functionality. Ethereum was built on the same fundamental principles as Bitcoin: a blockchain protocol should be decentralized and its transaction ledger immutable. Additionally, it is a programming language (Turing complete), which runs on a blockchain and helps developers to build and publish distributed applications. In the Ethereum blockchain, instead of mining for bitcoin, miners work to earn ether, a type of crypto token that fuels the network. Ether can be transferred between participants and is used to compensate participant nodes for computations performed.
Ethereum’s live blockchain was launched in July 2015. Since then the price for Ethereum has been jumping from one all-time high in March 25, 2017 (Exhibit 2) to next one on May 1, 2017 (Exhibit 3). Even more impressive is Ethereum’s market cap. In less than two years, it has gone from zero to a market cap of around $7 billion in May 2017. Furthermore, Ethereum seed investment USD return is presently 148x and when placed in the context of “Time to Unicorn Valuation” it is ranked number 3 (Exhibit 4).
Bloomberg compares Ethereum to GoogleDocs and describes it as shared software that can be used by all but is tamperproof. The article goes as far as saying that there could be blockchain versions of Uber or Airbnb that are peer-to-peer. It means that no company would need to sit in the middle of the transaction to gather data about spending habits or collect a fee. Others fear that Ethereum may “face more security problems than bitcoin because of the greater complexity of the software”. The DAO has shown that Ethereum is all but perfect but it has also shown that these problems can be solved. Every new technology has bugs. Important is to learn from it and to seize the opportunity to improve day by day.
IV. Problems
According to the first paragraphs of the paper, it sounds like smart contracts are going to be the perfect solution to all future transactional and contractual questions. Smart contracts in combination with distributed ledger technologies have the potential to automate an extensive array of transactions and services within the financial services sector. However, the title “Smart Enough Contracts” indicates that smart contracts can bring new problems as well, and some use cases are simply impossible. As a result, the reality of smart contracts is more mundane. When getting past the theory and examining the practical with a legal eye, it is actually difficult to consider a smart contract as either smart or a contract. As a matter of fact, smart contracts are far from perfect. To this point, they are just automated computer code. Therefore, the term “smart contract” is somewhat misleading and it might be better to drop it. A more fitting name would likely be smart agent or smart program, as contract agreements are one, but not all of the expressions that can be archived.
1. Legal Problems
Advancements in blockchain technology have led some to believe that smart contracts could soon offer alternatives to traditional commercial and financial agreements. While this enthusiasm may be premature, the legal profession nonetheless remains mostly unaware of this important emerging technology and the long-term implications for their profession. Therefore, it is questionable whether code can replace the law. Technology solutions alone cannot realize the promise of smart contracts. In some ways a smart contract is similar to a traditional contract, as the parties that agree to this on both sides have to agree to the conditions that the contract will execute under. When it becomes ambiguous as to whether the conditions have been met, solutions could be trusted oracles, an option for arbitration or an acceptance of “the code is the law”. But there are also decisions that code cannot make. Such as, definitions and agreements that would have to be made by people, quite possibly specialists in legal advice. As a result, a full replacement is highly unlikely.
a. Enforceability
Smart contracts must be designed to ensure legal enforceability globally, with the strength of contractual law. A contract is a legal document between two parties. In order to be enforceable, the contract must contain several elements. If even one is missing, a contract may be voided and the parties will be excused from any obligations. In a smart contract, it is not guaranteed that all these elements exist. For instance, when the law limits or bars a person from engaging in specific activities, any agreements or contracts to do so are either voidable or void for incapacity. However, the parties do not have to reveal their identities in a smart contract. For example, in highly regulated industries, such as the financial services industry, it is a mandatory requirement to know your customer to prevent money laundering. With their decentralized processing, smart contracts obviate the need for customer credentials. This could prove to be problematic in the future.
b. Interpreting the law
The contract can only be executed without complication if both parties agree unequivocally that the conditions for the contract have been met. If either party disagrees, the contract can be challenged. Lawyers or even courts will have to interpret the clauses of the contract to decide, which parts of the contract have been fulfilled and in who’s favor. As a result, a contract often leaves ample room for interpretations, especially when a term is implied. Implied terms are not stated but nevertheless form a provision of a contract. Furthermore, smart contracts may often deal with commercial scenarios so complex and unpredictable that the code will fail to embed all possible answers to all possible questions. A smart contract, which is basically automated code, cannot interpret the law the same way a human being can and it can hardly read implied terms, which are not stated and therefore not part of the code. Otherwise every smart contract or code would be of an enormous size in order to guarantee every single possibility of interpretation. This would be very costly and time-consuming and therefore contradict the concepts of smart contracts. Code works on linear decision-making and probability, but more often than not, finding the right answer to settle a particular contractual nuance is a much more lateral process and requires a level of creativity and flexibility that can come only from real-life experience. To inject that depth of practical experience into code is probably an impossible task.
Additionally, since all processes are standardized and automated, users have to trust that the code and the network will function as expected. But what computer would be trusted to “execute” those terms in a way that both parties could rely upon? Parties must not only agree on the code of their contract, but also the computer, which interprets and executes that code. A shared standard, at the minimum, would have to exist, and be used in a way that was verifiable by each party.
c. Dispute Resolution
It would also be difficult to resolve disputes for smart contracts. Since algorithms are responsible for the contract, it becomes difficult to prove its validity and accountability in a court of law. What if incorrect code creates an argument between the contracted parties? Who is there to sort things out? As long as the parties have clearly accepted the terms, there is scope to litigate. As there is currently no international Internet law, the original contract would have to set out the jurisdictions of the parties and which country’s law the contract is reliant upon. How should governments regulate such contracts?
This shows that the legality of financial smart contracts is yet to be established. First steps have been taken in the US, by the State of Vermont, to recognize distributed ledgers in the state courts. Similarly, the US State of Delaware was the first state that recently launched a program to provide an enabling regulatory and legal environment for the development of blockchain technology. The Delaware Blockchain Initiative’s roadmap includes the issuance of legally-enforceable smart UCC filings, followed by the possible enactment of enabling and conforming legislation authorizing distributed-ledger shares and the offering of new registry services not presently offered by Delaware. Another key aspect to consider is an accurate translation of legal terms and conditions into software logic. Startups such as CommonAccord are working on a system that auto-translates legal documents into smart contracts, simplifying their interpretation by both lawyers and developers.
Legislators, regulators and governments have begun to realize the potential for distributed ledgers in increasing transparency and ease of compliance and reporting.
d. Conclusion
Until now, smart contracts will never fully replace natural-language law. Many types of agreements can never be fully expressed in code or executed by a computer; especially those that involve human performance rather than the exchange of dematerialized assets. Even fully self-executing contracts will ultimately need to make reference to legal terms and concepts that will define each party’s rights if their relationship leads to litigation. Many roles inside the business eco-system will need to be transformed. Lawyers must learn how to write computable code, and judges must learn how to interpret it, or rely on expert witnesses to testify valid interpretations. In the end, the evolution of smart contracts will lead to a re-evaluation of common practice. Both practitioners and clients will have to discover which types of agreements and terms are best suited to code, which should be left to natural language and how to provide a combined solution for both alternatives.
2. Practical Problems
Once initiated, the outcomes for which a smart contract is encoded to perform cannot usually be stopped. This can create many practical problems.
a. Safety
Smart contracts may be difficult to develop and implement where situations call for reversibility of transactions. They need to be error-free, error-tolerant or, in at least some way correctable because they are generally irrevocable or impossible to stop. Relying on “form” contracts is no guarantee of safety – especially not for smart contracts. A software consumer for example has an error correction process built into the software license. When something goes wrong, there will probably be someone to solve the problem. But smart contracts are not ordinary software. A smart contract is supposed to automatically implement a real-life contract: an actual agreement between two (or more) parties. After the negotiation, parties agree to the terms of a deal. Then, those terms are converted into a smart contract. But the parties don’t know whether the terms agreed upon were correctly programmed. If bugs get in the code, it could be problematic that the smart contract is stored on an immutable blockchain. Any errors or vulnerabilities are set in one ‘block of the chain’. The program code implementing the smart contract cannot immediately be debugged after being stored on an immutable blockchain.
b. The DAO
One good example of bugs that got in the code is The DAO. The DAO was a decentralized autonomous organization and a form of investor-directed venture capital fund. The project wanted to provide a new decentralized business model for organizing both non-profit and business model enterprises. It lived in the ether, which means that it ran as a DAO application on top of the Ethereum blockchain. Furthermore, it had no conventional management structure or board of directors and the code was open-source. Most importantly, The DAO was stateless, and not tied to any particular nation state. This, again, is a legal problem: many questions of how government regulators would deal with stateless funds were yet to be dealt with. Originally, the Ethereum creators had the vision that computer code should be treated as law in their community and serve as a replacement for legal agreements and regulation. Participants were supposed to look exclusively to the application’s code as dispositive on all matters.
Investors were able to send digital ethers to the fund, which allowed them to take part in votes on whether to put money in a given project. The token sale in May 2016 set the record for the largest crowd funding campaign in history and poured more than $150 million in form of ether into the project. Candidates for investment put themselves forward, providing not only a business plan, but also smart contracts that define the relationship between them and The DAO. Its creators hoped to prove that they could build a more democratic financial institution, one without centralized control or human fallibility. But the voting structure required a 20% quorum, which led to the outcome that none of these proposals were approved. In the end not only the voting structure failed, but the whole system: on June 17, 2016 The DAO was subject to a hack that deployed a combination of vulnerabilities and weaknesses. The hacker gained control of 3.6 million ether (valued at $50 million at the time of the hack).
Ethereum had to react after the theft and created a “hard fork”, a permanent split of the Ethereum blockchain, in order to reimburse investors. The hard fork restored virtually all funds to the original contract. The original unforked blockchain was maintained as Ethereum Classic, thus breaking Ethereum into two separate active cryptocurrencies.
The problem is that this event is not outside the law and law still has to apply in the real world. This raises many questions around liability and accountability of the implementation of the system and who could be sued to recover the lost value. Much of this is currently untested in court, however that is not to say that there are not applicable precedents in existing law.
Other people suggested, that there needs to be a new kind of due diligence for this new kind of contract. “Smart contracts blend law and computer science. The due diligence on smart contracts should do the same”.
c. Outside Events
Smart contracts will increase automation, which can be a good thing. But automation can also cause problems or be impossible, especially when a smart contract changes its behavior in response to some external event. For example, this could be an agricultural insurance policy that pays out conditionally based on the quantity of rainfall in a given month. In these cases, complete automation will not be possible.
In the example, the smart contract waits until the predetermined time, retrieves the weather report from an external service and behaves appropriately based on the data received. Every node on a chain executes smart contracts independently. If it now retrieves some information from an external source, each node performs this retrieval repeatedly and separately. But a blockchain only works if every node reaches an identical state after processing every transaction and block. Therefore, everything that takes place on the blockchain must be completely predetermined. No deviations are supposed to occur. Because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer. The moment that two nodes disagree about the chain’s state, the entire system fails. This could cause several problems. The source can change its response in the time between requests from different nodes or it could become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.
Therefore, smart contracts autonomously perform certain actions under certain pre-defined conditions, called oracles. Instead of a smart contract initiating the retrieval of external data, one or more trusted parties (“oracles”) create a transaction, which embeds data in the chain. Because every node runs every calculation, it’s not practical (and presently impossible) to make arbitrary network requests from a smart contract. Oracles fill this void by watching the blockchain for events and responding to them by publishing the results of a query back to the contract. In other words, an oracle pushes the data onto the blockchain rather than a smart contract pulling it in. In this way, contracts can interact with the off-chain world.
Oracles require a trusted entity to manage the interactions between the blockchain and the outside world though. This introduces obvious trust problems. A decentralized contract that requires trusting a single outside data source is a bit of a contradiction.
d. Future Events
A similar problem to the lack of legal interpretation is that a lot of the contracts are coded with the assumption that everything is going to happen as planned. However, there is a possibility that smart contracts perform in a specific way that may cause irreparable economic damage. Or they perform in specific situations when it makes no sense. For example, leasing companies could use smart contracts for their leasing agreements. On the one hand cars are unlocked via smart contracts and payments are automatically calculated and paid based on predefined terms of a contract. On the other hand, as soon as one customer is late with its payment, the product stops functioning automatically. At first glance, this seems to be a useful, practical solution. An automated process makes sure that the company can react immediately to missing payments. Furthermore, the leasing company does not have to worry that the customer uses the car or any other leasing product without paying for it. However, at a closer look an immediate reaction can cause a lot of trouble. Imagine, a person who entered a leasing agreement for a car and does not realize – for whatever reasons – that he or she is late with payments. This person will continue using his or her car regularly. In this situation, a late payment could occur while the person is driving the car on a highway. To avoid a negative outcome in these situations, a smart contract has to be flexible. Flexibility offers the ability to avoid the full anticipation of all possible outcomes. To date, smart contracts are not able to implement flexibility, as they only react on predefined code. A code must anticipate all possible solutions for all possible situations. As a result, it would be enormous in size. Furthermore, it is hardly conceivable that any agreement can provide for all contingencies.
The same problem arises when a smart contract may operate in states of the future that are unanticipated by either party.
V. Use Cases
But there are also potential use cases of smart contracts that extend far beyond the movement of digital cash. In general, smart contracts give the customer the insurance everything will happen as expected with the guarantee of a specific performance.
a. Examples
Indeed, smart contracts can be used to effectuate business activities involving purchases and exchanges of virtually any tangible or intangible goods, services and rights (e.g., sales of securities, commodities, personal property, real estate, digital rights, etc.). So, smart contracts could be used to create peer-to-peer versions of banks, securities exchanges, services such as eBay, Uber and Airbnb, and virtually every other business model involving intermediaries that handle processing and payments for a fee.
Furthermore, they can be used for secured corporate debt. In this case financial distress can be resolved ex ante by contract. Collateral can be conveyed automatically upon default and restrictive covenants are no longer necessary. Smart contracts can be a solution for derivative securities as well. Warrants, options, convertibles will exercise themselves automatically at the optimal time. Thus, state-contingent payoffs will be made automatically.
b. Automotive industry
Besides these examples, I have analyzed the auto industry. Chances are high that smart contracts could disrupt both car insurance and car sharing market.
(1) Insurance
Smart contract blockchain technologies could have a disruptive impact on the insurance market. The benefits of smart contracts in insurance are clear: in theory they should reduce insurer costs and lower premiums for policyholders and, importantly, improve customer experience of insurance products.
In the auto insurance industry, smart contracts can bring insurers, customers and third parties to a single platform. This can eventually lead to process efficiencies, and reduced claim processing time and costs. Automated claims payment processes will mean policy-holders will get paid more quickly in comparison to today’s manual processes, where even non-contested claim payments can take weeks or months to be paid. Also, third-parties such as garages, transport providers and hospitals – once they are part of the distributed ledger – will be able to provide quicker support against claims to customers and can expect faster settlement of claims. With data fed into such technologies, policy adjustments could be made automatically in response to certain pre-determined events or information received. Smart contracts’ inflexibility can also have a positive side effect. They tend to avoid the textual ambiguity of traditional contracts, preventing legal disputes. Because the rules of the smart contract are pre-programmed, the contract would only execute as specified. The programmable character also allows for less insurance fraud. A car insurance payout could only be used for repairs at certified parties. Whether someone actually follows the rules is no longer verified in the bureaucratic process afterwards. The payout can even be programmed in such a way that it will automatically return to the insurer if the receiver doesn’t use it within a certain amount of time.
(2) Car-Sharing
Smart contracts can also be applied in the car-sharing industry. Cars are often one of the most expensive assets that individuals own; yet they are usually parked (and not used) 95% of the time. Less and less people desire to own a car, which makes car ownership the next industry to be disrupted by technology. In the future, a peer-to-peer smart contract system to rent driverless cars could be created to effectively compete with both engaging a car service for short trips and renting a car for longer journeys. It could anticipate requirements and preferences based on data stored on the user’s digital devices, online databases and other information sources. Hence, a user would only have to input any modifications to the system’s proposals on the user interface. The next steps would be automated processes: the system searches and verifies the features of participating cars, perform matching functions based on availability and current location, send the driverless car to the user, disburse payments, and repeat the process when the vehicle reaches its destination. Besides that, a party that breaches its obligations will be penalized immediately. The smart contract could automatically initiate a protocol to financially penalize the defaulting party and provide the aggrieved party with a monetary remedy.
Hence, this system could have a huge disruptive effect on (i) car manufacturers, (use optimization would presumably reduce sales) (ii) insurance companies (fewer car policies will be sold) (iii) financial institutions (fewer car loans); and (iv) taxi companies, parking facilities and other businesses. This process would displace them all.
VI. Conclusion
In conclusion, smart contracts are a great promise, but even greater challenges lie ahead. Blockchain-based transaction validation won’t be sufficient in all circumstances. Complex transactions will still require human interaction. While other products have run through decades of development, deployment, testing, debugging and code optimization, blockchain is a technology at an early stage of development. The idea for smart contracts was born, but developers with blockchain (and legal) expertise are hard to find to bring this idea to an advanced level. But there is hope that smart contracts will become more sophisticated over time. It is likely that once a model is demonstrated to work in a live environment that it will be adopted elsewhere.
The success of bitcoin’s blockchain technology has been pivotal: an automation-friendly transaction environment in a wide-open setting could be protected and could function reliably. Due to efforts of Szabo, the Ethereum project, and others computable contract technology itself is not the obstacle. The true obstacle is a human-centric legal process that in some cases has been in place since ancient Rome. The next stage should go a step or two beyond what has already been developed. Thus, it is an evolution, not a revolution.
II. Smart Contracts
1. Origin
The term smart contract does not have a clear or settled definition. Basically, smart contracts are computer programs that act as agreements where the terms of the agreement can be preprogrammed with the ability to self-execute or self-enforce itself. It operates mechanically and automatically and no human interference is needed. The main goal of a smart contract is to enable two or more anonymous parties to trade and do business with each other, usually over the Internet, without the need for a middleman. For this reason they are also called self-executing or digital contracts. The smart contract technology makes contracts much simpler to build and deploy.
Computer scientist Nick Szabo first coined the phrase “smart contracts” in his 1997 paper “Formalizing and Securing Relationships and Public Networks”. His goal was to bring what he called the “highly evolved” practices of contract law and related business practices to the design of electronic commerce protocols between strangers on the Internet. His work has been foundational to what smart contracts are becoming in the blockchain era. In his paper Szabo defined smart contracts as “a set of promises, specified in digital form, including protocols within which the parties perform on the other promises”. For him was “the basic idea behind smart contracts that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive…”.
Smart contracts would improve execution of the four basic contract objectives, which Szabo described as observability, verifiability, privity and enforceability. Among other use cases, smart contracts – according to Szabo – would enable both parties to observe the other’s performance of the contract. It would verify if and when a contract has been performed, guarantee that only the details necessary for completion of the contract are revealed to both parties and be self-enforcing to eliminate the time spent policing the contract. Furthermore, smart contracts reduce mental and computational transaction costs.
Traditional physical contracts, such as those created by legal professionals today, contain legal language on vast amounts of printed documents and heavily rely on third parties for enforcement. This type of enforcement is not only very time consuming, but also very ambiguous. Smart contracts have the potential to solve these problems. First, they can reduce costs. Second, they can cut legal paperwork and, consequently, time associated with each transaction. Thus, securing a transaction can take seconds instead of hours through smart contracts (Exhibit 1).
2. Blockchain
With blockchain there has been a renewed interest in smart contracts over the last couple of years. The first use of blockchain technology was the digital currency bitcoin. Systems today operate in a centralized model, which means that parties who wish to transact with each other do so via a central system. This leads to the problem that all parties have to trust this central system. Thus, people are dependent on third parties. Blockchain coupled with smart contract technologies removes the reliance on central systems between transacting parties. Instead of relying on a centralized authority to validate a contract between two counterparties, blockchain relies on digital code to confirm transactions. Therefore, the modern conception of a smart contract typically depends on blockchain technologies in a decentralized system.
Therefore the shared ledger of the blockchain itself is certainly significant, but what it enables matters most: it provides a way to validate transactions through little or no human intervention. Instead of involving lots of humans in the transaction pipeline and paper processes that take days, weeks or months to complete, huge volumes of transactions could be validated automatically.
III. Ethereum
Probably the most famous smart contract application is Ethereum. In late 2013, programmer and co-founder of Bitcoin Magazine, Vitalik Buterin, published a white paper detailing an innovative digital currency-powered technology platform known as Ethereum. It is an open-source, public, blockchain-based distributed computing platform featuring smart contract functionality. Ethereum was built on the same fundamental principles as Bitcoin: a blockchain protocol should be decentralized and its transaction ledger immutable. Additionally, it is a programming language (Turing complete), which runs on a blockchain and helps developers to build and publish distributed applications. In the Ethereum blockchain, instead of mining for bitcoin, miners work to earn ether, a type of crypto token that fuels the network. Ether can be transferred between participants and is used to compensate participant nodes for computations performed.
Ethereum’s live blockchain was launched in July 2015. Since then the price for Ethereum has been jumping from one all-time high in March 25, 2017 (Exhibit 2) to next one on May 1, 2017 (Exhibit 3). Even more impressive is Ethereum’s market cap. In less than two years, it has gone from zero to a market cap of around $7 billion in May 2017. Furthermore, Ethereum seed investment USD return is presently 148x and when placed in the context of “Time to Unicorn Valuation” it is ranked number 3 (Exhibit 4).
Bloomberg compares Ethereum to GoogleDocs and describes it as shared software that can be used by all but is tamperproof. The article goes as far as saying that there could be blockchain versions of Uber or Airbnb that are peer-to-peer. It means that no company would need to sit in the middle of the transaction to gather data about spending habits or collect a fee. Others fear that Ethereum may “face more security problems than bitcoin because of the greater complexity of the software”. The DAO has shown that Ethereum is all but perfect but it has also shown that these problems can be solved. Every new technology has bugs. Important is to learn from it and to seize the opportunity to improve day by day.
IV. Problems
According to the first paragraphs of the paper, it sounds like smart contracts are going to be the perfect solution to all future transactional and contractual questions. Smart contracts in combination with distributed ledger technologies have the potential to automate an extensive array of transactions and services within the financial services sector. However, the title “Smart Enough Contracts” indicates that smart contracts can bring new problems as well, and some use cases are simply impossible. As a result, the reality of smart contracts is more mundane. When getting past the theory and examining the practical with a legal eye, it is actually difficult to consider a smart contract as either smart or a contract. As a matter of fact, smart contracts are far from perfect. To this point, they are just automated computer code. Therefore, the term “smart contract” is somewhat misleading and it might be better to drop it. A more fitting name would likely be smart agent or smart program, as contract agreements are one, but not all of the expressions that can be archived.
1. Legal Problems
Advancements in blockchain technology have led some to believe that smart contracts could soon offer alternatives to traditional commercial and financial agreements. While this enthusiasm may be premature, the legal profession nonetheless remains mostly unaware of this important emerging technology and the long-term implications for their profession. Therefore, it is questionable whether code can replace the law. Technology solutions alone cannot realize the promise of smart contracts. In some ways a smart contract is similar to a traditional contract, as the parties that agree to this on both sides have to agree to the conditions that the contract will execute under. When it becomes ambiguous as to whether the conditions have been met, solutions could be trusted oracles, an option for arbitration or an acceptance of “the code is the law”. But there are also decisions that code cannot make. Such as, definitions and agreements that would have to be made by people, quite possibly specialists in legal advice. As a result, a full replacement is highly unlikely.
a. Enforceability
Smart contracts must be designed to ensure legal enforceability globally, with the strength of contractual law. A contract is a legal document between two parties. In order to be enforceable, the contract must contain several elements. If even one is missing, a contract may be voided and the parties will be excused from any obligations. In a smart contract, it is not guaranteed that all these elements exist. For instance, when the law limits or bars a person from engaging in specific activities, any agreements or contracts to do so are either voidable or void for incapacity. However, the parties do not have to reveal their identities in a smart contract. For example, in highly regulated industries, such as the financial services industry, it is a mandatory requirement to know your customer to prevent money laundering. With their decentralized processing, smart contracts obviate the need for customer credentials. This could prove to be problematic in the future.
b. Interpreting the law
The contract can only be executed without complication if both parties agree unequivocally that the conditions for the contract have been met. If either party disagrees, the contract can be challenged. Lawyers or even courts will have to interpret the clauses of the contract to decide, which parts of the contract have been fulfilled and in who’s favor. As a result, a contract often leaves ample room for interpretations, especially when a term is implied. Implied terms are not stated but nevertheless form a provision of a contract. Furthermore, smart contracts may often deal with commercial scenarios so complex and unpredictable that the code will fail to embed all possible answers to all possible questions. A smart contract, which is basically automated code, cannot interpret the law the same way a human being can and it can hardly read implied terms, which are not stated and therefore not part of the code. Otherwise every smart contract or code would be of an enormous size in order to guarantee every single possibility of interpretation. This would be very costly and time-consuming and therefore contradict the concepts of smart contracts. Code works on linear decision-making and probability, but more often than not, finding the right answer to settle a particular contractual nuance is a much more lateral process and requires a level of creativity and flexibility that can come only from real-life experience. To inject that depth of practical experience into code is probably an impossible task.
Additionally, since all processes are standardized and automated, users have to trust that the code and the network will function as expected. But what computer would be trusted to “execute” those terms in a way that both parties could rely upon? Parties must not only agree on the code of their contract, but also the computer, which interprets and executes that code. A shared standard, at the minimum, would have to exist, and be used in a way that was verifiable by each party.
c. Dispute Resolution
It would also be difficult to resolve disputes for smart contracts. Since algorithms are responsible for the contract, it becomes difficult to prove its validity and accountability in a court of law. What if incorrect code creates an argument between the contracted parties? Who is there to sort things out? As long as the parties have clearly accepted the terms, there is scope to litigate. As there is currently no international Internet law, the original contract would have to set out the jurisdictions of the parties and which country’s law the contract is reliant upon. How should governments regulate such contracts?
This shows that the legality of financial smart contracts is yet to be established. First steps have been taken in the US, by the State of Vermont, to recognize distributed ledgers in the state courts. Similarly, the US State of Delaware was the first state that recently launched a program to provide an enabling regulatory and legal environment for the development of blockchain technology. The Delaware Blockchain Initiative’s roadmap includes the issuance of legally-enforceable smart UCC filings, followed by the possible enactment of enabling and conforming legislation authorizing distributed-ledger shares and the offering of new registry services not presently offered by Delaware. Another key aspect to consider is an accurate translation of legal terms and conditions into software logic. Startups such as CommonAccord are working on a system that auto-translates legal documents into smart contracts, simplifying their interpretation by both lawyers and developers.
Legislators, regulators and governments have begun to realize the potential for distributed ledgers in increasing transparency and ease of compliance and reporting.
d. Conclusion
Until now, smart contracts will never fully replace natural-language law. Many types of agreements can never be fully expressed in code or executed by a computer; especially those that involve human performance rather than the exchange of dematerialized assets. Even fully self-executing contracts will ultimately need to make reference to legal terms and concepts that will define each party’s rights if their relationship leads to litigation. Many roles inside the business eco-system will need to be transformed. Lawyers must learn how to write computable code, and judges must learn how to interpret it, or rely on expert witnesses to testify valid interpretations. In the end, the evolution of smart contracts will lead to a re-evaluation of common practice. Both practitioners and clients will have to discover which types of agreements and terms are best suited to code, which should be left to natural language and how to provide a combined solution for both alternatives.
2. Practical Problems
Once initiated, the outcomes for which a smart contract is encoded to perform cannot usually be stopped. This can create many practical problems.
a. Safety
Smart contracts may be difficult to develop and implement where situations call for reversibility of transactions. They need to be error-free, error-tolerant or, in at least some way correctable because they are generally irrevocable or impossible to stop. Relying on “form” contracts is no guarantee of safety – especially not for smart contracts. A software consumer for example has an error correction process built into the software license. When something goes wrong, there will probably be someone to solve the problem. But smart contracts are not ordinary software. A smart contract is supposed to automatically implement a real-life contract: an actual agreement between two (or more) parties. After the negotiation, parties agree to the terms of a deal. Then, those terms are converted into a smart contract. But the parties don’t know whether the terms agreed upon were correctly programmed. If bugs get in the code, it could be problematic that the smart contract is stored on an immutable blockchain. Any errors or vulnerabilities are set in one ‘block of the chain’. The program code implementing the smart contract cannot immediately be debugged after being stored on an immutable blockchain.
b. The DAO
One good example of bugs that got in the code is The DAO. The DAO was a decentralized autonomous organization and a form of investor-directed venture capital fund. The project wanted to provide a new decentralized business model for organizing both non-profit and business model enterprises. It lived in the ether, which means that it ran as a DAO application on top of the Ethereum blockchain. Furthermore, it had no conventional management structure or board of directors and the code was open-source. Most importantly, The DAO was stateless, and not tied to any particular nation state. This, again, is a legal problem: many questions of how government regulators would deal with stateless funds were yet to be dealt with. Originally, the Ethereum creators had the vision that computer code should be treated as law in their community and serve as a replacement for legal agreements and regulation. Participants were supposed to look exclusively to the application’s code as dispositive on all matters.
Investors were able to send digital ethers to the fund, which allowed them to take part in votes on whether to put money in a given project. The token sale in May 2016 set the record for the largest crowd funding campaign in history and poured more than $150 million in form of ether into the project. Candidates for investment put themselves forward, providing not only a business plan, but also smart contracts that define the relationship between them and The DAO. Its creators hoped to prove that they could build a more democratic financial institution, one without centralized control or human fallibility. But the voting structure required a 20% quorum, which led to the outcome that none of these proposals were approved. In the end not only the voting structure failed, but the whole system: on June 17, 2016 The DAO was subject to a hack that deployed a combination of vulnerabilities and weaknesses. The hacker gained control of 3.6 million ether (valued at $50 million at the time of the hack).
Ethereum had to react after the theft and created a “hard fork”, a permanent split of the Ethereum blockchain, in order to reimburse investors. The hard fork restored virtually all funds to the original contract. The original unforked blockchain was maintained as Ethereum Classic, thus breaking Ethereum into two separate active cryptocurrencies.
The problem is that this event is not outside the law and law still has to apply in the real world. This raises many questions around liability and accountability of the implementation of the system and who could be sued to recover the lost value. Much of this is currently untested in court, however that is not to say that there are not applicable precedents in existing law.
Other people suggested, that there needs to be a new kind of due diligence for this new kind of contract. “Smart contracts blend law and computer science. The due diligence on smart contracts should do the same”.
c. Outside Events
Smart contracts will increase automation, which can be a good thing. But automation can also cause problems or be impossible, especially when a smart contract changes its behavior in response to some external event. For example, this could be an agricultural insurance policy that pays out conditionally based on the quantity of rainfall in a given month. In these cases, complete automation will not be possible.
In the example, the smart contract waits until the predetermined time, retrieves the weather report from an external service and behaves appropriately based on the data received. Every node on a chain executes smart contracts independently. If it now retrieves some information from an external source, each node performs this retrieval repeatedly and separately. But a blockchain only works if every node reaches an identical state after processing every transaction and block. Therefore, everything that takes place on the blockchain must be completely predetermined. No deviations are supposed to occur. Because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer. The moment that two nodes disagree about the chain’s state, the entire system fails. This could cause several problems. The source can change its response in the time between requests from different nodes or it could become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.
Therefore, smart contracts autonomously perform certain actions under certain pre-defined conditions, called oracles. Instead of a smart contract initiating the retrieval of external data, one or more trusted parties (“oracles”) create a transaction, which embeds data in the chain. Because every node runs every calculation, it’s not practical (and presently impossible) to make arbitrary network requests from a smart contract. Oracles fill this void by watching the blockchain for events and responding to them by publishing the results of a query back to the contract. In other words, an oracle pushes the data onto the blockchain rather than a smart contract pulling it in. In this way, contracts can interact with the off-chain world.
Oracles require a trusted entity to manage the interactions between the blockchain and the outside world though. This introduces obvious trust problems. A decentralized contract that requires trusting a single outside data source is a bit of a contradiction.
d. Future Events
A similar problem to the lack of legal interpretation is that a lot of the contracts are coded with the assumption that everything is going to happen as planned. However, there is a possibility that smart contracts perform in a specific way that may cause irreparable economic damage. Or they perform in specific situations when it makes no sense. For example, leasing companies could use smart contracts for their leasing agreements. On the one hand cars are unlocked via smart contracts and payments are automatically calculated and paid based on predefined terms of a contract. On the other hand, as soon as one customer is late with its payment, the product stops functioning automatically. At first glance, this seems to be a useful, practical solution. An automated process makes sure that the company can react immediately to missing payments. Furthermore, the leasing company does not have to worry that the customer uses the car or any other leasing product without paying for it. However, at a closer look an immediate reaction can cause a lot of trouble. Imagine, a person who entered a leasing agreement for a car and does not realize – for whatever reasons – that he or she is late with payments. This person will continue using his or her car regularly. In this situation, a late payment could occur while the person is driving the car on a highway. To avoid a negative outcome in these situations, a smart contract has to be flexible. Flexibility offers the ability to avoid the full anticipation of all possible outcomes. To date, smart contracts are not able to implement flexibility, as they only react on predefined code. A code must anticipate all possible solutions for all possible situations. As a result, it would be enormous in size. Furthermore, it is hardly conceivable that any agreement can provide for all contingencies.
The same problem arises when a smart contract may operate in states of the future that are unanticipated by either party.
V. Use Cases
But there are also potential use cases of smart contracts that extend far beyond the movement of digital cash. In general, smart contracts give the customer the insurance everything will happen as expected with the guarantee of a specific performance.
a. Examples
Indeed, smart contracts can be used to effectuate business activities involving purchases and exchanges of virtually any tangible or intangible goods, services and rights (e.g., sales of securities, commodities, personal property, real estate, digital rights, etc.). So, smart contracts could be used to create peer-to-peer versions of banks, securities exchanges, services such as eBay, Uber and Airbnb, and virtually every other business model involving intermediaries that handle processing and payments for a fee.
Furthermore, they can be used for secured corporate debt. In this case financial distress can be resolved ex ante by contract. Collateral can be conveyed automatically upon default and restrictive covenants are no longer necessary. Smart contracts can be a solution for derivative securities as well. Warrants, options, convertibles will exercise themselves automatically at the optimal time. Thus, state-contingent payoffs will be made automatically.
b. Automotive industry
Besides these examples, I have analyzed the auto industry. Chances are high that smart contracts could disrupt both car insurance and car sharing market.
(1) Insurance
Smart contract blockchain technologies could have a disruptive impact on the insurance market. The benefits of smart contracts in insurance are clear: in theory they should reduce insurer costs and lower premiums for policyholders and, importantly, improve customer experience of insurance products.
In the auto insurance industry, smart contracts can bring insurers, customers and third parties to a single platform. This can eventually lead to process efficiencies, and reduced claim processing time and costs. Automated claims payment processes will mean policy-holders will get paid more quickly in comparison to today’s manual processes, where even non-contested claim payments can take weeks or months to be paid. Also, third-parties such as garages, transport providers and hospitals – once they are part of the distributed ledger – will be able to provide quicker support against claims to customers and can expect faster settlement of claims. With data fed into such technologies, policy adjustments could be made automatically in response to certain pre-determined events or information received. Smart contracts’ inflexibility can also have a positive side effect. They tend to avoid the textual ambiguity of traditional contracts, preventing legal disputes. Because the rules of the smart contract are pre-programmed, the contract would only execute as specified. The programmable character also allows for less insurance fraud. A car insurance payout could only be used for repairs at certified parties. Whether someone actually follows the rules is no longer verified in the bureaucratic process afterwards. The payout can even be programmed in such a way that it will automatically return to the insurer if the receiver doesn’t use it within a certain amount of time.
(2) Car-Sharing
Smart contracts can also be applied in the car-sharing industry. Cars are often one of the most expensive assets that individuals own; yet they are usually parked (and not used) 95% of the time. Less and less people desire to own a car, which makes car ownership the next industry to be disrupted by technology. In the future, a peer-to-peer smart contract system to rent driverless cars could be created to effectively compete with both engaging a car service for short trips and renting a car for longer journeys. It could anticipate requirements and preferences based on data stored on the user’s digital devices, online databases and other information sources. Hence, a user would only have to input any modifications to the system’s proposals on the user interface. The next steps would be automated processes: the system searches and verifies the features of participating cars, perform matching functions based on availability and current location, send the driverless car to the user, disburse payments, and repeat the process when the vehicle reaches its destination. Besides that, a party that breaches its obligations will be penalized immediately. The smart contract could automatically initiate a protocol to financially penalize the defaulting party and provide the aggrieved party with a monetary remedy.
Hence, this system could have a huge disruptive effect on (i) car manufacturers, (use optimization would presumably reduce sales) (ii) insurance companies (fewer car policies will be sold) (iii) financial institutions (fewer car loans); and (iv) taxi companies, parking facilities and other businesses. This process would displace them all.
VI. Conclusion
In conclusion, smart contracts are a great promise, but even greater challenges lie ahead. Blockchain-based transaction validation won’t be sufficient in all circumstances. Complex transactions will still require human interaction. While other products have run through decades of development, deployment, testing, debugging and code optimization, blockchain is a technology at an early stage of development. The idea for smart contracts was born, but developers with blockchain (and legal) expertise are hard to find to bring this idea to an advanced level. But there is hope that smart contracts will become more sophisticated over time. It is likely that once a model is demonstrated to work in a live environment that it will be adopted elsewhere.
The success of bitcoin’s blockchain technology has been pivotal: an automation-friendly transaction environment in a wide-open setting could be protected and could function reliably. Due to efforts of Szabo, the Ethereum project, and others computable contract technology itself is not the obstacle. The true obstacle is a human-centric legal process that in some cases has been in place since ancient Rome. The next stage should go a step or two beyond what has already been developed. Thus, it is an evolution, not a revolution.