Many transactions conducted on the blockchain utilize smart contracts. Many of these agreements are based in code only, while others—called ancillary smart contracts—are paired with written text contracts.
There are, of course, many issues to take into account when it comes to negotiating, designing, coding, and enacting smart contracts. Legal issues in particular can be especially challenging to manage, with more complex agreements creating difficulties for the parties involved.
Is a Smart Contract Enforceable?
One of the major questions people have is with regard to the enforceability of smart contracts. In general, most simple contracts are enforceable. In fact, there’s a great deal of legal background that supports the concept of electronic documents being just as enforceable as written agreements.
In addition, many agreements need not actually be in writing in order to be enforceable. This means a purely code-based smart contract could be considered completely enforceable, just as a written document would be.
Ultimately, the matter of enforceability comes down to the terms of the contract. As long as there is an offer and acceptance, mutual assent, and consideration (i.e. both parties get something out of it), it should be enforceable as long as the terms themselves do not violate any relevant laws.
Challenges of Drafting Smart Contracts
While these contracts may typically be enforceable, there are far more complex matters to discuss, especially when it comes to the kinds of multi-faceted agreements that organizations rely on to structure their business relationships. Some of the challenges presented by smart contracts in this area include the following.
Arcane Programming Vs. Actual Intent
When different parties are negotiating a written contract, the main concern is making sure the intent of each party is clearly and accurately represented in the language of the document. This may require some legal expertise, but that’s about it.
A smart contract, however, is based on code, and it’s important to make sure that code correctly represents the intentions of the agreeing parties. That means trusting a third party to program the contract correctly, and that requires a certain amount of trust. The programmer is an additional point where the contract might go wrong, so tight, ongoing collaboration between the parties, their legal teams, and the programmer is essential.
Failure to Execute
Even if a smart contract accurately represents the desired terms of the agreement, there’s the matter of whether it’s actually possible for the contract to execute its terms. For example, if fees or penalties are to be assessed, the contract has to be able to pull those funds from the appropriate wallets in order to execute properly. Unfortunately, organizations typically move funds around, which means those funds may not be in the right place for the contract to extract them.
Another issue is if the contract has to use data that is off-chain. This may require the introduction of an “oracle” to feed the contract the needed data, but that’s another point of failure. If something goes wrong with the oracle, the contract might not execute as intended.
Cold Objectivity
With traditional contracts, there’s often some ambiguity built into the document’s language in order to allow some flexibility should the unforeseen occur. In addition, in the course of a business relationship, the parties involved may not necessarily fully execute the terms of the contract if either party fails to perform under the agreement. In many cases, it may be better to allow partial performance in order to maintain an otherwise profitable relationship.
Unfortunately, smart contracts don’t leave much room for ambiguity. Either the terms are met, or they are not. Any eventualities that are not intentionally built into the contract’s code will not be accounted for in its execution. Smart contracts are purely objective, and as such, they may be better suited for simpler agreements that can be framed in a few “if-then” statements.
Adjudication Challenges
Given that smart contracts are far more likely to reach multiple jurisdictions than traditional written contracts, they present the challenge of what body of law will be used to adjudicate them in the event of a dispute or failure to perform. A choice of jurisdiction should therefore be baked into the agreement.
Even with that, however, the fact that a smart contract may not necessarily represent the intentions of those who drafted it may result in more difficulties. Courts would likely default to the code in a code-only agreement since that’s what would represent the “final” contract, even if it doesn’t necessarily execute as intended. Ancillary smart contracts with a written text agreement may resolve this issue, even if it’s currently unclear which would take precedence if there are any discrepancies between the two.
When and How to Use Smart Contracts
Given these challenges, it’s likely better to reserve smart contracts for simple transactional agreements rather than use them to structure complex business relationships. That said, there are some best practices that can help them work, such as drafting an accompanying text document, using the text-based contract to populate the smart contract’s code, accounting for failures of oracles, and considering the possibility of coding errors.
Smart contracts are becoming more sophisticated as time progresses, so we may see a day when they can be just as effective as written contracts are now. However, until they reflect the reality of how business relationships actually work—or until the nature of business interactions themselves evolve to become more objective—they’re best reserved for easy-to-automate transactions.