Smart Contracts. Their Potential and Real Limitations. Part 3
Smart contracts and dependence on off-chain resources
It is often assumed that a smart contract will receive information or parameters from resources not in the blockchain, so-called off-chain resources. For example, a smart contract for crop insurance is programmed so that the insurance will be paid if the air temperature drops below 0 degrees Celsius. The smart contract will receive information about the temperature from an external source. This raises two problems.
First, smart contracts cannot retrieve data from off-chain resources themselves; the source must initiate the transfer of information.
Second, the code is replicated across multiple blockchain network nodes, and if the data is constantly flowing, the nodes will receive different information. For example, node 1 receives information that the temperature is -0.5 degrees, while node 2 receives information that the temperature is 0 degrees. Consensus is needed between the nodes to validate the transaction: data inconsistency can lead to the smart contract condition being unfulfilled.
The parties to the agreement will be able to solve this problem with the help of so-called oracles — trusted third parties that receive information from external systems and transmit it to the blockchain at pre-agreed moments, according to a schedule. In the case described above, the oracle will monitor the temperature, determine the onset of frost, and send this information to the smart contract.
Oracles are a great way to access off-chain resources, but using them requires the involvement of a third party. You must enter into a separate contract with them to supply data to implement the target smart contract. As a result, the benefits of decentralizing smart contracts are reduced. An oracle is also a potential point of failure. For example, if an oracle fails, it will provide erroneous data or stop working altogether. These risks must be taken into account before smart contracts are widely used.
What is the “final” agreement of the parties?
In traditional text-based contracts, courts look to the final written document agreed upon by the parties to determine whether they are in compliance or breach. Courts have long emphasized that the final agreement reflects the parties' mutual intent.
In the case of software-only smart contracts, the executable code—and the output of its execution—is the only objective evidence of the terms agreed upon by the parties. In such cases, emails between the parties and verbal discussions about what the smart contract “should” do will likely give way to the software code as the defining expression of the parties’ intent.
Courts may treat the text and code as a single agreement for ancillary smart contracts. The situation is more complicated when the traditional text agreement and the code do not match. For example, in the crop insurance example, the text says that the insurance will be paid if the air temperature falls below 32 degrees Fahrenheit. In contrast, the smart contract says the payment will occur when the air temperature is at or below 32 degrees Fahrenheit. The text agreement does not specify whether the code or the text will prevail in the event of inconsistency, and courts will need to decide (perhaps on a case-by-case basis) whether the code should be treated as a mutually agreed amendment to the text agreement, or whether the text should prevail. In some ways, the analysis of this situation should be no different from the analysis of a situation where the terms of the main agreement do not match what is reflected in the appendices or the work schedule. The fact that in one case, the conflict is between the text and the software code and in the other between the two texts should not be determinative; however, courts may decide otherwise.
One solution is to use a text contract, where the parameters that trigger the execution of the smart contract are not only written in the text but also included in the smart contract itself. In the crop example, the condition “below 0 degrees” can be written in text and specified as a parameter in the smart contract, thereby eliminating the possibility of inconsistency.
Automation of smart contracts
One of the key features of smart contracts is their ability to automatically and relentlessly execute transactions without human intervention. However, automation and smart contracts can only be changed or terminated if the parties specifically provide for such capabilities when they are created, which is among the main challenges preventing smart contracts from becoming widespread.
For example, in a traditional text-based contract, one party may forgive the other party’s violation and not force them to pay a penalty. Suppose a valued customer is one month late with a payment, and the vendor decides that the long-term commercial relationship is more important than any right to terminate the contract or a penalty for late payment. However, if a smart contract is involved, the vendor cannot physically refuse to enforce the contract on an ad hoc basis. Late payment will result in an automatic penalty transfer from the customer’s account or a restriction of access to the software or device if this is provided in the smart contract. Automatic execution does not fit with the way many companies do business.
Similarly, in textual contractual relations, the parties may situationally agree that partial performance of the contract is considered full performance, for example, to maintain the same long-term relationship—or because the parties decided that it is better to partially perform the contract than not to perform it at all. The objectivity required in the case of a smart contract may not correspond to the realities of the parties' interaction.
Modifying and breaking smart contracts
Currently, there is no easy way to change a smart contract, which creates complications. For example, in the case of a text contract, if the parties mutually agree to new terms of the transaction or if the laws change, the parties can quickly agree to changes to the contract or adjust their behavior. Smart contracts do not provide the same flexibility. Modifying an immutable smart contract is much more difficult than modifying the code of regular software not built on the blockchain. As a result, changing a smart contract can lead to much higher transaction costs than rewriting a text contract and increases the likelihood that the desired changes will not be accurately reflected in the code.
Similar difficulties are associated with breaking a smart contract. Let’s say one of the parties discovers an error in the agreement that gives the other party more rights than they agreed upon, or one finds that fulfilling the obligations is much more expensive than expected. In the case of a text contract, a party can resort to an effective breach (or threat thereof), i.e. deliberately breach the agreement and pay damages if this is cheaper than fulfilling the contractual obligations. Moreover, by failing to comply with the terms of the contract or threatening to do so, it is possible to sit the other party down at the negotiating table and discuss a peaceful dispute settlement. Smart contracts do not provide for such options at all.
Smart contracts are currently being developed to be easier to change and can sometimes be violated. In a sense, this is unethical given their immutable and automated nature, but they will benefit from innovations that reflect business realities and how the parties to the contract act.
Feel free to drop a “Hi” at Pharos Production, where we bring software to life! 👋✨
“Join our exciting journey with Ludo — the reputation system of the Web3 world! 🌍✨”
