Smart Contracts in blockchain

Aspire Thought Leadership! Ever wondered about smart contracts in blockchain?. Find out more on what has changed with smart contracts in blockchain in

A Contract is an agreement with specific terms between two or more persons or entities in which there is a promise to do something in return for a valuable benefit known as consideration. According to The Free Dictionary, “a contract is an offer, an acceptance of that offer results in a meeting of the minds”. Contracts which describe and enforce rules for trade and barter were in use in ancient times, and modern contract law is traceable from the industrial revolution. Centuries of trade has resulted in sophisticated paper-based contracts with supporting practices like contract law concerning with the rights and duties that arise from agreements. In this post we will learn more about smart contracts in blockchain

The digital age has affected contracting practices. Digital contracting has existed for several decades and in various forms. For example, Electronic Data Interchange (EDI) used by large corporations to share data among themselves, data-oriented contracts which allow machines to take automatic actions based on events, and computable contracts which take the information expressed by data-oriented contracts and execute business logic to enforce the terms of the contract. A data-oriented contract may have some contractual conditions encoded in a computer language such as the expiration date and amount owned. A computable contract can take the information from a data-oriented contract and execute business logic to send an invoice for the final amount based on cash flows until that date.

Smart Contracts in blockchain

Contracts evolving from electronic to data-oriented, and again to computable denotes a trend towards greater automation. Expressing contract terms as data is significant since it enables computer-based contracting abilities that bypass the pitfalls of parsing plain-text contracts either via lawyers or the use of natural-text processing capabilities.

What are Smart Contracts?

In 1996-97, Nick Szabo outlined the functional and technical requirements for contracts embedded in software and hardware in such a way as to make the breach of contract expensive. He labeled such contracts “Smart Contracts”. According to his definition, a smart contract “facilitate all steps of the contracting process” and included the aspects of search, negotiation, commitment, performance, and adjudication. The visionary thinking was that hardware and software alone could handle the full lifecycle of activities related to a contract.

The general understanding of smart contracts evolved, with the rise of Bitcoin and its success in decentralized trusted financial transactions. In 2003, Mark Miller theorized Smart Contracts are “contracts as program code, where the terms of the contract are enforced by the logic of the program’s execution.” Richard Gendal-Brown stated that “A smart-contract is an event-driven, stateful, program which runs on a replicated, shared ledger and which can take custody of assets on that ledger.” Vitalik Buterin’s defined them as “a computer program that directly controls digital assets and which is run in such an environment that it can be trusted to execute faithfully.”

Szabo’s smart contract concept required no fancy technology. His primary example was that of the electronic mechanism in a vending machine which performs two critical functions: It directly enforces operation by taking in money and dispensing products, and second, it incorporates enough security to make the cost of a breach (breaking into the machine) exceed the potential reward.

Consider a standard employment agreement between an employee and employer. The employee agrees to work 40 hours per week, and the employer pays out the wages bi-monthly. If a vacation is longer than two weeks, the employeer deducts it from salary. Thus we can define an employment contract:

(1) On PayDay
a. Calculate the number of hours worked last 14 days;
(2) Credit into an employee account
a. numHours * hourlywage;

An employer could implement the above ‘smart’ contract by deploying it on an employment blockchain and sharing it with all employees and other entities (such as trade unions, insurance companies, Ministry of Labor, and so on). Execution of the contractual terms encoded in the contract is based upon an external event, in this case, passing time.

Smart contracts are agreements codified and running on the blockchain. Blockchain lends itself to smart contracts with its ability to establish trust in transactions. A permissionless blockchain such as Bitcoin incentivizes miners to perform with honesty and rewards them in the form of bitcoins for both solving puzzles on a sliding level of difficulty. Validated transactions are charged a transaction reward, paid to the miner who solves the problem fastest. A permissioned blockchain has the capability to establish trust among distributed but known members. The pre-existing trust frees up computing resources for more complex, multi-party smart contracts.

In today’s world, the legal enforcement of contracts is cumbersome, error-prone, and expensive. The critical capability that blockchain provides to smart contracts is the automatic enforcement of pre-agreed contract terms by computers that represent the parties in an immutable transaction.

