Thank you to OpenLaw for reviewing this article and giving great insights into the intersection of smart contracts and the current legal system.

Smart contracts can revolutionize the way companies and individuals interact with one another by offering ways to digitize paper contracts and automate business logic using reliable and tamperproof decentralized infrastructure.

However, while smart contracts offer immense business benefits, are they legally binding in a court of law? To answer this question, we explore the construction of current legal agreements and how they may evolve into smart contracts. Outlining the technicals of this transformation will serve as the foundation for addressing their legal status and other nuanced discussions about the future of smart contract development.

According to Cornell Law School, a contract is “an agreement between private parties creating mutual obligations enforceable by law. The basic elements of a legally enforceable contract (in most jurisdictions) are: mutual assent (agreement without duress/force); expressed by a valid offer and acceptance (signatures of all parties); adequate consideration (exchanges of value); capacity (of age & sane of mind); and legality (legal activity).”

Legal contracts are predominantly written documents based on various standard industry templates with customization as needed. Companies typically don’t draft up new contracts for each standard transaction. Instead, they use trusted industry templates and add in their modifications or create a set of customized agreements that becomes the basis for a particular type of business relationship.

Most written legal documents today are either stored as paper contracts in file cabinets or as digital PDFs on computer hard drives. Written contracts require a physically written signature by all parties to be legally enforceable. Digital contracts (also referred to as electronic contracts) have the same characteristics as written contracts except the signature is done electronically through an e-signature.

As Chainlink Co-Founder Sergey Nazarov repeatedly points out, contracts today are probabilistic in that each party will probably hold up their end of the agreement and pay on time. However, in the real-world many parties simply don’t hold up their end of the bargain either intentionally or unintentionally. Counterparties defaulting on obligations leads to a litany of inconveniences such as late cash flows, unforeseen expenses, inaccurate budgets, increased litigation, and various other problems.

(Some of the problems and resulting consequences of current legal agreements. Source: Konfidio)

The reason contracts are probabilistic is because the contract process requires back and forth actions between parties to execute and settle the contract. Each party has to wait and trust that the other party will take action on-time and then they must reconcile to verify the counterparties’ actions. This involves a game of email/phone tag that often leads to posturing and gamesmanship to test the other parties’ limits and/or pressure them to act. Large companies have certain advantages that allow them to delay payments by bullying smaller vendors. This counterparty risk extends to international agreements in which companies delay or refuse action, and resolution is even more challenging due to costs and complications of international litigation.

Transitioning Towards Smart Contracts

A smart contract is a deterministic, reliable, and tamper-proof digital agreement run on decentralized infrastructure. Once two or more parties agree to the terms of a contract, they transform the contract (or parts of it) into code and send it to shared infrastructure that stores, maintains, executes and settles the contract automatically for both parties. Having the contract operate on shared infrastructure via a distributed ledger (primarily a blockchain, but also a Directed Acyclic Graph (DAG) --- a non-blockchain distributed ledger that offers enhanced scalability due to its unique consensus algorithm) offers new benefits to all parties.

Using a distributed ledger as a backend system to run and store the contract, the contract becomes deterministic (outcomes are determined directly by data). Instead of waiting for the other party to take action, verifying their actions, and manually entering data, these actions are all automated by the smart contract. The smart contract auto-executes (maintenance, data entry, execution, settlement) based on the interaction between the contract’s code (terms) and external data-feeds it receives about contractual events. Neither party holds control over the shared infrastructure or data, and therefore neither party can escape their contractual obligations nor tamper with the outcome.

(Some basic differences in current legal contracts vs. smart contracts; Source: Everis)

As OpenLaw stated in a recent blog post, “OpenLaw (via smart contracts) transforms legal agreements into structured computable files — data objects that can be read from, written to, or interacted with. As a result, legal agreements no longer need to be trapped in dusty filing cabinets or hard to parse Microsoft Word Files or PDFs. They can operate like software.”

