Eden Legal has always seen potential and interesting applications in “the blockchain” (or decentralised ledger technologies as we probably should say). Though until recently, if asked I would probably have said that the crypto world seemed to be populated by the some of most impenetrable computer scientists and some of the most brazen scoundrels.
But 2021 is set to be the year of smart contracts. So we’ll see lots of business contracted on decentralized ledgers with the characteristics of being publicly recorded, self-executing, immutable and irreversible. And not just because of the word “contract”, this can’t be ignored by Eden Legal.
This post is mostly some very initial, personal thoughts on where we are and what smart contracts may mean in practice. Eden Legal always aspires to be at the interface of technology, business, and law – but we are all still learning. Eden Legal will return to this topic – and probably many things will have changed by then.
- First off, you and I are probably not going to sit down and write a smart contract. Most of us can’t code (you lost me at “pragma”). What we’ll more likely do is use someone’s ready-made platform where the contracts are set up and fill in the gaps (think NFT minting – “insert % resale royalty here”). So we contract without seeing the nuts and bolts of the code; but this is really what DeFi etc. is supposed to do – to provide a marketplace or pool for individuals wanting a financial service and other individuals looking for yield, each probably not knowing the other, with more or less composable options.
- Between businesses, there wouldn’t be obvious advantages to using pure smart contracts. We’d need to hire someone to do it and pay them to write in a language we don’t understand. Currently, they may work better for B2C contracts. And setting out the logic of what happens on what trigger is definitely the sort of thing that lawyers should be able to help coders get right. There would also need to be some natural language explanation of the what the consumer is committing to – which could end up forming part of the contract. If Eden Legal were a regulator, this might be one of the things I would be asking peer to peer and B2C smart contractors to improve.
- Lawyers like to discuss whether smart contracts are legal contracts. And for sure, if we had a pure smart contract, then we’d want to know that it was binding and enforceable (and by the way, Eden Legal’s view is that there’s absolutely nothing preventing this). But in business we probably won’t “enter into” a smart contract with each other. But what we might do is automate the execution or back-end processes of a certain portion of our – human readable, natural language – contract, using an agreed platform.
- Smart contracts are of course quite dumb. They are good at binary and unsophisticated if-then logic. And especially good at if-something-happens-on-chain then-this-should-happen-on-chain logic. They aren’t so good at exclusions or unlesses. So arrival of a shipment can automatically release payment for goods. And travel delay can automatically release an insurance payment. But actual “events” or “losses” which could be subjective (especially if we need to decide whose fault this was) are much harder to cater for.
- This may mean that we’re agreeing to pay out based on a validatable parametric trigger, i.e. based on data as evidence of an event, not the event itself. So we are saying we will pay when the carrier’s systems indicate that the delivery has been received at the destination (and not “we will pay when the goods arrive safely”). Or the insurance will pay out if x weather station says there was a hurricane (and not “we will pay if your crops are destroyed”). This is nothing new; the new part is really the automation.
- So we will need to agree on a trusted data source. Often we will be linking an IOT or AI oracle to our smart contract. For major contracts might we want to have multiple oracles and take a majority decision? Do we need a back-up if our usual data source goes offline? We could also still rely on an “analogue” solution, e.g., a trusted third party to be the data source – so a doctor could send a medical or death certificate, or someone could enter a confirmation that products have passed acceptance tests, upon receipt of which the smart contract could make a pay-out.
- Particularly if there is a qualitative element (were the goods of the correct quality? was the accident not your fault?) then self-executing smart contracts may not be the friend of the party who needs to make payment. So we need to choose carefully for which types of contracts we implement them. Because when we do then there may be an interesting shift in the litigation risk from the party trying to get paid to the paying party trying to get automatically transferred currency refunded. Or possibly we again need a third party – e.g. a multisig arrangement where a third party arbitrator must also approve the transaction and is given a key to do so.
- How do we guarantee payment? A self-executing smart contract can’t solve a wallet having insufficient funds. Do we need to pre-collateralize the contract with the full amount of the foreseen payment? This might work for one-off transactions where today we rely on escrow; but for one-to-many transactions like insurance this is hardly practical. An on-chain guarantor would raise the same issues. Possibly we might have to consider off-chain security in the normal way.
- For an ongoing contract we might need it to expire or to be able to “terminate” our participation when we no longer want to interact with it – can we achieve a similar result with a date parameter or a selfdestruct command?
- Using a technology-based solution eliminates “trust” in a lot of ways, but not other risks – code may be buggy; protocols may change; hackers may hack. So we might want insurance against these risks – hopefully on a different platform or off-chain…
- While smart contracts can’t push data or funds into the real world, we might want to denominate the contract in a stablecoin – for Eden Legal cryptocurrencies are still too volatile (when denominated in fiat currency) to make for comfortable transactions in most cases.
- If there is a dispute then what is the law that governs it and where will would we need to go to court? If we are contracting between two wallets or addresses, who are the parties and where will we locate them if something goes wrong? If our contract sits on a distributed ledger how do we keep certain information confidential? There are plenty of things for which a natural language contract will be preferable – so we may be looking at hybrid solutions for some time to come.
- So the excitement around smart contracts is understandable, but we are still very early here. Human readable contracts will still be perfectly good solutions in many cases – smart contracts aren’t revolutionising the legal world quite yet. And even with smart contracts, humans may still be required to validate certain parameters or to resolve unforeseen issues. However, distributed ledger technologies offer plenty of benefits. And almost everything is more effective when digitized. So from a legal perspective the process will be gradual – but in 2021 now probably inexorable.
