I have been droning on about virtual automatic contracts for a few posts now.
By the by, today is a bit of an exciting day because later this evening I will be going to the Ethereum meetup in Amsterdam. This will be an interesting opportunity for me to speak with others who are interested in exploring the possibilities of virtual automatic contracts generally and also to see specifically some more details as to how Ethereum smart contracts will work. I am particularly interested in how to test and deploy contracts onto the network. For the most part the Ethereum scripting language appears to be relatively straight-forward, but the key thing I’m currently lacking before I really dig deep and start coding out provisions and contract structure templates is how the contracts get from my text editor where I draft what I think they should be to a test environment to make sure they are not throwing any errors I did not want and then into the actual Ethereum network. Understanding how that test and deploy will work is crucial else you will not be able to get your contracts to work within the system. This piece is not necessarily about Ethereum, in the vein of my previous pieces this is more generalized in nature and should apply to other smart contract protocols that are coming online.
If virtual automatic contracts are going to be even moderately interesting beyond simple financial derivatives of other virtual currencies or products then paradigmatic linkages to real world events must be developed. I have been thinking about this for a while because if Watershed wants to be able to support the development of DAOs and other smart contract mechanisms – which is where we are attempting to go over the course of the year – then the real key to development of any contract which will have more than an academic interest is how to link to the real world. So far, I have come up with three paradigms that I think would to a certain degree work.
IRL Paradigm Linkage 1 - Data
As I stated in my previous post on open data and development, data which is aggregated by an agency or organization which the parties agrees is neutral and has no incentive to skew the data in either direction could be agreed to by the parties as a provider of machine consumable IRL data which smart contracts can use to make “decisions” and “spend” its money appropriately.
I will steal an example of how this could work from Charles Hoskinson (who for the record is quite eloquent at explaining what Ethereum is up to). Let’s say you wanted to develop a crop insurance mechanism. Let’s say that you found there was a single causal link between crop returns and rainfall and that for the most part you were not interested in (for whatever reason) insuring against vector or pest crop failure or any other failure. You were only going to insure crops against a lack of rainfall.
You sell a product whereby at the beginning of the season farmers send via mobile money a certain amount of money (which would be a factor of how much land they were insuring). When the farmer sends the money, from a legal point of view this would constitute the contract offer. This insurance policy would then be verified by some agent that you have in the field to insure, for example, that the farmer actually has the land and has cultivated the crop. After field verification then your firm would respond with an SMS to the farmer that you have accepted his offer of the contract and that the contract is deployed. Once the contract is deployed the humans get out of the way.
Over the course of the term of the contract, the smart contract would be given permission to speak to a national weather service data feed that aggregates rainfall data in the farmer’s area (and presumably other areas as well). Upon the expiry of the contract term (which would likely be structured to be around harvest time), the smart contract would pay out in an inverse relationship to the amount of rain which actually fell and would rely upon the government’s national weather service for it to know what that amount of rainfall was.
Other real world questions which could be used by virtual automatic contracts by linking to data feeds would include some of the following: did you ship the item(s) – verified by a UPS feed? Did you build the web site – verified by a Travis or Jenkins build result? These would be more specific in nature than general data feeds such as weather data but for the most part they could be used in certain situations. For example, where the contracting party that was seeking to outsource some specific portion of a web application or coding project to a contractor built tests for that and wrote the contract such that the coder was paid automatically upon the Travis or Jenkins build passing the specs – that would work. However, this would not always work. For example, if the contracting party did not have the time or ability to write the specs and was looking to outsource the build of the specs along with the build of the feature then it is unlikely that building a Travis or Jenkins build feed into the virtual automatic contract would be wise.
Data can be a powerful tool for understanding some real world events. Primarily data feeds should be used where you need high level, aggregated information which applies generally to a specific group of people (based on age, class, location, profession, etc.) but not to specific people. Also data feeds as IRL linkages for virtual automatic contracts will be important where you also want to tap into a specific type of event but not to specific events. The basic idea of when you would want to build a virtual automatic contract to link to data feeds is when you want to zoom out from the specifics of the people, parties, and events that the contract may interact with. Data obviously won’t work if you need to “zoom in” or if you cannot get at the data (like the amount of potholes that currently exist in Hargeisa…we are making great strides at getting at data but we still have a long way to go and even in big countries there are still zillions of data feeds which are not fully developed and leverage-able.).
IRL Paradigm Linkage 2 - Referees
When you do not have a data feed to rely upon, or when you need to look at the deeper specifics of people or events, then you will need some human involvement in the smart contract. I am hesitating to call these judges or arbitrators because I think the role of these humans would be slightly different in the sense that what this post is about is figuring out whether a real world event occurred or did not occur. It is a bit pedantic to say I don’t like the term judges or arbitrators here, but I think that what we are looking at here is different in form and function. Really what we want the referees to look at is providing a binary answer to a relatively simple question which computers cannot answer.
The questions which a referee could be used would include some of the following. Did you make the web application to the correct style specification? Did the product you shipped meet the quality specifications built into the contract? These things could not easily be determined using data feeds. Did you actually plant the crops in the field that you have sought to insure?
There are three main considerations which I would recommend drafters build into virtual automatic contracts when utilizing referees to verify IRL events. First, the question which the referee needs to answer should be binary in nature. Second, the question which the referee needs to answer should be verifiable in nature. Third, the question which the referee needs to answer should be objective and party neutral. Let’s take a look at each of these.
First, the question should be binary. Did event Z occur? Yes or no. Sometimes this is tricky to determine and will require specialists to answer (such as does this drug meet the stated chemical specifications or does this widget meet the design specifications from this CAD drawing); sometimes, however, the question will not require specialists to answer. Whether specialists need to be involved or not will depend on the subject matter of the contract. Either way, the question which the referees need to answer should be structured so that it is binary in nature. So the contract should be structured such that the answer is yes or no, not a list or an essay which will be difficult for a computer to parse. Additionally if the question can be structured in a binary way, then experts from any language base could easily be utilized to answer the question (for the most part) and so you would have the entire world upon which to draw referees from.
Second, the question should be verifiable. Why trust one referee with determining whether an event has occurred when you could trust 3 out of 5 or 51 out of 100 or whatever threshold the parties agreed upon. If the questions could be structured in a way which the task could be uploaded to a microtasking platform such as Amazon’s Mechanical Turk then you could easily have the questions be verified by multiple referees to ensure that one referee does not either have a bias or simply made a mistake and pressed Yes when they meant No. This would require structuring the terms of the contract in a specific way. For example, to verify that crops were planted, one could require a geotagged photo from a smart phone uploaded to the insurers site. The site could use computers to match the geotag on the photo with property records with the application for the insurance. As long as the geolocation data from those three match (within some allocable error range) then go to the next step of verifying that crops were planted. The photo which has verified its location data could then be sent to the microtasking platform with the question: Were crops planted in this field? If 3 of 5 respondents say that crops were planted there then the insurer would accept the offer from the insuree and the insurance contract would be deployed. It is up to the drafter to work with the parties to build the questions in such a way that they can be verified by multiple referees which will reduce the uncertainty and also the claims of bias by the referees.
Third, the question should be objective. I see a lot of contracts; mostly I review contracts developed by other parties since for the most part my clients either have global templates or are Somali businesses who are given proposed contracts by larger entities. One of the things that always strikes me about many contracts is how much subjectivity is in contracts. This is fine for some types of contracts (see below) but when it is possible to reformulate a specific verification to be objective and party neutral that would be advantageous. When I say party neutral I mean to say that whenever possible the parties should not be mentioned and the question which is sent to the referees should be focused on IRL events. So rather than ask the question like, Did party A do X? it would be advantageous to ask the question like, Did Z occur? There could be a difference in X event and Z event from the above two questions, but this will be one of the tricks in very good virtual automatic contracts and not so good virtual automatic contracts.
IRL Paradigm Linkage 3 - Trust || Subjective Verification
One of the overarching factors of the cryptocurrency space is to explicitly disallow trust. However, for many contracts trust is unavoidable. Trust and subjective verification are substantially the same thing. When I order something online I am entering a contract which has trust and subjective verification at its core. I pay the online merchant trusting that they will ship me the item and the online merchant trusts that I will not send it back to me for a stupid reason. We both subjectively verify that the two primary events have occurred (payment, and sending of the proper item).
Subjective verification and trust have one significant advantage over the above to non-trust related IRL linkages: they are efficient. It will be easy, but for the foreseeable future not an extremely simple engineering feat, to link data feeds with smart contracts or referee networks. However, it will always be easier to build a subjective verification into a contract. Yet, this will require the parties to trust one another.
Although the cryptocurrency community tends to not “like” trust so much, as a lawyer there appear to be some advantages to building subjectivity and trust into a contract. In particular, there are advantages when the parties are entering into a long term contract and where the parties want to be able to trust one another. For example, I would likely build employment contracts for high level individuals with a trust and subjective verification clauses for some portion of the contract and then objective data feeds for other parts of the contract. In these types of contracts the parties want to be able to trust one another. The Board wants to be able to trust its officers and the officers want to be able to trust the Board. The tricky part will be determining what the conditions are which would allow the contract to trigger different clauses that are more objective in nature or would allow for a termination of the contract (which is a subject for a different post I’m working on). Obviously these triggers would be very different depending on the type of virtual automatic contract which the lawyer|coder was building, but it is likely that if you want to have a functional virtual automatic contract with some efficient elements of subjectivity within the contract that you build some triggers which one or both of the parties can utilize to turn to a more objective mechanism for determining whether an event occurred.
All in all, it will not be simple to link real world events to virtual automatic contracts, but these three mechanisms would provide the basis on which to build. What am I leaving out? Are there other paradigms that you find that could work?
~ # ~