Smart contracts seem to be a terribly clever and useful thing: a self-executing contract without the need for middlemen while saving transaction costs and being immune to manipulation. That seems to be good to be true, and of course, it is, as a smart contract, in most cases, is neither very smart nor necessarily a contract in the legal sense. Not to mention how many smart contracts were hacked or bypassed or otherwise tampered with.
Smart Contracts in the wild
Yet the subject is interesting, but from my practical perspective as a lawyer, I see relatively few examples of real-life use of smart contracts (in the narrow sense, excluding the notorious soda vending machine). This is not to say that such use does not exist: it does in many blockchain transactions, in DAOs, in facilitating revenue shares when digital assets such as NFTs are sold on, in insurance, healthcare, and finance / DeFi applications. But compared to the amount of “other” contracts, their market share is tiny.
Furthermore, many of the use cases that are often proposed for smart contracts are not convincing or practical. For example, it is in most cases a terrible idea to use smart contracts to facilitate insurance payouts, as the circumstances under which such payout is supposed to happen can often not easily be proven or simply fed into a ledger by oracles or similar mechanisms. The world is a noisy place and who is at fault in a traffic accident is sometimes hard to determine.
There are, however, many situations in which there is much less noise and uncertainty and where all necessary information can easily be obtained and may, in many cases, already be recorded anyway on some form of electronic ledger, albeit not necessarily a blockchain.
The Service Level Agreement (SLA) as a use case for smart contracts
I propose to consider the use of smart contracts in tech Service Level Agreements (SLA). I have no illusions of being the first one to do so – a short Google search shows that the idea is not completely novel. Yet it is certainly not yet mainstream. That is surprising insofar, as SLAs may be a rather low-hanging fruit in that respect.
One of the core ideas of many SLAs is that a certain service does not have a fixed price, but the price may vary depending on the level at which the service is provided. A higher bandwidth or shorter response time may entitle the provider to reap a bit more money, a shortfall will require the customer to pay less.
Furthermore, SLAs very often contain very detailed stipulations as to how the level of service provision can be measured and where that has to happen, e.g. at the point where data leave the data center and are being fed into the internet. And all those information must be recorded and managed anyway, read: stored electronically in almost all cases.
It seems to me rather convincing to expand the existing mechanisms a bit to enable automatic payment (and necessary paperwork) resulting in a real-world reduction of administrative overhead and thus cost. Most of the technical infrastructure is already in place.
But on which chain?
There are, of course, a few practical issues. One of them (discussed for example in the paper “Cloud Service Billing and Service Level Agreement Monitoring based on Blockchain” by Neidhardt, Köhler, and Nüttgens) is the blockchain such system should run on.
While in theory, I like the idea of this being Ether et al, I do not see how this can work in practice as rational business actors may not want to be subject to wildly fluctuating prices. The more appealing idea seems to be a private blockchain. That need not necessarily be a very obscure one, it could easily be a de-facto infrastructure / open chain. Maybe SAP wants to get its edge back and try something in that direction.