Smart contracts, a primary focus of distributed applications on blockchain technologies, are a key area expected to deliver disruption. But while there is strong potential, there are challenges to overcome.
Many of the business implications are specific to the nature of cryptocurrency smart contracts which by nature are escrow contracts, in which the smart contract itself acts as the trusted 3rd party holding the payment. If the contractual terms are met, the payment is made. If the contractual terms are not met, the payment is returned to the buyer.
There are nine business characteristics with business implications which must be assessed for any given smart contract solution.
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 and dropped in 2018, 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 weekly Ethereum price has a range of over $80 USD, roughly 40%.
The 24-hour volatility doesn’t inspire much more confidence as this recent example with a swing of close to $40 or around 15% shows. 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.
A 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 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.
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.
Externalizing settlement to non-cryptocurrencies is another solid business strategy. Hyperledger does not support direct cryptocurrencies at all, although one has been built in it and there are implementations of loyalty tokens. All currency settlements in Hyperledger are expected to through external, 3rd-party payment systems, which could be either fiat- or crypto-currency based. The under development Eos technology is designing to allow both options. And certainly, while Ethereum smart contracts assume escrow settlements in Ether or other Ether-based currencies, it’s possible to externalize payments in this case as well.
Lastly, the entire challenge of volatility has given rise to stablecoins, which use a variety of hedging and governance strategies to remain at par or close to at par with a fiat currency, most often the US dollar.
Time value of money is another concern 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 short term returns from cash on hand. They move it into and out of foreign currencies and money market funds, often daily, 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. Many net 30 terms also include inducements to pay more quickly in the form of a discount, e.g. a 2% discount on purchase price if payment is received in 10 days. 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. 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.
The escrow approach is acceptable for short-term transactions, but for longer term services delivery, externalizing payment to a fiat currency or stablecoin through a 3rd-party mechanism becomes important.
The slow speed of transactions means that smart contracts aren’t suitable for many 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; only recently has the backlog been cleared due to reduced volumes. 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.
Some of this issue is reduced with cryptocurrency-based settlement, simply because both parties will put trust that the cheque is in the mail, effectively. And there are now higher-speed settlement systems emerging which use a variety of tactics to speed bulk transactions. Externalizing payment systems to higher-speed credit card transactions also eases this concern.
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.
Not all cryptocurrency transactions require transaction fees of course. However, the optional transaction fee is what makes it more likely that the transactions will be included in the next blocks created. They are part of the business model, and part of the reason why organizations choose to host block creation components of cryptocurrencies.
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.
Structuring business relationships beyond the most simple transactions requires agreements with multiple parties in a value chain. Creating a blockchain solution where one party creates the value chain and then establishes individual contracts with others to appropriately spread the gained value around to incent involvement is a likely approach. Banks already have mutually owned entities which provide debit settlements between them, so extending these business relationships has potential.
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.
Externalizing payments to 3rd party payment systems with more traditional terms, whether stablecoin or fiat-currency based, does not gain this advantage and the costs continue to be borne by the selling organization.
License: CC0 Public Domain
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 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.
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, even if the solution is only a distributed application providing administrative relief for the execution of a traditional contract.
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 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.
Regardless of whether the solution is a permissioned, private blockchain or a permissionless, public solution, automated test harnesses become critical when establishing smart contracts. I foresee the use of Monte Carlo approaches to explore the edge conditions which could cause locks which cause escrow-locks and other conditions. Additionally, a major subject of discussion is the degree to which human governance agents are required in blockchain solutions, with multiple emerging models, simply to allow overrides or fallbacks in the event of adverse conditions.
Architecting business solutions with blockchains requires attention to the business architecture as much as or more than the technical architecture. These nine factors will help you determine where smart contracts based on blockchain will be suitable for your business needs, and how to manage your choices. There are many cases where the advantages are strongly one-sided in straightforward cryptocurrency smart contracts, but there are existing and emerging solutions for most of these concerns.