Reinventing: Blockchain

Title & Escrow

ReinventingTitle-Escrow-1
This article originally appeared in HuffPost on 11/08/2017.

Blockchain has the potential to reinvent the business of traditionally ‘offline’ Contractual Agreements, such as an Escrow Agreement, but could be used for contracts of all sizes as well.

In this post, I begin to explore how Blockchain can and will lead to a truly secure, distributed way in which to enter a traditionally offline agreement, or contract. While standard legalese, notaries and the courts backing those agreements up with law indeed do offer a strength only the law can hold, they are not always efficient or even realistic to defend in the case of a default. In essence, sometimes contracts in the traditional sense, provide a false sense of security because you need to be able to defend them if they are broken.

Now, in a similar fashion to the concept of an escrow service where parameters are met before payment is distributed, the blockchain and Smart Contracts can be used to hold terms and resulting actions to be taken if terms are met. Using a concept known as ‘oracles,' any information that can be verified by a human, can become part of the Merkle Tree used to establish the authenticity of the agreement in question. This data could be collected manually, or obtained using a data feed from an API of some sort.

So, instead of getting lost in the technical weeds in this post, I want to play out a fun real-world example of how this could work, and then end by looking at Zen Protocol, a Blockchain startup working to achieve this idea. Let's take a look at a real world everyday example of how Blockchain, Smart Contracts, and Oracles could be put into play.

*A Simple Everyday Business Escrow Contract Scenario using blockchain. *

The Deal: Sacha and Henry have arrived in San Francisco to attend Burning Man. But, before they do, they are meeting Jen, a software engineer who claims she can build their new web app and get it launched on the App store by the time they return from Burning Man. They agree the app will work open without crashing and will allow a user to quickly share their location with anyone via an email message containing a map link.

The Price: They agree on a price of $15,000 for the complexity and rush service and agree to pay Jen in BTC, 50% now, and 50% upon verification that the app is in the App store. They also agree on a Smart Contract transaction fee that will be paid to 7 Oracles, each agreed to by Jen, Sacha and Henry based other reputation of providing accurate data.

The Risk: As with any contract, both parties are taking a risk. Sacha and Henry are risking that Jen will run off (perhaps to to Burning Man as well) and not develop the app, and Jen is risking that after she builds and launches the app that Sacha and Henry will pay the remaining 50% like they said they would. This is where the concept of Escrow comes in, and why it is often used in larger transactions, such as for a down payment on a home. However, it can be used for smaller, yet still meaningful transactions as well.

The Contract: Blockchain Smart Contracts and Oracles act like Escrow. A Blockchain Smart Contract can ensure that the funds being represented exist, and sound an alarm if they ever were to disappear mid-project. In this example, Jen can know Sacha and Henry have the BTC to pay her once she launches the app, she doesn’t just have to take their word for it.
Delivery: The fateful day comes, and Sacha and Henry return from Burning Man and search the app store for their app. They find it, and download it! Jen did a great job, and it does what they wanted. It seems to download, but won't launch. Oh no! They let Jen know that before they can pay her, that has to be fixed.

Jen tests it, and it doesn’t happen to her, the App works fine every time and its the same on three of her friends' phones. She lets Sacha and Henry know that it must be their device they just brought to the dessert. They disagree, won't try to test on a different device, and refuse payment until it works on their phone. Difficult clients indeed.

Here we are, the moment where the contract becomes everything. Did you do what you said you would, and if so, what are you owed? If not, what must you do to satisfy the contract? This is where we traditionally begin to engage in long drawn out emails, and perhaps even lawyers, and courtrooms. However, using Blockchain, Smart Contracts, and Oracles, we can use other peers on the network to confirm whether or not a contract’s terms were met. In this case, is the app visible on the App Store, and does it run.

Contract Execution: Jen is confident that she performed the work correctly, and submits the smart contract for review. If the oracles find that the app downloads and runs, they will execute the contract and her remaining 50% of BTC will be released. If they don’t, it will not execute, and will remain open, not paying out her remaining 50%.

Dispute Resolution: All 7 oracles attached to the Smart Contract report back data resulting in an accurate execution and Jen is Paid. Sacha and Henry need to get a new phone, or at least be willing to try on a different device.
In the alternate scenario, where all 7 Oracles agree on the fact that the app won't load, Jem is left to deal with the fact that she needs to rework her code before she will be paid. You might ask, what if all Oracles don’t agree the app works? Thats a good question, and brings into play Blockchain’s “Multi signature” property, sometimes called M-of-N. Again, will link to explain technical details in order to keep these articles high level, but essentially, they allow for the there to be more than one person required to execute the Smart Contract. In my example here, this person could be a notary public Sacha, Henry and Jen agreed on, who agrees that if more than half the oracles agree the app works, that they will also digitally sign the agreement, adding an extra layer of neutrality and security to the contract for both parties.

Conclusion: All of this verification was done in a secure, affordable, and distributed in a peer to peer network, instead do relying on a centralized authority like an escrow firm, or a court to decide what happened.

You can imagine that, for example, using a data feed, such as for whether a stock price hit a certain price, the job of an Oracle can become even more efficient, handled programmatically, and realistic for millions of financial transactions.

By creating a platform where peers can validate for other peers, we all become the trusting governing body for everyone, instead of placing this responsibility on one central entity.

A note on trusting Oracles: It’s an important thing to note, is that the people reporting the data, the Oracles, depend on their data being accurate to survive. This inherently provides protection against fake data being used to falsify the Merkle Root. While this isn’t 100% failsafe, it is very similar to the Proof of Work concept where producing invalid, falsified work only hurts the overall chances of any given miner, and it wouldn’t make sense to falsify data if one wanted to have any longevity as an oracle.
Enter, Zen Protocol.

Zen Protocol is a great example of a Blockchain startup working to realize the technology needed to make the above example possible, essentially offering a solution for decentralized, automated escrow.

The team has created a viable, decentralized, Oracle system, meaning the smart contracts can operate on things which happen in the real world - the most important thing missing from smart contracts. But also, in addressing one of the main issues with Smart Contracts, they have created proprietary technology to ensure contracts are bug-free before they are agreed to. There is nothing worse than a contract that won't run when you need it to. That’s akin to not being able to produce the contract at all in a court of law, you might as well not have it. Their F* language demonstrates contracts they are free of errors and security vulnerabilities.