CodeLegit Conducts First Blockchain-based Smart Contract Arbitration Proceeding

No, code is not law. We discussed that before. But, code is used everywhere and somehow it must allude to law. But how, given that no software is bug-free? With our Datarella project CodeLegit, we have been working on a solution bridging the gap between code and law: Today we announce the successful conduct of the worldwide first arbitration proceeding using Smart Contracts on a Blockchain.

For this showcase we used a very simple setting: Two parties agree on doing business that is defined in a Smart Contract. This Smart Contract includes our Arbitration Library. In parallel, both parties conclude a legal contract which includes a arbitration clause referencing the Blockchain Arbitration Rules.

Arbitration Library
Our Smart Contract Arbitration Library allows to pause, resume, modify and end a Smart Contract. Additionally, the Arbitration Library connects the software with human beings acting as Arbitrators. Most of the process is automated, which maximizes the efficiency of a dispute.
Blockchain Arbitration Rules

The Blockchain Arbitration Rules are rules the parties have agreed upon in their legal contract. They shall apply in case of a dispute. Those rules are based on the UNCITRAL Arbitration Rules and have been developed by us in cooperation with IT lawyer and Blockchain expert Dr. Markus Kaulartz. The advantages of the rules are, on one hand, speed, because they are tailored to working together with the Arbitration Library and all communication is done via e-mail or any other form of electronic communication and secured via hashes written in the Bitcoin and the public Ethereum Blockchain. On the other hand, the Blockchain Arbitration Rules shall attract arbitrators who are specialists both in legal and technical questions.

Mock arbitral proceeding
In our example, one party which considers the other party to be in a breach of the legal contract pauses the execution of the Smart Contract by triggering a function pauseAndSendToArbitrator in the Arbitration Library. This function automatically notifies a so-called Appointing Authority defined in the Blockchain Arbitration Rules. The Appointing Authority then proposes an Arbitrator who reviews the statements of claim and defence, decides upon the case and finally delivers his arbiter award to the parties. According to the award, the Appointing Authority either resumes the Smart Contract, modifies its execution or ends it permanently, depending on the resolution. The arbitrator is paid with funds available in the Smart Contract in dispute.
Advantages

The integration of decisions by human beings – the arbitration, known from the offline world – transforms a false performance based on an erroneous piece of software – the Smart Contract – into a legally correct performance. At the same time, this kind of arbitration preserves all the advantages of Smart Contracts, because a dispute does not have to be brought before a state court, but can be solved by an expert arbitrator by modifying the performance.

With this arbitration solution, CodeLegit demonstrates a feasible way how to reach compliance in case of erroneous software (do not forget: the more complex software is, the more bugs it contains). The next step will be to implement this solution into industrial Blockchain environments in order to establish the CodeLegit Arbitration Library on a broad basis in the technical compliance sphere.

You can only win by including the Arbitration Library and the Arbitration Rules, because both only apply in case of a dispute, and you will be glad having used them, avoiding going to a state court, but having reached a decision in accordance with applicable laws and through a legitimated court. Give our regards to TheDAO…

CodeLegit Blockchain Arbitration White Paper

The State Of The Initial Coin Offering ICO

In our upcoming Ethereum Meetup we will discuss one of the hottest topics you can read about in the tech space: Initial Coin Offerings ICO, sometimes referred to as Initial Token Offerings ITOs or, more simply, as Token Sales.

In June 2017, blockchain project teams have raised more money through ICOs than through traditional venture capital firms. Has one of the key aspects of applied blockchains – the elimination of the middle-man – unexpectedly come upon the venture capital industry?

It might be too early to confirm this assumption but some VCs have supposedly decided not to wait any longer but to start using ICOs as an instrument to leverage their traditional businesses. Over at CrowdstartCapital, we have compiled a list of the world’s largest ICOs.

Jamie Burke, Dr. Nina Luise Siedler, Dr. Markus Kaulartz

In our meetup, we will approach the ICO from different perspectives, trying to get hold of this phenomenon:

  • Is an ICO the right moneyraising tool for your project?
  • What are the pitfalls of an ICO?

We are very happy to have one of the most prolific experts in the field of blockchain investing to present his perspective on ICOs: Jamie Burke, Founder and CEO of Outlier Ventures and Convergence VC. Jamie and bis team have analysed over 1,000 blockchain-related startups. He is quite critical when it comes to ICOs, That’s the reason we are very much looking forward to meeting Jamie on 25 July.

