Published on December 24th, 2017 | by Michael Barnard0
Blockchain Contracts for Electricity: Business Drivers
December 24th, 2017 by Michael Barnard
Blockchain is hot right now, not only as the underpinning of bitcoin, but because it has the promise to be a disruptive technology in multiple sectors. I started my exploration of how it will impact electricity’s transmission, distribution, and sale in “Bitcoin’s Hot But Blockchain For Cleantech Is Interesting.” In a three-part series of articles on the nature of smart contracts based on blockchain technology, I dive into this topic further.
Part 1, “Blockchain Contracts for Electricity: Underpinnings,” lays out the technical and business underpinnings of smart contracts.
Part 2, this article, lays out 9 factors which can be used to determine where smart contracts will shine and where they won’t.
Part 3, “Blockchain Contracts for Electricity: Sweet Spots,” looks at the implications for different business models in general and for the electrical generation and distribution business overall.
All articles on cleantech + blockchain are also being published on https://future-trends.cleantechnica.com/cleantech-blockchain/
There are 9 factors which will help to identify the sweet spot for smart contracts that emerge from the exploration in the first article:
- Herstatt risk due to currency volatility
- Time value of money
- Speed of transactions
- Cost of transactions
- Accounts receivable and default costs
- Penalty clauses
- Multiplying parties
- Trusted contract writers
- Bad contracts
1. Herstatt risk due to currency volatility
Herstatt risk or settlement risk is the risk that a foreign exchange rate will change after a contract is locked in at a specified amount of a specified currency. Obviously this is a two-way risk, as if the exchange rate goes up, the buyer will pay more; and if the exchange rate goes down, the seller will receive less. The more volatile the currency and the longer the time until settlement, the greater the risk.
This is critical in cryptocurrencies right now since they are so volatile compared to the normal currencies of the developed world, which typically change against one another in single-digit percentages in any given year. Further, most cryptocurrencies have little historical data for assessment and don’t respond to the same geopolitical events in the same way as fiat currencies.
From a Herstatt risk perspective, cryptocurrencies’ volatility and lack of historical data definitely introduces challenges. More stable currencies can be more easily hedged for Herstatt risk, but cryptocurrencies are all over the map on any given day right now. With bitcoin and Ether, as the two major examples, both having climbed substantially over the past couple of years, smart contracts have been favoring the seller more than the buyer. But short-term smart contracts, which is what most of them have been to date, have been risky in both directions. The chart on the left from Appcoins shows a range of over $60 USD or close to 14% in the past week.
The 24-hour volatility doesn’t inspire much more confidence with $34 USD (or 5%) variance. These are currencies with a high Herstatt risk at any but the shortest time periods.
Of course, with any risk comes hedges to accommodate the risk. The easiest is just shortening the time period until settlement gets to an acceptable level. But as the volatility in even very short contracts shows, the risk remains very high. This is minimized somewhat by the reduction of escrow fees, so there will undoubtedly be buyers and sellers who choose to accept the risk regardless in business models where high escrow fees currently hold true.
The second hedge has more merit, I think. A smart contract can be set up to reference external exchange rates, for example the stable US dollar to the volatile ether. This would be implemented by having an external program feed the exchange rate at completion into a variable in the smart contract, or by having a constant feed of exchange rates into a blockchain accessible by all contracts. The contract can be for a certain USD value at the point of contract completion based upon an agreed upon external provider of exchange rates. The payment is in ether equal to the USD price agreed upon. In this case, the escrow account has to participate in the hedge by holding the likely largest amount of the cryptocurrency given volatility.
For example, you have a website and want an ecommerce payment system added to it. You contract a developer to implement it. He tells you it will take a month and cost $2,000. You agree and enter into a smart contract using Ethereum. You jointly agree that the likely maximum volatility is 50% down and 100% up. Using $400 ether exchange rates, you would need 5 ethers for the payment. Given the volatility, you might see from 2.5 ethers to 10 ethers required. You transfer 10 ethers into the smart contract’s escrow. You agree upon a third-party service which will validate the existence of the ecommerce service in your website in a month and which is able to update a variable in the smart contract.
Upon a month being up, there are a few outcomes.
- The ecommerce system isn’t in the website. The smart contract returns 10 ethers to you.
- The ecommerce system is in the website and:
— The exchange rate is at $200. The smart contract transfers all ethers to the developer.
— The exchange rate is at $800. The smart contract transfers 2.5 ethers to the developer and 7.5 ethers to you.
— The exchange rate is at $400. The smart contract transfers 5 ethers to both you and the developer.
— The exchange rate is $1000, outside of the agreed volatility range but on the upside. The smart contract gives 2 ether to the developer and 8 to you.
Those are the uninteresting scenarios in that the risk hedging worked as intended. The final scenario is more interesting. The exchange rate is $100. Now there is only $1000 USD equivalent in escrow. This leads to a last couple of options.
- The developer could have put a license key into the ecommerce software, with your knowledge, and code in the license management could be set to enable or disable the license key depending on the equivalent of $2000 being available in escrow. If it isn’t, then the smart contract could be set to allow you to submit more ether to match the $2000 or have the ecommerce software not work. You’ve got a serious choice to make because you’ve already sunk $4,000 into something worth $2,000 to you and now you have to decide if it’s worth another $1,000.
- The developer could also just accept the Herstatt risk for the sake of convenience. In this case, the contract pays out. Once again, you are out $4,000 assuming you transferred funds into ether for the purpose of contracting, but the developer only receives $1,000.
Obviously, the volatility range is an important factor in your hedge, and it’s difficult to predict. You want the range to be lower to limit the risk of the last scenario where you effectively lose a bunch of money. The seller wants it to be higher to limit the chance of not getting paid for work. After all, it’s only in one of the above scenarios that the developer is at risk of getting no money, but there are two where you are out $4,000 or more.
2. Time value of money
Time value of money is another issue with smart contracts. Escrow is fine and dandy, but it’s not used on all that many contracts compared to net 30 terms. Some of this is due to the fees being high, which smart contracts reduce substantially. But time value of money is another big reason. Every major business has a chief financial officer whose job includes maximizing the returns from cash on hand. They move it into and out of foreign currencies and money market funds to gain some benefit from it.
Net 30 terms means that in a one-month contract, you only have to pay 60 days after contracting with 30 days for delivery of the service and 30 days to payment. In pretty much every longer-term contract of multiple months, sellers negotiate to create terms where they can invoice monthly to increase the time value of money to them while buyers try to negotiate longer durations between invoicing to maximize their time value of money.
But in smart contracts you have to put the money into escrow at time of signing the contract, 60 days earlier. And as the Herstatt risk hedge assessment indicates, you will likely have to put more value into escrow than the actual value, double the money in the example.
In the hypothetical case above, this means you have no potential to get value out of your money for two months. Once again, this favors the seller, not the buyer. And this also assumes that you have sufficient cash-on-hand that not having the amount in escrow isn’t putting anything else at risk.
3. Speed of transactions
The slow speed of transactions means that smart contracts aren’t particularly suitable for e-commerce applications right now. When you pay for something on iTunes, you receive access immediately. Bitcoin transactions take 10 minutes to process and Ethereum only features 15 second transaction resolution at best. Neither guarantees a transaction will be in the next block, so it might be hours with Bitcoin if there is a high transaction load for a transaction to clear. And smart contracts will typically feature multiple transactions of various sorts.
Consumers aren’t interested in an extended wait for gratification. This use case would just be a straight payment from wallet to wallet, which is still problematic in many cases due to the speed of transactions. Current cryptocurrencies don’t support the transaction volumes necessary for mass ecommerce solutions today, and possibly never will.
4. Cost of transactions
The cost of transactions with cryptocurrency makes it less useful for smaller transactions. Buying a coffee for $3.00 and spending $1.00 for the transaction won’t be acceptable to either the buyer or the seller and neither will be interested in paying it. Merchants pay the credit card transaction costs of 1.5% to 3% out of their thin margins today, but that’s only 4.5 cents to 9 cents on a coffee. 33% won’t fly.
Regardless of anything else, cryptocurrencies are currently unsuitable for smaller retail transactions. Sellers who use the Amazon platform to sell their products today pay about 60 cents for a $10 transaction, so a dollar is a big increase.
For smart contracts, they have to be decent sums and it has to be clear who is paying them. Given the loss of time value of money and Herstatt risk, if I were entering into a smart contract as a buyer, I’d be negotiating to have the seller pay all transaction costs to somewhat even the terms. But it’s unlikely that a lot of templated smart contracts will give buyers that option, as they will be set up by sellers. Yet again, the advantage in this is for the seller, not the buyer.
5. Multiplying parties
One of the purported advantages of smart contracts, including a third party such as a delivery organization in a contract, is actually an added complexity. Anything which involves multiplying parties to a contract increases its complexity, as is true with any solution to a problem. One of the original English formulations of Occam’s Razor was do not multiply entities without necessity. Three-party arrangements today typically involve one contract between two of the parties and a different contract between two of the other parties, not one contract between the three parties. One organization takes on the costs and risks of one of the parties, such as the delivery organization, and includes them in their price either explicitly or implicitly.
Every services contract I’ve negotiated has included only a service organization and a customer, and those contracts have often been worth millions of dollars. This is the most common pattern, and the value proposition of adding additional entities is unclear in most cases.
Tri-party agreements are relatively common in the construction industry, but less common elsewhere, and those tri-party agreements are in aid of financing and not escrow agreements with virtual currencies.
6. Accounts receivable and default costs
Accounts receivable and default costs are a strong advantage of smart contracts for the seller and no direct advantage to the buyer.
Net 30 contracts involve an invoice being generated by seller and being sent to the buyer. If the buyer doesn’t pay, the seller has to dun them for the money. If they continue not to pay, the seller has to take the buyer to small claims or civil court to try to exact payment.
Escrow contracts by definition protect the seller, not the buyer. All of the buyer’s money is in escrow, not the seller’s. The seller is guaranteed payment and the buyer has no ability to default except in the case of the seller not meeting the smart contract’s conditions. There is no need for any civil action by the seller against the buyer with any decently structured smart contract.
7. Penalty clauses
Penalty clauses are one place the buyer starts to see an advantage. If a buyer needs a good or service at a particular time in a particular location or its value starts going down, a smart contract can be very useful for them. The obvious analogy is to many pizza parlors’ promise of 30 minutes or free. Pizzas that can be free if late, of course, are likely to be too inexpensive to warrant the contracting costs. But imagine a supply chain smart contract requiring delivery of a product to a construction or manufacturing site on a just-in-time basis.
The buyer of just-in-time goods has distinct downsides to late and early delivery. They have to put early deliveries into inventory and then take them out again, incurring costs which impact profits. They have to slow or halt their construction or manufacturing if the goods they need are late, which in turn impacts their delivery and their cash flow.
A smart contract which had clauses which penalized either early or late delivery automatically would be advantageous. No need to worry about adjustments or negotiations of penalties or getting into lawsuits. The penalties would be automatically incurred upon delivery. In some business models, this factor alone could make it worth a buyer’s time. And since so many of the benefits are in the seller’s interest, they’ll be amenable too.
8. Trusted contract writers
Smart contracts are applications that will be impenetrable to most buyers and most actual sellers. Instead of putting your trust in Visa and Amazon, you are placing your trust in someone else entirely, the developer of the contract.
Smart contracts are easily gamed by unscrupulous people who set them up specifically to take advantage of someone else who is less sophisticated. Imagine a templated contract which appears to have configuration which returns payment for non-delivery, but actually pays one party regardless of what happens. Unless you look at the code and can understand it, you’ll never see that.
And it will frequently be the seller who sets up the templated smart contracts. After all, they are trying to sell stuff and smooth the way for buyers.
For larger contracts, there are currently experienced negotiators on both sides and lawyers on both sides making sure that terms and conditions are as favorable as possible. Contracts with a major consultancy, for example, won’t get approved for release by the consultancy’s management or lawyers with net 90 day terms.
In addition to lawyers, smart contracts will need to involve programmers initially. Eventually trusted, sophisticated and configurable smart contract systems which allow selection of terms and conditions, recognition of third parties and the like will emerge, but it’s early days. Right now, an additional cost for anyone doing this includes paying developers.
9. Bad contracts
When a business contract turns out to be bad, there are remedies. There is small claims court, there’s good faith between the buyer and the seller, there’s value-in-kind agreements and the like. There are ways to make the parties whole enough and typically the money doesn’t just disappear. If one party dies while money is in escrow before delivery of value, there is case law and often boilerplate terms and conditions which cover the situation.
But with smart contracts, it’s possible for the money to go into escrow and never, ever come out. The point of smart contracts is to keep money safe between two parties entering into an agreement. But what if the conditions of the contract aren’t met due to a programming error or just lack of sophistication on the parts of the people entering into the agreement? In that case, the money can go into escrow and stay there forever. Imagine a smart contract that is looking at the wrong variable for the triggering condition, so it never comes. Imagine an external program which fails to put anything into a deliverable entirely. There is nothing inherent in smart contracts that prevents those situations except developers testing programs, and we all know that the history of software is riddled with defects.
These 9 factors will help us determine where smart contracts based on blockchain will shine. There are many cases where the advantages are strongly one-sided. But that doesn’t mean that they have no value or that value won’t emerge.
The next article, “Blockchain Contracts for Electricity: Sweet Spots,” looks at the implications for different business models in general and for the electrical generation and distribution business overall.
As always, I’ll be paying close attention to comments. If I’ve mischaracterized something or made other mistakes, please let me know. Similarly, if there are emerging smart contract examples or utilities accepting cryptocurrencies, point them out to me, especially in non-English language countries.