Cost savings occur at every stage. The code that runs on the blockchain replaces the traditional judicial enforcement mechanism, interpreting contractual terms, contracting and negotiation resources required for each organization, and enforcement of the contractual terms. In this context, the distributed nature of blockchain becomes even more attractive because it decentralizes and democratizes trust.

Bitcoin protocol provided a straightforward scripting language to incorporate limited program logic in transactions. Ethereum expanded that idea by creating the Ethereum Virtual Machine (EVM) that runs a Turing complete stack-based language, opening the door to apply smart contracts running on blockchain to unlimited applications. Ethereum smart contracts are written using programming languages like Solidity and Serpent while Hyperledger Fabric uses languages like Golang and Javascript.

Smart Contracts in Blockchain

Smart contracts are fundamental to blockchain platforms. With smart contracts, users can apply secure rules in the processing of transactions. They can use them to perform automatic validation steps and encode conditions that in the past were on a signed physical contract.

Participants in a blockchain platform agree on the format of transaction data in the smart contracts, and on the rules that govern these transactions. This agreement involves an accurate expression of the rules, exploring all exceptions, and defining a framework for resolving disputes. It is an iterative process involving developers and business stakeholders.

The process also covers reviewing the rules, registering agreement between the parties, testing the rules on transaction data, simulating scenarios to understand their business impact, and storing them in a secure and transparent manner. Data models and business domain models, represented by the smart contracts, require the same attention. Governanace of the rules must be agreed upon by all parties: who can establish rules, can deploy rules, and the processes for changing the rules of the network.

Three considerations for smart contracts and blockchain:

1. Using a Turing-complete programing language prevents exhaustive validation of smart contracts. Blockchain often implements use-cases of trading value. Smart contracts act as trading agents whose action has a profound impact, manipulating value on the platform, assets or crypto money. The logic embedded in them should be protected and their effect predictable. However, by definition, the formal validation of a program written with a Turing-complete programming language is a non-decidable problem. Although a Turing-complete language is convenient, using a less expressive language and runtime, like a rule engine able to execute production rules, might be a better option to take advantage of more opportunities to check the semantics of the contract and apply formal verification techniques. Trading expressivity against safety is something to consider when the code controls the value of assets exchanged over a business network.
2. Smart contracts are business logic that should be in the hands of business people, not developers. Smart contracts encode the conditions of agreements created by the business partners who trade on the platform. The conditions are the business rules regulating the transactions. For example, deciding whether all funds, or a fraction, will be transferred to the seller when the buyer receives the goods. These business rules are likely defined in business contracts agreed upon by all parties. The contractual logic is likely to be real logic, which is of some interest to the business stakeholders of the participants in the blockchain network. Lawyers, business executives, or even end-users are the likely consumer and instigators of this logic. A high-level language, business-friendly enough to involve business stakeholders, would be much better than logic buried in code which is understood and maintained by developers. The need here is very much the same as in business platforms implemented for decades before blockchain. Decision management software enables externalization of the decision logic and expresses it in high-level languages that business stakeholders can understand.
3. Management of the smart contract life-cycle is essential and should be under the control of carefully defined governance processes. Any change to business logic, which can have a profound impact on the company operation, is usually extensively controlled by strict governance processes. Once again Decision Management has been positioned to solve this problem and provide an extensive feature set to define review processes and manage the overall life-cycle with the expected level of auditability. For instance, business partners will likely want to review the rules, negotiate them, maybe even vote on them. Ultimately, they want to overtly control the whole change process. In situations where governance of the business logic is critical, a new version of the contract must be strictly validated before deploying and activating it. Any impact to the business must be assessed. For example, running a simulation over a broad set of historical data. Because smart contracts are objects shared by business partners involved in trading, a collaboration between the partners to define, review, negotiate, and validate the contract clauses is mandatory.

To sum it up, Smart Contracts are a clever and powerful mechanism to automate the logic. There are still many questions about its legal foundation, life-cycle, and the governance.

Integration with an External Business Logic Layer

A simple approach in blockchain networks is to encode the business rules of network operation as smart contracts. However, the encoded business rules are not accessible to the parties. For example, new participants entering the business network require a lengthy review cycle and coordination between legal, business and development teams to ensure the terms encoded on the blockchain are well understand and agreed upon by all stakeholders.