Essentially, smart contracts act like programmable software run on shared, data-driven, yet decentralized infrastructure. Building off this understanding, let's examine a simplified contract representing global trade in the current versus smart contract format.

Contract Terms

The contract is between Novartis --- a European Pharmaceutical company, and Walgreens --- a U.S. retailer, that outlines payment from Walgreens to Novartis for pharmaceutical products based on a series of conditions: 1) The goods arrive on time 2) with the correct quantity, and 3) in good condition. The movement of goods from Novartis to Walgreens involves several intermediaries: third-party inspectors, customs, transportation companies, and financing companies.

Current Form
They agree to a contract (invoice) and fax it back and forth to obtain physical signatures. Both companies and their banking partners review and store a copy of the invoice in their filing cabinets/databases. This lack of a common medium results in a plethora of checkpoints when goods pass between intermediaries. Each step in the transportation route involves exchanging physical documents between different operational platforms and usually some form of manual data entry/verification. It ultimately leads to time delays, frequent miscommunications, reconciliation overhead, and increased disputes.

Smart Contract
They agree to a smart contract (coded invoice) and sign it with their e-signatures. They send the invoice to the blockchain, which carries the contract throughout the rest of its life cycle. Each intermediary sends their relevant information directly to the smart contract (sign with private keys) via e-signatures (authorization), Web APIs (GPS tracking, Customs), and IoT devices (temperature sensors and RFID chips for quality control and quantity checks). Neither party needs to act once the contract is set in motion since payment is automatically released once the data confirms all conditions are met.

According to a joint document produced by the International Swaps and Derivatives Association (ISDA) and Linklaters - a multinational law firm located in London, “A legal agreement can be analyzed as containing operational and non-operational clauses.”

Operational Clauses in Smart Contracts

Operational clauses outline the actual actions of the contract, such as if there’s a car accident, then file a claim; if the claim is valid, then issue an insurance payout according to their coverage. Smart contracts can perfectly replace operational clauses because smart contracts use code that represents boolean logic (if x happens, then execute y).

Echoing the thoughts of OpenLaw, there are three core components to making this a reality:

  1. A smart contract enabled blockchain (or DAG) stores the contract terms (code) and executes the contract based on conditions being met. It also provides a way to sign contracts using private keys and an audit trail for both parties and regulators. Blockchain platforms with smart contract capabilities include Ethereum, Hedera, Polkadot, and Tezos.
  2. Legal software contains libraries and tools for creating and deploying various legal templates. These templates provide standardized ways to digitally represent (codify) important parts of a legal contract such as the parties, terms, and consideration. As stated in a recent blog post by OpenLaw entitled The Smart Contract Stack, it’s a way of creating what Ian Gregg referred to as Ricardian Contracts — a digital agreement “that defines the terms and conditions of an interaction between two or more peers, that is cryptographically signed and verified. Importantly it is both human and machine-readable and digitally signed.” This software is currently being provided by startups such as OpenLaw and Clause (which created a foundation called the Accord Project for developing legal templates).
  3. Oracles connect the (on-chain) smart contract to any and all systems outside its native blockchain (off-chain). This includes connection to off-chain data feeds (web APIs, IoT, Clouds) to trigger contract execution, in-demand payment systems for off-chain settlement (banks, fintech, other blockchains), and third party entities that require transactional metadata (regulators, auditors, analytics). Oracles can also enhance data quality by verifying and authenticating data that both triggers and settles contracts. Chainlink is the leading standard data layer for bridging the on-chain and off-chain worlds.
Chainlink oracles connect smart contracts on any blockchain to any input and output

Non-operational clauses in Smart Contracts

Non-operational clauses represent context about the wider legal relationship between the parties, such as ontologies and formal semantics.

According to Cambridge University Press, “Formal semantics is an approach to semantics, the study of meaning, with roots in logic, the philosophy of language, and linguistics.”