Right after Jamie introduced us to the actual ICO sphere, we are happy to have Dr. Nina Luise Siedler and Dr. Markus Kaulartz with their interactive take on the legal aspects of ICOs. Everybody has heard of Bitcoin and other crypographic coins or tokens, and most of us know what those are from a technical perspective. Markus and Nina will go beyond that and will explain what tokens are under applicable laws. They will give some practical insights to explain that there are different kinds of tokens which can be used for various business purposes. Depending on the kind of token, different regulatory frameworks apply to ICOs. Markus and Nina will share insights of what companies have to consider when running their own ICO.

We are very much looking forward to having exciting discussions! See you at our partner Deloitte’s  Munich offices on July, 25!

Medication Plans on The Blockchain – Building a Decentralised Application in Healthcare

The theme of this post is easily generalised to other use cases and serves as an example of how blockchain technology can shift power and trust in a well-established system, in this case the one of health care.

TL;DR

Medical prescriptions should be unified and digitalised. They should be resilient and controlled by the real owner of the prescription (and thus of the personal data). This can be achieved by a blockchain-based solution. A system of smart contracts in Solidity is proposed which achieves this and furthermore is modular and update-able. Some general advice on designing a blockchain solution is given.

What’s the problem?

How many of you know what iatrogenic illness means? I confess that prior to writing my Master thesis upon which this post is based, I also had no idea. So, to not keep you waiting, here’s the definition from Merriam-Webster:

ioatrogenic: induced inadvertently by a physician or surgeon or by medical treatment or diagnostic procedures

from the Greek word for physician (iatros). Add an illness to that and you have an illness caused by a physician. Now, it sounds like an oxymoron, but it is in fact more common than we would of course like to be. You can divide the causes for iatrogenic illness into so-called Adverse Drug Events (ADE) and, to be completely MECE*, other reasons. Other reasons would include things such as rough examinations, surgical errors (there’s a reason they draw arrows on the limb to be amputated) and so on. ADE includes all injuries or complications caused be medication, be it the wrong medication, drugs interacting in unintended ways and so on. [1] ADE has shown to be the most common cause of injury to hospitalised patients, and furthermore, the most preventable one.

Where is the problem coming from?

In fact, computer-based prescribing systems have been shown to decrease medication errors by 55% to 80% in a study from 2004. [2] It does not, however guarantee that the most severe of those medication errors are prevented by the usage of an IT solution. Among ADE’s, the most common form of avoidable medication errors are prescribing errors (i.e. an error made somewhere in the process of getting a drug to a patient). There is a list of sixteen classes of these prescribing errors, but basically they boil down to:

  • Knowledge deficiencies – among doctors, patients or pharmacist about drugs, other parties, et c.
  • Mistakes or memory lapses – e.g. a patient forgets what medication he/she is already on
  • Name-related errors – complicated-sounding substance gets mistaken for other complicated-sounding substance
  • Transferring errors – information is missing or incorrect once the order arrives at the pharmacist
  • ID checks – patient, doctor or pharmacist ID isn’t properly verified
  • Illegible handwriting (!)
  • Wrong type of document filled out

These errors all illustrate why prescribing errors are so common, but also why they should, to a large extent, be avoidable. [3] The thing is that, considering the current rate of prescribing errors causing damage or danger to patients being relatively low (ca. 2% [2]), its importance is overshadowed by more clinical research in medicine and is thus being overlooked by the research community and public in general. One reason for this could be the wide-ranging competencies required to implement a system for decreasing the rate of prescribing errors to zero. To do such a thing, one would require technical expertise within security and privacy as well as all the various skills for application development, one would also require medical and pharmacological knowledge, and essentially, one would need to have experience within information systems management.

A step in the right (digital) direction

To combat prescribing errors, many public health systems require or recommend that patients with more than three different prescribed medications have a unified medication plan which should theoretically contain all prescriptions. The effectiveness and quality of medication plans was examined in 2015 by a group of German researchers. The results were scary. 6.5% of all medication plans examined did not contain discrepancies! Where discrepancies means differences in drug names, additional or missing drugs, deviations in dosage, et c. In spite of this, or perhaps to improve the quality of medication plans, a law was passed in Germany three months after the publication of the medication plan review, which makes it mandatory for all patients with three or more medications to have a medication plan. In order to cope with the slowness of technology adoption in healthcare, up until January 2018, there is no requirement that the medication plans should be digital. Thereafter they should be available on an electronic health card (eGK). [4]

Considering the different types of prescribing errors we’ve identified, it is not difficult to translate those into some type of requirements for a system to solve those errors. The resulting requirements happen to fit very well to a blockchain system with smart contracts, therefore we’ll propose a design of a system of smart contracts to function as medication plan. Let’s look at the errors one by one and explain which requirements fit to them:

Knowledge deficiencies