Second, the smart contracts must be updated when the rules of the network change, which may require another cycle of review by all participants, testing, and deployment on the blockchain network. There may be several reviews with legal teams to ensure the smart contract code complies with terms agreed with the business stakeholders who may not be familiar with the implementation language used in smart contract code. Consider a scenario where a business network in the automotive industry uses blockchain to manage the lifecycle of a vehicle. The smart contract code must be updated to accommodate each change when regulations are updated around allowable pollutant limits from the exhaust, or there is a recall on vehicle parts, expiration of licenses or other litigation. The business network would grind to a halt as each change requires a lengthy, multi-party review of the terms encoded on the blockchain.

Therefore, smart contracts cannot purely be code, in the sense that developers think about code. Smart contracts must be expressed at a higher level of abstraction, using business terms of the domain. They should be precise and formal, without ambiguity, but still understandable by people. That’s what business rules are. Business rules define an aspect of business and should assert business structure and control the behavior of the business. Therefore, one of the business logic layers could be a Decision Management Platform such as IBM’s Operational Decision Manager (ODM) which provides a robust rules engine and interface for business owners to devise, change and maintain rules of operating the network.

Enterprises need to manage change at the ecosystem level. Because the network participants define the rules of the network, managing changes must be a team activity. Many collaborative processes surround a smart contract lifecycle, according to the governance defined by the business network. What is the review process? Do we vote for activating a new version of the contracts? What is the emergency process to turn off a flawed smart contract? Principles that the business rules technologies defined many years ago are even more crucial as blockchain brings the need to manage business intent at the ecosystem level.

Well defined smart contracts require a Decision Management Platform representing operational decisions, automated and governed as business assets, and handled by business stakeholders. Integrating blockchain with a decision management platform is a good idea because:

• When working with something new like blockchain, it’s a good idea to use proven and reliable technologies like ODM’s rule engine where possible.
• It puts the rules for value exchanges directly into the hands of the specialists who define them  the accountants, the auditors, the lawyers, the analysts, and so on rather than burying it in the codebase of the blockchain application.
• The specialists can use Decision Center as a platform for collaboratively governing their rules. Often, agreeing on the rules is half the battle!
• Extracting the business rules and executing them in ODM’s enterprise-class rule engine provides better responsiveness to changes: Update the rule, test it, and deploy the updated decision service — all without touching the code of the Smart Contract. From the code’s point of view, it’s still calling the same decision; but now it is processing transactions according to the updated rules.

Extending Smart Contracts in blockchain with a Trusted Oracle

With transient information (e.g., an interest rate), how can we propogate the updated data to a smart contract? One possibility could be to delegate this responsibility to the client application: The client application retrieves the current interest rate and includes it in its payload to the smart contract. Why would the network trust the client application to provide information reliably and accurately? Instead of delegating this responsibility to the client application, a better option is to:

1. Delegate the processing to get volatile information to a third-party known as the Oracle.
2. Deterministically agree on the value to use for a transient piece of information.

For an Oracle to work in a blockchain network, it must meet the following conditions:

1. Multiple endorsers must be able to get the same answer from the Oracle to preserve the deterministic aspect of a smart contract.
2. Reliable connectivity must exist between the execution of a smart contract and the response from the Oracle.
3. The responses received from the Oracle must preserve data confidentiality.

The following diagram shows the architecture and sequence of events for leveraging an Oracle component from a multi-participant blockchain network:

Leveraging an Oracle in a blockchain network

1. Client application submits the transaction to each organization that needs to endorse the transaction (as specified in the endorsement policy). Note that the client application is unaware the smart contract will delegate a portion of the execution to an external system.
2. Each endorsing peer in each organization will, in parallel, issue a request to the Oracle with sufficient information so the Oracle can correlate the various requests from the different endorsing peers.
3. The Oracle will use the certificates used to sign the transactions to correlate common requests and ensure consistency in the response. The Oracle may sign the response to avoid any potential tampering.
4. The endorser peers should be able to validate the signature of the Oracle. The ledger should preserve the signature and response data to provide auditability.

Emerging Application Architecture