As described by Margaret Hagan, Director of Legal Design Lab at Stanford Law, an ontology “is an explicit, structured description of all the people, things, concepts, and relationships in a domain. It provides a common vocabulary to all the people working in a domain — like in medicine, in law, or otherwise. It gives them a shared understanding of how to represent their domain to machines.”

(An example ontology for categorizing legal data; Source: Margaret Hagan)

Combining the two together, formal semantics provide logical meaning to words and concepts in the contract, while ontologies help categorize interrelationships between legal concepts by providing structure and a domain of knowledge for reference. For example, formal semantics might give specific interpretations to statements like “in good faith”, while ontologies identify the jurisdiction, laws, databases, and court cases that give meaning to such statements.

Non-operational clauses are more difficult to reduce down to pure coded logic. Problems arise with the formal representation of subjective matter that can’t be easily coded like “in good faith” because it entails subjective interpretation or references to structured knowledge. While smart contracts could have the positive effect of forcing parties to iron out subjective details (which should improve over time using machine learning software that references ontology databases), it may be too costly in some instances to be worth implementing. These subjective clauses are where courts can come into play upon disagreements. It’s important to understand that smart contracts will not eliminate litigation, but should vastly reduce it along with other overhead expenses via deterministic automation and verification of each parties’ contractual performance.

According to a research report by the Cardozo School of Law titled Smart Contracts & Legal Enforceability, “Given the novelty of the technology, the question of the enforceability of smart contract code has not yet been examined by U.S. courts. Fortunately, the question of smart contract enforceability can be largely answered under existing state law implementations of the statute of frauds, the Uniform Commercial Code (“U.C.C.”), the Electronic Signatures in Global and National Commerce Act (“E-Sign Act”), and state laws modeled on the Uniform Electronic Transactions Act (“UETA”).” Although there is much work to be done and nothing is certain, there is a popular belief among many legal experts that already existing laws regarding e-signatures and electronic contracts/transactions can be applied to smart contracts in order to give them legal enforceability.

To determine legal enforceability, it’s important to examine how the smart contract was represented in the legal document. Further articulated in the ISDA/Linklaters joint document, representing legal smart contracts boils down to two broad methods: external and internal representation.

External Representation of Smart Contracts

In external representation the contract is physical and represented by natural language, but some of the business logic representing the operational clauses is processed through a smart contract. The actual code is mutually exclusive to the contract and therefore isn’t legally binding. In this model, if the code were to trigger a transaction to the wrong party then there would be a clear legal precedent to sue the counterparty and win. This model provides more comfort in the early days of smart contracts because it gives more wiggle room to legally rectify mistakes.

External representation in smart contracts often revolves around a “permission of claim” such as data-driven invoice receipts for event occurrences, as opposed to triggering payment settlements. For example, bond payments are recorded as payment claims based on current interest rates, instead of directly making payments from the bond issuer to the bondholder. The claims can even be produced on the blockchain to provide a cryptographically verified receipt of its occurrence (date, payout amount, parties involved, event data), which could be used as proof in a court of law. While internal representation may be best suited for ownership claims like property titles, one has to wonder if receipt claims are much different than current digital contracts given that you still need to wait for your counterparty to take settlement action and make the payment.

(A simple comparison of Internal vs. External Representation; Source: Valentijn v/den Hout via HackerNoon)

Internal Representation of Smart Contracts

In internal representation the contract is still in natural language, but certain parts of the contract reference identifiable pieces of code that are legally binding. In this interpretation, the outcome of the smart contract would be legally binding and give direct “permission of use” even if it were incorrect because the code underpinning the operational clause is binding. In this model, it’s of the utmost importance for each party to have someone technically savvy audit the contract code and the platform it runs on beforehand since code is law and ownership is transferred. However, legal precedents could emerge that overturn smart contract outcomes in cases where there’s a high burden of proof that mistakes occurred.