To resolve this error, data regarding patients and their medications needs to be unified, available and guaranteed correct. There shouldn’t be multiple versions with equal or uncertain amounts of validity. Additionally, there should be little chance of the data getting lost or not available when it is needed.

Mistakes or memory lapses

It is completely human and expectable that a patient taking many different medication can’t remember the details of complicated names of each substance. This can be solved, however, by the unification of medication plans and assurance that all prescriptions are correct and active.

Name-related errors

See point Knowledge deficiencies.

Transferring errors

Through the unification of the various systems available currently, the process of transferring prescriptions would be simplified.

ID checks

Through the digitalisation and implementation of a permissions management system patients would only need some type of identification (could be biometric) to collect their medication.

Illegible handwriting

Assuming the doctor enters the prescription into a digital system and doesn’t write with pen and paper, this problem is practically eliminated.

Wrong type of document filled out

Again, through the unification of the different possibilities to prescribe a medication, there would be no such things as the wrong type of document. At least not inside the system.

Design choices in the solution

So what are the technical details one needs to consider when designing a blockchain-based system for a medication plan? I’ll describe the three most important design choices in this blog post. The three questions are:

  • Who needs to participate in the network?

In this case, the only users are doctors, patients and pharmacies. So to not take on additional risk regarding data exposure, only those who are on-boarded and verified through some separate process should be allowed to participate in the network. There are however some negative aspects of choosing a private or permissioned blockchain, one point being that there might not be enough active nodes to keep the consensus building at an acceptable fault-tolerance level at all times. This can be solve by some type of incentive or requirement that for example doctors keep a running node at all times. Another risk of running a private blockchain is that, when the amount of nodes isn’t very large, and the users consists of a specific group of people (such as doctors in Germany), then the risk of collusion becomes considerable. To combat this, the consensus-making should be well-spread geographically and demographically.

  • What data and functions need to be on the blockchain and what should definitely not be there?

In the case of a medication plan, the data which is required to be on the blockchain consists of three parts; user IDs, prescriptions and doctor/pharmacy permissions to prescribe/sell medications. Naturally, we can’t have plaintext information about patients and their prescriptions, even if it is a private network. Therefore, IDs are formed from a public/private key-pair (similar to bitcoin or ethereum), which should be generated by the user, on a user device. Prescriptions are only ever published on the blockchain as hashes, because even though the users theoretically are anonymous, it has been shown that Bitcoin transactions can be traced back to a person. [5] The permissions of doctors and pharmacies also need to be stored on the blockchain, in a smart contract to ensure that they aren’t manipulated or somehow overruled. Including permissions and sensitive data in smart contract means that extreme caution needs to be taken when programming them, to ensure that no syntactic or logical mistakes are made. The functionality needed on the blockchain is basically complimentary to the data pieces, getters and setters. But additionally, permissions needs to be handled on-chain.

    • How should the smart contracts be written?

There are relatively few resources by experienced smart contracts developers on best practices for building smart contracts, but mostly the general advice for writing good code (failing loudly and as early as possible, commenting, etc.) should be followed. There is however, so much to say about specific smart contract programming that it will be more explained in another blog post. Here, I’ll just talk about architecture of the system of smart contracts briefly.

In order to be able to keep an overview of the smart contracts and functionality used in the application, they should be as small and simple as possible, thus facilitating analysis. Ok, so say that you have a fairly complicated (not in a computational way) functionality to begin with, then you separate it into multiple smart contracts and end up with maybe five to ten of them. How are you supposed to keep track of them and increase the modularity of you system? Enter the contract managing contract. [6] It is basically a contract to keep track of (and manage) the different contracts in your system, it logs the addresses and names of each separate contract and provides another contract, the endpoint of the user-facing application, with the possibility to access them.

Conclusion

Designing an application for managing sensitive personal information needs to be resistant to failure, privacy-preserving and provide accountability so that any changes to the information can be traced. A very relevant use case for such an application is a medication plan. A suitable system for building the application back-end, is a blockchain-based system of smart contracts. Smart contracts programming is a fairly new phenomenon and is based on decentralisation, therefore much thought should be given to how such a system should be designed. A possible solution was drafted above.

*MECE stands for Mutually Exclusive, Collectively Exhaustive

References