Enterprise applications that now incorporate blockchain require an architecture suited to these modern applications. As I argued earlier, it is important to externalize the business logic in smart contracts from the actual smart contract code, which should handle data and event interchange with external systems.

Evolution of Blockchain Application Architectures

Just as the application architectures evolved from business logic and data handling embedded in the data layer to externalizing of the business logic in a middleware layer, a similar evolution is happening for blockchain applications. Early blockchain applications inserted the business logic and data handling for manipulation of ledger data in the smart contracts. This is now evolving to the externalization of business logic in a separate layer. This separation ensures business owners can change the rules for asset interchange by using the language used in the business domain without worrying about technical implementation details and also enables scaling of the blockchain applications and providing independence on the underlying blockchain implementation.

The Vehicle Lifecycle example

To illustrate how an external decision management system such as IBM’s Operational Decision Manager (ODM) can bring value to a blockchain network, consider the lifecycle of a vehicle. The following illustration shows the vehicle’s lifecycle from manufacturing to recycling, through registration with the regulatory authority, and transfer of ownership when selling the vehicle, to eventual disposal.

Vehicle lifecycle blockchain network

All parties in the business network have a trusted, distributed, source of truth about the history and ownership of a vehicle.

Describing the vehicle with the characteristics, such as its technical and commercial characteristics, owner identification, and insurance status is important.

Transactions related to a vehicle include the initial purchase order, manufacturing order, request for registration, and ownership transfer. Different rules govern these transactions at different stages of the vehicle lifecycle. Business rules likely apply to the sales process when purchasing the car from the car dealer. Change of ownership needs to comply with trade laws related to the vehicle, specific to each country. Participants want to detect fraudulent transactions on non-compliant vehicles or other tax evasion patterns.

Some of the transaction processing, embedded in smart contracts, is technical. Examples of processing include transforming data structures and creating, updating, and destroying assets. Other parts of the smart contract logic are much closer to the legal rules that govern the underlying contract between the parties or by the government regulator.

Topology of the Vehicle Blockchain Network

The figure below shows the typical architecture of a blockchain business network. Hyperledger Fabric is displayed here, but it could be any other blockchain. In this example, each peer node has its instance of the IBM ODM Rule Execution Server, which runs rules for all blockchain applications deployed on it.

Network topology for a vehicle blockchain network

A blockchain network runs on a set of nodes. Each node has a copy of the transaction ledger and assets, stored in a database, called world state in Hyperledeger Fabric terminology.

Inside a node, several processes implement the blockchain protocols and functions. A peer node in this topology is the set of operations required to handle the transactions on a blockchain node.

Isolated security schemes must protect business network nodes, so an instance of IBM ODM Rule Execution Server must be deployed for each peer node. Multiple peer nodes make both the application and the rule execution capability highly available.

The lifecycle of an ownership transfer transaction

To illustrate how the blockchain application and IBM ODM work together, consider the case of a sell/buy transaction between two people.

To perform this business transaction, a system needs to publish a VehicleTransferTransaction call to the blockchain with all the information about the Vehicle, the seller, and the buyer.

Assume that the rules governing the transaction will check if it is fraudulent. The logic for these rules is complex and defined by experts. When someone discovers a new fraud pattern, the experts (business stakeholders) want to quickly change the rules to identify fraudulent transactions as soon as they are submitted to the blockchain.

The transaction goes through the journey shown in the following illustration:

Smart contract transaction processing flow

• An external system, which could be a business process or an application, uses the REST API generated by Hyperledger Composer for this blockchain application to push a PrivateVehicleTransfer transaction.
• Hyperledger Fabric distributes the transaction to all nodes in the blockchain.
• Each peer node triggers the chaincode (smart contract) for this blockchain application to check the transaction and apply the logic implemented by the smart contract.
• Chaincode triggers the Hyperledger Composer transaction processor callback, defined in the blockchain application.
• Transaction processor (JavaScript code) makes an external REST call to the Rule Execution Server that holds the business rules in a decision service, passing the data necessary to take the decision.
• Business rules are applied to the transaction and executed by the rule engine.
• The rule engine sends the response back to the Hyperledger Composer callback.
• The callback performs actions according to the response, either rejecting the transaction or validating it, with extra information when it sees a suspicious transaction.

