Programmable law: 4 Key Features which will enhance smart contracts, and will make lawyers code

Law has been with us for as long as we have civilization. Currently, the law is behind all or most factors of our and business lives. It can, however, not follow the speed which currently we do our business, do resolutions, define lawful frameworks,  sign contracts, execute contracts, etc.

Blockchain technology could provide a big push in helping and automating some legal procedures. The first small step towards it was the introduction of distributed ledger technology (DLT) and the introduction of ‘Smart Contracts’ by Ethereum Blockchain ecosystem. The Ethereum Blockchain ecosystems enabled us to code “If, then” statements with transferable assets incorporated in the code. This means that if the specific action is done, the code will be executed and the specified Ethereum amount will be transferred from the first specified account to the other specified account.  (you read more e.g. here)

The definition of a smart contract is well defined by Clack, Bakshi and Braine(link):

A smart contract is an automatable and enforceable agreement. Automatable by a computer, although some parts may require human input and control. Enforceable either by legal enforcement of rights and obligations or via tamper-proof execution of computer code.

Currently what Ethereum blockchain provides is usability of using multiple ‘if-else’ statements to define the conditions of the contract. I would not use the word ‘legal contract’, as no country or legal jurisdiction has signed explicit law stating that these contracts on DLT or blockchain are legal. The ‘smart contract’ usability can be also misinterpreted as the current contract on blockchain does not have any type of intelligence, which it could use to execute the steps. Current possibilities could be defined as a smart contract v0.1, as with some further key features enabled it will transform the law enforcement to the next level.

First of all, the core feature missing is the legality of the user. Currently, in blockchain space, the contract itself is stored as alphanumeric address, e.g.:


The users or participants of this contract would have the same representation – the alphanumeric string. However, it is not a proved and verified identity. Solving the issue of legalizing the user would be a groundbreaking move towards implementing smart contracts globally.

Secondly, there should be a specific and agreed DLT where these contracts should be stored. In my view, in future, we will have multiple DLTs around the world with different use cases, or legal specificity. This is needed to avoid duplicates of the contract. The code would be incorporated in the distributed ledger and would be the main version, which both parties/participants would rely on. Therefore neither party would be able to tamper with the code, and that would make the legal contract ‘self-enforcing’. This would mean that after a specific event has occurred, e.g. the container came to specific GPS location, one party would receive the payment which was coded in the legal smart contract. Other participants would not have the possibility to decline the payments.

Thirdly, there is a need to define legal location. Blockchains infrastructure nodes usually are scattered all around the world for multiple reasons – the main one is the proof of work algorithm, as the miners are in search of cheap electricity for mining and putting the transactions on the ledger. This creates a question of which jurisdiction the contract would be applied. The legal contract must have an identifiable location to determine the applicable legal jurisdiction for various legal questions relating to it.  Some examples of this are the legal definition of crypto assets, cryptocurrency, or simply the legality of smart contract stored on the distributed ledger. A solution could be to include the legal location in the smart contract as an option and automatically register the smart contract with the legal institution, which would put it into a smart contract registrar.

Last but not least, some operational and non-operational clauses are easier to be left on paper. Some features in a legal contract like the definition of force majeure or occurrence of a specific event at a specific time would be too expensive and too hard to code and too hard to measure in the smart contract. The occurrence of these events could be also very rare, so putting it in the code would not give a wanted return on investment. It would be much easier to keep it written in the legal contract. ISDA document has pretty well defined these events (link).  This could be solved by having a legal contract in a written form stored in the decentralized storage, like IPFS, StorJ, Swarm, etc., or in cloud storage which has auditable, legally approved, and timestamped storage.IMG_2066

Step by step solving one or few of these issues will create a perfect framework for having real smart contracts on DLT. So what it would make our life look like? Easy – we would have lawyers writing code, and making smart contract templates, which could be used in setting contracts. I believe having this framework will reduce the inefficiencies of the current business ecosystem and reduce the current price of legal validation.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s