A smart contract is self-executing code that follows pre-programmed rules, which are then verifiable on a blockchain. As such they are a misnomer. They are not smart, because they can only do what they are programmed to do. They are not so much a contract as a tool within a contract. However, smart contracts are very useful in carrying out tasks, especially complex or potentially contentious calculations, which may be required at the execution stage of transactions. Examples might be determination of the proceeds of sale on a derivatives transaction. As junior employment lawyers know, much time can be spent (wasted) in trying to agree the terminal payments or an employee’s last day. If someone could produce a smart contract (perhaps most sensibly for a large employer) taking feeds from holiday records and payroll, this would be a boon.
But just because a blockchain is involved (and everyone knows that they are immutable, and – this side of quantum computing – uncrackable) this does not mean smart contracts can’t go wrong, or will not give rise to disputes. That is because smart contracts are software systems, and susceptible to the same frailties as all software; and because they will require inputs – and such inputs may be open to question.
Software works when it is subjected to extensive testing (factory; user; beta) and a period of live use in production. This means that software should best not be relied upon to be reliable until thousands of test cases have been undertaken. However, smart contracts have on occasion been pressed into service for a single live event, or perhaps in scenarios where only limited beta testing had been undertaken. I recall one Initial Coin Offering (ICO) when the developers of the smart contract to be used in minting and distributing coins were to be paid an enormous bonus simply if the ICO was undertaken without a hack or other cyber event. This sort of thing does not instil confidence!
Going back to the putative smart contract to calculate employment termination payments, there may remain the prospect of dispute between the parties. For example, the employee may dispute the number of days recorded as having been taken as leave. Whilst the smart contract could not be faulted in such circumstances (probably), a dispute of that sort would remove the benefit of having used the smart contract.
If it is agreed that smart contracts may lead to disputes, then it is worth looking at how those disputes may unfold and best be disposed of. The disputes might be broken down into various categories:
- Development of a smart contract
Like all software development projects, production of a smart contract is fraught with difficulty and may lead to disputes between the procuring party and an independent developer arising out of the perennial issues of (1) scope; (2) delay; (3) failure at acceptance stage (bugs); (4) technical design flaws or (5) poor project management.
The dispute resolution mechanism should be prescribed by the parties in the development agreement, and might helpfully include an element of expert determination.
- Claims following hacks or other data loss through use of a smart contract
Assets (funds; digital assets; contractual opportunities; misdirected goods; personal data) may be misappropriated or simply lost in the event a transaction supported by a smart contract is susceptible to external intervention. Claims may arise from: individual consumers (or groups claiming through representative or class actions); adjoining participants in an ecosystem (trading or otherwise); or the owner / operator of the smart contract (claiming physical loss or damaged reputation). Claims (which may be tempered by limitations and exclusions of liability) may be dealt with either in accordance with applicable terms and conditions (e.g. customer use agreement) or as a claim in tort by those without a contractual nexus between themselves and those they are claiming against.
- Unintended operation of a smart contract
In cases where something less than exhaustive testing has been undertaken on the smart contract, there may be scope for the software to operate otherwise than intended. This would not be a “blockchain” fault. It would be because either a necessary rule or exception had not been coded into the smart contract or because it had been miscoded and such defect had not been adequately tested or remediated. The fault may lie either with the developer of the smart contract or the procurer. It may give rise to a scope or design issue. If the defect arises after a system acceptance certificate has been issued, the procuring party’s redress against the developer may be limited.
Given the highly technical nature of these disputes, it can be most appropriate for the parties to include an arbitration agreement in their development and use agreements. This is all the more so given that smart contracts are likely to be cross-border in nature to facilitate peer-to-peer or business-to-consumer transactions. It is imperative to include clear dispute resolution provisions and to stipulate the choice of the governing law in natural language to remove the risk of any ambiguity. In the absence of an express governing law clause, the court or tribunal will have to consider a number of factors to determine what law should apply including the physical location of the parties and the place of formation of the contract. To mitigate against jurisdictional issues, parties should include clear provisions on governing law and dispute resolution.
With stakes often being quite high, it would seem that the upcoming proliferation of the use of smart contracts will not be a panacea to avoid disputes, but will likely give rise to disputes in multiple guises.