Smart Contract Challenges and Limitations

While there is little doubt about the ability of smart contracts to digitize trust through certainty of execution and creation of efficiency, it is important to realize there are limitations of smart contracts that do not always make for a seamless transition from the real-world into computer logic.

1. The distributed consensus capabilities of blockchains is a ‘trustless’ environment – i.e., the blockchain network creates and confirms the network truth without a trusted third party. Confusion arises when describing blockchain as a network where everything is trusted, including the smart contracts written on top of it. The consensus mechanisms enable the nodes to collectively agree on a shared truth, but that does not extend to the logic encoded in the smart contracts.
2. Another interpretation challenge with blockchain is that validation of transactions (to achieve consensus) is validation of smart contracts, or that such validation is legally indispensable. Blockchain provides evidence that a transaction has occurred after fulfilling the technical conditions encoded in a smart contract but it cannot establish the validity of the transaction in the legal sense. A transaction may be recorded in the blockchain but the contract underlying such transfer may be legally invalid because, for example, one party lacked legal capacity, acted under duress or an illegality tainted the agreement. The transaction might have been an upfront payment but the counter performance may have failed or proved inadequate. “Putting a smart contract onto the blockchain” provides a record of its existence but a record need not always reflect reality - even if the record itself is trustworthy. The fact that the blockchain “validates” a transaction in a technical sense says nothing about the validity of transaction in the legal sense or about the validity of the smart contract the transaction forms part of.
3. The self-enforcement capability of automatic execution of smart contracts is sometimes interpreted as the elimination of human discretion on the side of the contracting parties or with the elimination of the need to seek judicial help. Self-enforcement of smart contracts in blockchain shields the smart contract from the vagaries of human discretion and protects the parties from breach, however, in a legal context, enforcement is associated with the state-sanctioned protection of the parties’ economic interest in the performance of the contract. Courts enforce contracts by awarding damages for loss resulting from non- or defective performance, seeking to place the aggrieved party in the same position she would have been in had the contract been performed. Smart contracts equate enforceability with guaranteed performance, collapsing these two concepts.
4. The tamper-proof enforcement concept of smart contract can also be fraught with risks. “Tamper-proof” enforcement means that there is no stopping or changing a smart contract. If self-enforcement is to guarantee performance and if neither subsequent human intervention, nor a modification of the smart contract are possible, then its code must be perfect. Tamper-proof self-enforcing smart contracts may “shield” the transaction from the vagaries of human discretion but they introduce the risk of performance being affected by coding errors. An interesting result follows: as neither party can interfere with the operation of the smart contract, breach is technically impossible – at least if breach is associated with an event related to or within the control of the parties. Multiple risk allocation scenarios are possible, depending they can attribute the coding error to one of the contracting parties or to a third party. If the parties used a smart contract created by a third party, there may also be a discrepancy between what the smart contract should do and what it actually does. The point is not that the parties may have trouble determining the actual functionality of the smart contract (as they can hire a specialist to do so) but it may be difficult to establish what takes precedence in the event the code of the smart contract does not match the agreement it embodies. They often make such decisions long after they have formed the contract as there may be a significant time-lag between the creation and implemention the contract.
5. The precision and digitization of trust encoded in smart contracts can create hidden costs. Unless there is well-defined and ongoing governance in permissioned networks, the only modifications made to smart contracts are previously encoded dormant options which may be alternatives. For example, consider a scenario where a supplier ends up sending lower-quality products to a buyer but will extend payment terms to non-standard 60 days to preserve the business relationship. If the original smart contract did not include this payment flexibility, it would not be feasible for the parties to arrive at such a settlement. The parties would be required to write a brand new smart contract, testing, integration, and roll out on the blockchain network for such a real-world scenario. Thus, it is not always possible to translate real-world reasonableness into digitized terms.
6. Some technical writings claim blockchains create a parallel transactional universe, or even their own jurisdiction, where the parties can transact outside of the legal system. There was a brief period of turmoil that followed the rise of the internet, and similar claims of the radical disintermediation as a natural consequence of its distributed nature. Contracts formed “in cyberspace” are now treated like all other contracts and are subject to the same legal principles. Technical writings implying smart contracts and blockchains obviate the need for judicial protection overlook the simple fact that the lack of recourse to established legal institutions would incentivize not only fraudsters and hackers but also discourage the use of blockchains and smart contracts in financial transactions.
7. The difficulties of translating existing paper-based contracts into smart contracts is a non-trivial task. The viability of smart contracts hinges on the ability to express contractual obligations in code. There are multiple options: the smart contract can be a translation of an existing agreement, created in code from the outset or, drafted in natural language with subsequent encoding in mind. While only some contracts can or should be smart, most technical writings continue to extoll the ability of smart contracts to transform many types of contracts, including employment contracts, leases and mortgages. Parties can create their own smart contract or agree to use an existing smart contract created by somebody else. While there are no obstacles in creating one-off, customized smart contracts, economies of scale dictate that smart contracts take the form of generic programs and used on a mass-scale. One or more parties are unable to verify whether the code accurately reflects their agreement, or to determine how the smart contract will operate in practice. Given that the coders who create the smart contract cannot (or should not) decide on its commercial and legal aspects, there must be a document describing the substance of the agreement. Many smart contracts will originate as documents written in natural language that require subsequent translation into code. Lawyers and coders co-operating in the translation of legal documents into executable code can solve the problems of interpreting or supplementing contractual language. Despite such co-operation, neither the parties nor their lawyers can determine whether the code of the smart contract correctly reflects the original legal document. Such discrepancies are unsettling given that the smart contract cannot be stopped or amended once it starts self-enforcement. To avoid the difficulties of translating legal language into code, smart contracts should be written in code from the outset. Contracts should be drafted with encoding in mind because most lawyers are unlikely to become programmers (just as most programmers are unlikely to become skilled lawyers).