Internal representation for smart contracts is more closely associated with the end-to-end execution of a contract or “self-executing,” where payments are directly issued based on events data. Chainlink has already demonstrated its ability to create a smart bond in a proof of concept with SWIFT. The PoC automated bond payments based on the average interest rate of five top banks, which then triggered a payment message on the SWIFT network. In this example, there is no manual action required from execution to settlement.

Areas of Further Development

Despite the pioneering work of many industry leaders, legal smart contracts are still in their early days of development. There are still several key areas that need to be addressed for mass adoption to occur.


Mass adoption in many industries is often contingent on establishing industry standards. There needs to be a common programming language for representing legal contracts that allow lawyers to easily understand, draft, and check legally binding smart contract code. To accomplish this, Ricardian Contracts are necessary to enable easy conversion of computer programming language to natural legal language. If not, then having tech people in every legal firm is absolutely essential. Unfortunately, there are also many different methods (markup languages) of representing smart contracts, which makes it difficult for lawyers from different projects and jurisdictions to easily understand the terms of the agreement. Standardizing these languages down to a few or enabling common conversion tools is likely the only way to manage contracts on a global scale.

Trusted Templates

Similar to the way templates are widely used today, smart contracts need trusted templates that can be used in simple drag-and-drop and then modify fashion. Startups like OpenLaw and Clause (via the Accord Project) are using their markup languages to design easy-to-use open-source templates that replicate common contractual agreements. Over time businesses and industry experts will refine these agreements until the market identifies those templates that are most secure, legally compliant, and meet the needs of the market. Once foundational smart contract templates are agreed upon for simple business processes, more complex designs for advanced business models can emerge.

Litigation Procedures

It’s important that formal procedures are established in the case that something goes wrong, such as disagreements on the outcome of a smart contract. There are already many government bodies and legal consortiums discussing fallback procedures and legal precedents around such incidents. This is an area that will likely develop based on future court cases where such problems emerge and decisions are made. Interpretations could differ across jurisdictions, but standard procedures should take root and provide clarity to the market.

As Giesela Rühl — a professor of Private International Law at Friedrich-Schiller-University in Jena (Germany), puts it “just like all other contracts, smart contracts demand that the law answers them. The decisive question, therefore, is not whether smart contracts are subject to the law, but rather to which law they are subject.”

Data Security

Given that data directly triggers actions and code is law, data quality is of the utmost importance. If contracts continue to move towards data-driven automation, they will require higher standards than currently present for data security and verification. Given the massive risk of corruption and downtime associated with having a single point (oracle) of failure, decentralized oracles may be required for legally binding auto-executing contracts. Chainlink provides a robust toolset for developing authenticated, verified, and tamper-proof data inputs and outputs for legal smart contract consumption.

Bringing Legally Binding Automation to Contract Lifecycles

Society is on the path towards wide-scale automation. In addition to the widely discussed automation of manual labor via robotics, smart contracts are rapidly expanding automation into economic exchanges of value via open-source decentralized protocols. Smart contracts will drastically reduce the cumbersome back-end processes of legal transactions.

The remaining hurdle to enterprise/consumer adoption are mutually agreed upon legally-binding standards for which great strides are already underway. Legal firms such as Linklaters are working directly with ISDA for smart contract legal standards in derivatives, while the Global Legal Blockchain Consortium and Chamber of Digital Commerce are working to gain consensus on legal standards with stakeholders.

Once these standards are finalized, smart contracts will bring drastic efficiencies to the speed and cost of conducting business that involves coordinating multi-party workflows. The decentralized verification of these agreements will usher in a paradigm shift to a trustless society — transacting with anyone around the world without fear of counterparty risk.

If you want to start building with Chainlink today, visit the developer documentation, join the technical discussion on Discord, and/or reach out to us about securely launching your data-enabled application or Chainlink Price Reference Data Contract on mainnet today.

If you want to get involved in the Chainlink community, visit our events page to join future meetups like this in your local area. If you want to become a Chainlink Ambassador and host a meetup, sign up today! For more information, check out the Chainlink website or follow us on Twitter or Reddit.