Written by Michael James on Monday 31 October 2016
The concept of ‘Smart Contracts’ is simple; clauses and rules are embedded in software which is distributed via networks to provide an interface which formalises a transaction.
Bitcoin has a distributed ledger a distributed consensus mechanism, and a distributed set of business rules and conditions. The contract for Bitcoin is relatively simple: ‘are the parties who they purport to be’, ‘do they have permission to buy/sell’ and ‘does the buyer have funds’. This is a straightforward smart contract which is actioned and then fulfilled for every buy or sell on the bitcoin network.
The idea of a smart contract is very powerful; putting your trust in a set of rules and a shared consensus mechanism rather than any one party seems, on the face of it, an ideal solution. In finance we already trust in rules and triggers such as ‘Stop Loss Orders’ and ‘Buy triggers’ for share trading. This kind of trigger is relatively simple but still this transaction has its fair share of intermediaries and parties. For a wealth product, where I may be buying units in a fund which will trigger purchases in multiple markets and assets there are many more intermediaries and contracts. This increasing level of complex relationships and parties means that the contracts and rules must also be more complex and brings me to my concern in developing even medium complexity smart contracts with high levels of automation.
Even short simple texts can, if the recipient is in one mood or another, be read with the wrong inflection or intent. This is without the misspelling and dressed (dreaded) auto-correct. In the world of software there is a plethora of opportunities for missing or misunderstanding information in the journey from defining requirements to writing code. In the transformation world we are used to catching these at the normal approval, testing and release gates and yet still bugs creep through the process. For most commercial applications such errors can be embarrassing and occasionally costly but, for smart contracts, bugs in the code and mistranslation of rules could be catastrophic.
This was highlighted in the recent DAO hack; The DAO is a crowdfunding Decentralized Autonomous Organisation. The creators codified the rules and decision-making process to bring in funds to the DAO that represent ownership and then those owners have the right to vote on the use of funds to anyone submitting a proposal for funding to the DAO. The DAO relied exclusively on its rules and code to run the business. Though there are some suggestions that the business model was not fully ratified, the DAO raised $150m for distribution. The DAO went live with some vulnerabilities and these where exploited by a hack taking out $50m. The possibility of a hack or wrong doing had not been considered, the whole distributed codebase had to be forked into leaving this business in some disarray. Essentially this was a code writing problem, but it shows how a small issue in the software can be very costly in relation to smart contracts. ** http://www.coindesk.com/understanding-dao-hack-journalists/
That doesn’t mean we should avoid applying smart contracts technology to financial services and I see plenty of opportunities in know Your Customer (KYC) and sign-off processes that are not that complex where the technology could really prove itself. But before we jump head-long into ‘consensus driven distributed autonomous smart systems’, maybe financial services just need to think about smarter ways to help the customer. For example, my heating oil company give me interest on credit, monitor my oil level and fill the oil tank at the best time automatically. That feels very smart to me.
This article was first published in IBS Intelligence 27/10/16