Smart Contracts and Legal Issues

Given the vast sums of money raised through Initial Coin Offerings, the question of the legal status of the tokens issued in ICOs has drawn outsized attention. All securities offered and sold in the United States must be registered with the SEC or qualify for an exemption from the registration requirements under applicable law. Most ICO issuers have positioned their offering as “utility tokens”—providing purchasers with future access to the issuer’s product or service. As a result, they have been offered without the benefit of registration or qualification for an exemption from registration. The SEC began studying blockchain in 2013 when it formed the Digital Currency Working Group (since renamed the Distributed Ledger Technology Working Group). It was not until the summer of 2017, however, that the SEC began to assert its authority to regulate ICOs directly. In a July 2017 report, the SEC declared that the DAO tokens issued by Slock.it were securities within the meaning of the Securities Act of 1933 and the Securities Exchange Act of 1934. This announcement was a “shot across the bow” by the SEC, establishing that ICOs could be within the regulatory scope of the SEC.

The SEC also clarified that in analyzing whether a token was a security, it would apply its traditional analysis based on a four-part test delineated by the Supreme Court in the 1946 SEC v. Howey3 decision. Whether a transaction is an “investment contract”, and therefore included within the statutory definition of a security, Howey held that a transaction was an “investment contract” if:

1. it is an investment of money,
2. in a common enterprise,
3. with an expectation of profits from the investment,
4. where those profits are derived solely from the efforts of the promoters or third parties.

The SEC concluded that the DAO token met all four criteria and, as a result, was a security. The SEC’s determination was not a surprise; the DAO tokens resembled equity shares in a company. However, because the DAO’s was a relatively clear-cut case, it did little to resolve the security-versus-utility debate in the legal community. Since then, several SEC actions have focused on fraudulent ICOs.

In September, the SEC charged Maksim Zaslavskiy and his companies (REcoin Group Foundation and DRC World) with fraud in ICOs that were purportedly backed by investments in real estate and diamonds. In December 2017, the SEC froze the assets of PlexCrops. The SEC maintained that the company had promised unlikely returns, advertised a non-existent team of experts, and did not disclose the financial crimes of its founder. The complaint also alleged that the company violated the Securities Act of 1933 by undertaking an unregistered offering. The filing was the first by the SEC’s Cyber Unit, which was formed in September 2017 to “focus the Enforcement Division’s cyber-related expertise on misconduct involving distributed ledger technology and initial coin offerings, the spread of false information through electronic and social media, hacking and threats to trading platforms.” While these cases sent a clear message to the market that the SEC would not tolerate fraud, again they did little to clarify the security-versus-utility divide.