1. Tierney LM. Iatrogenic Illness. Western Journal of Medicine. 1989;151(5):536-541.
2. The Epidemiology of Prescribing Errors, The Potential Impact of Computerized Prescriber Order Entry. Anne Bobb; Kristine Gleason; Marla Husch; et al, Arch Intern Med. 2004;164(7):785-792. doi:10.1001/archinte.164.7.785
3. Prescription errors in the National Health Services, time to change practice,
Hamid, Harper and Cushley et al., Scottish Medical Journal. Vol 61, issue 1, pp. 1-6. 21.04.2016
4. Full legal text available at: http://www.bgbl.de/xaver/bgbl/start.xav?startbk=Bundesanzeiger_BGBl&jumpTo=bgbl115s2408.pdf
5. Deanonymisation of Clients in Bitcoin P2P Network. Alex Biryukov, Dmitry Khovratovic, Ivan Pustogarov. Proceeding
CCS ’14, Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, Pages 15-29, November 03 – 07, 2014
6. Monax – Solidity tutorials, https://monax.io/docs/solidity/solidity_1_the_five_types_model/, Accessed on 15/05/2017.

Building Blocks – How the World Food Programme is harnessing Blockchain technology to deliver humanitarian assistance

What started with a Proof-of-Concept in Pakistan in early January this year, has been transformed in a fully functional Blockchain pilot being rolled out in Jordan in May, 2017. The Building Blocks project not only demonstrates the power and the impact of blockchain technology and its potential to enhance the lives of millions  but it is proof of the technology’s potential for efficiency gains for a humanitarian agency, such as WFP.

Based on the early, however robust prototype field tested in Pakistan, the Building Blocks pilot in Jordan now serves thousands of households in a Jordanian refugee camp Tazweed village. The inhabitants receive food vouchers that can be used in the village’s supermarket. The seamless integration of the existing iris scan identification technology into Building Blocks system allows the  existing processes to stay in place without any need for changes for the beneficiaries,  the supermarket nor WFP personnel. The only visible differences are a higher transparency of aid accounts for beneficiaries and easier bookkeeping for supermarket managers. The biggest, however invisible, advantage is a minimized risk of fraud or data mismanagement.

The economic benefits of harnessing Blockchain technology can amount to several million US-Dollars for the Jordanien refugee camp population, alone. The goal of the Building Blocks pilot is to demonstrate a fully-functional Blockchain solution that can serve as a role model and architecture for similar humanitarian projects worldwide and a base to develop other use cases.

The Datarella team wants to thank the WFP team, the IrisGuard team and our partners over at Parity Technologies for the great cooperation: from the beginning, we felt being one big team with everybody helping the others out when they needed it. Other than with this collaborative effort a project like Building Blocks would not have succeeded: Blockchain technology still is in its infancy and basic conditions in the field have proven to be challenging. Again: thank you very much for the opportunity to demonstrate the power and the real impact of Blockchain.

If you are interested in the Building Blocks project you might consider visiting our Ethereum Meetup on May, 16 .Here we will present more details and especially share our experiences gained in Tazweed village, Jordan

Find some more information on Coindesk or you contact us directly.

Foto by Houman Haddad, WFP:  Opening scene, 1 May, 9:00 am, in the Tazweed Village supermarket, Jordan

The biggest thing in tech 2015-2025?

From time to time we contemplate about which developments, movements or innovations are those that really matter, and that make this frequently mentioned difference. The results of these intellectual games must be subjective and are generated from a uniquely individual perspective. Things get fascinating, though, if you’re convinced that a specific development not only qualifies as your personal No 1 but should be on many people’s A-list. 

Speaking of technology, my personal No 1 which back in 2009 was ‚Apps’, since 2015 is „Blockchain“. Beside developments such as VR and AR that certainly will honour their promises, the blockchain will fundamentally change the way we use the internet. You can regard it as a layer on top of the internet which allows a completely different approach to transactions – i.e. the end-user perspective – and supply chains – i.e. B2B perspective.

Without summing up and repeating all aspects of a blockchain, let’s focus on just one aspect (which, by the way, is the only reason for using  a blockchain, anyway) – the automated consensus made possible by smart contracts. A smart contract is an algorithm defining and executing a set of rules, i.e. without an additional notary service deciding upon whether all contracting parties comply with all rules. Now, without knowing the technical details behind smart contracts, just ask yourself: how many manually executed processes immediately pop up in your mind that could be substituted by an automated process that minimizes time and costs.

VR and AR have been around for years now. Many companies have been founded, many have been shut down. From my perspective, both, AI and AR, need new use cases and new hardware  to demonstrate their raisons d’être. That’s why it takes so long until they can really demonstrate their added value.

Don’t get me wrong – I can see the sexiness of many VR and AR prototypes. But, still, our world is heading towards automated processes; i.e. automatisations of already existing processes. And here the blockchain comes into play: it’s the great enabler of this global development. That’s why I hereby submit that in 2025, the blockchain will be regarded as the biggest development in technology of the last 10 years.

Comments?

PS: This posts reflects my personal view which is not necessarily congruent with the Datarella team member’s