In December 2017, the SEC stepped in to stop the ICO of Munchee, Inc. Funds raised by Munchee would be used to improve its existing app and recruit users to eventually buy advertisements, write reviews, sell food, and conduct other transactions using Munchee’s MUN token. The Munchee white paper described how the MUN tokens would increase in value and highlighted the ability of MUN token holders to trade the tokens on the secondary market. The document even claimed, “as currently designed, the sale of MUN utility tokens does not pose a significant risk of implicating federal securities laws.”

In the months since the DAO announcement, SEC Chairman Jay Clayton made several statements in his personal capacity in which he articulated his belief that most ICO tokens were securities. On the same day as the Munchee announcement, Clayton released a “Statement on Cryptocurrencies and Initial Coin Offerings.” His statement was directed at two audiences— “Main Street” investors and market professionals (broker-dealers, investment advisers, exchanges, lawyers, and accountants). For Main Street investors, Clayton’s statement contained a strongly worded warning to be wary of fraud and manipulation. He wrote: “As with any other type of potential investment, if a promoter guarantees returns, if an opportunity sounds too good to be true, or if you are pressured to act quickly, please exercise extreme caution and be aware of the risk that your investment may be lost.” He highlighted a string of warnings that the SEC had issued to Main Street investors.

In his comments on market professionals, Clayton was even blunter:

1.5em1.5em “A change in the structure of a securities offering does not change the fundamental point that when a security is being offered, our securities laws must be followed. Said another way, replacing a traditional corporate interest recorded in a central ledger with an enterprise interest recorded through a Blockchain entry on a distributed ledger may change the form of the transaction, but it does not change the substance.”

Speaking before the Securities Regulation Institute on January 22, 2018, Clayton continued his critique of market professionals but focused almost exclusively on lawyers. Clayton zeroed in on the role of attorneys in this market and highlighted two areas where he felt they were falling short.

• There are ICOs where lawyers appear to be assisting issuers on structuring offerings “that have many of the key features of a securities offering but call it an ‘ICO,’ which sounds pretty close to an ‘IPO.'” At the same time, these lawyers claim the offerings are not securities, and the tokens are issued without securities law compliance.
• In other ICOs, “lawyers appear to provide the ‘it depends’ equivocal advice, rather than counseling their clients that the product they are promoting likely is a security. Their clients then proceed with the ICO without complying with the securities laws because those clients are willing to take the risk.”

He also criticized public companies trying to take advantage of the blockchain hype by announcing blockchain projects or “[changing] its name to something like ‘Blockchain-R-Us.’ ” Leaving little doubt that stepped-up enforcement was coming, Clayton added, “With respect to these two scenarios, I have instructed the SEC staff to be on high alert for approaches to ICOs that may be contrary to the spirit of our securities laws and the professional obligations of the U.S. securities bar.”

Enforcement is not only at the federal level, but at the state level as well. On May 21, “Operation Cryptosweep” was announced. As part of this effort, regulators from across 40 jurisdictions in the US and Canada coordinated by the North American Securities Administrators Association (NASAA) initiated up to 70 investigations targeting ICOs.

Global Focus

Blockchain is on the radar of regulators all over the globe. In the wake of the DAO announcement, regulators in Canada, the United Kingdom, Hong Kong, Thailand, Switzerland, Australia, Gibraltar, and Singapore have issued similar announcements. Although the details varied by jurisdiction, in each case regulators clarified that ICOs were subject to the security regulations of their country, but also stressed that not all ICO tokens were necessarily securities. In the most extreme cases, South Korea and China banned ICOs—although with China there is a firm belief that the ban will be rolled back.

Class Action Lawsuits

Regulatory action is not the only risk faced by participants in the blockchain ecosystem. Attorneys have begun filing private actions on behalf of investors. In February 2016, a class action lawsuit was filed against the Project Investors, Inc. cryptocurrency exchange Cryptsy alleging that the defendant had stolen investors’ money and fled to China. In August 2017, the court ruled that the defendant had to return 11,000 Bitcoins to investors, worth $30 million at the time. The Cryptsy case underscored one of the challenges in enforcing legal decisions in this space. The judgment listed the alphanumeric public keys of twelve cryptocurrency wallets where the stolen Bitcoins were stored. However, the corresponding private keys are needed to transfer the Bitcoins to plaintiffs. Due to the decentralized nature of blockchain, there is no central authority for the court to order to produce these keys. Autumn 2017 saw the first of what is likely to be many class action lawsuits related to ICOs. In early November, the first of at least four class action lawsuits were filed in connection with the $232 million Tezos ICO. The defendants in the cases are co-founders Arthur and Kathleen Breitman, Dynamic Ledger Solutions, which owns the rights to the underlying code, and the Tezos Foundation, a Swiss entity that was set up to carry out the raise. In the original Tezos complaint,24 only one of the claims is for the sale of unregistered securities. The remaining claims include two accusations of fraud and claims of false advertising and unfair competition under California state law. In December 2017, there were at least three additional ICO-related class action lawsuits filed. All alleged that the defendants had engaged in the issuance of unregistered securities.

Other legal issues

The rules of evidence at the state and federal levels govern the admissibility of blockchain records . Today in most jurisdictions, admitting blockchain evidence would require expert testimony. However, some states have passed legislation recognizing the admissibility or validity of blockchain-based records in specific contexts.

• Vermont passed legislation creating a presumption of admissibility for blockchain evidence subject to certain conditions and allowing for the creation of blockchain based limited liability companies;
• Delaware passed legislation allowing Delaware corporations to issue and trade shares on a blockchain platform;
• Arizona and Nevada passed legislation recognizing blockchain signatures and smart contracts. The Nevada legislation also blocks local government entities from taxing and licensing blockchain use.
• Wyoming passed extensive legislation providing among other things an exemption for “utility/consumer” tokens from securities and money transmission laws and allowing maintenance of corporate records of Wyoming entities via blockchain so long as electronic keys, network signatures, and digital receipts are used.

Jurisdiction

As lawsuits emerge in the blockchain space, many jurisdictional issues need to be addressed—questions such as:

• Which courts will have subject matter and personal jurisdiction over disputes?
• Which national laws will apply?
• Where are smart contracts deemed to be transacted?
• Who has jurisdiction over DAOs (decentralized autonomous organizations— organizations that are run through rules encoded in smart contracts)?

Are Smart Contracts Legally Binding?

Parties will inevitably dispute, and the courts must decide, whether these smart contracts are legally enforceable parts of the agreed-upon terms in the corresponding paper contracts. Although this is not necessarily the same situation as with blockchain contracts, it raises a similar issue: can contractual terms stored in an online source be incorporated by reference into the parties’ contract? Courts found support for this in the Restatement (Second) of Contracts, which states that a contract “may consist of several writings if one of the writings is signed and the writings in the circumstances indicate that they relate to the same transaction.” Eventually, courts will hold smart contracts to be legally binding and enforceable, and network participants (or Blockchain Architects & Operators) must place clear language in their paper contract that evinces their intent to incorporate the smart contract and to be bound by the terms of their terms and conditions governing sales.

There are many uncertainties surrounding the legal status of blockchain smart contracts. Incorporation by reference seems to offer a path to enforceability, but the ever-changing character of blockchain ledgers raises additional issues for the incorporation by reference approach. These questions will need to be answered by the courts when litigation arises from smart contracts unless resolved by legislation, most likely at the state level.

Will Smart Contracts be admissible as evidence?

The next issue with smart contracts is whether they will be admissible evidence if the courts determine that they are not part of parties’ enforceable contracts. It seems likely that courts would admit smart contracts into evidence as business records, but what evidentiary weight will courts give smart contracts? Arguably, smart contracts are evidence of the contracting parties’ course of performance or course of dealing. However, while the Uniform Commercial Code states that the express terms of a contract must be read consistently with the parties’ course of performance or dealing where viable, the express terms of the parties’ contract prevail where they conflict with the course of performance or dealing. If the courts do not find that smart contracts are part of an enforceable contract, they may likely attribute the same evidentiary weight to smart contracts as they do to other evidence of the parties’ course of performance or course of dealing. Again, this is an area were state-level legislation may remove some of the uncertainty.