With our project Crowdstart Capital (CSC) we seek to support the developer community and the blockchain ecosystem at-large. This document seeks to clarify specifically what these terms mean as well as outline several options for supporting our goals in this area. First, we define the target audience:
Developer Community: We define the developer community broadly including:
Active professional developers
Computer science and university STEM students
Potential future developers
Open source software development organizations
Blockchain Ecosystem: This term refers to various blockchain technologies as well as all the technologies that support and connect these projects. Here we are using the word blockchain as a catch-all for all distributed ledger technologies including block-less tech such as the IOTA Tangle:
Core Blockchain Protocols: i.e. Ethereum, Monero, Neo, Qtum, Polkadot
Selected dApps (decentralized applications)
Supporting and connecting technologies: Atomic swaps,
multisig, hardware and lite wallets, governance protocols, etc.
Alternative protocols directed at a specific segment, such as IOTA for IoT
Exchange and liquidity services
CSC = Crowdstart Capital, a brand of Datarella GmbH, Munich
XSC = Tokens, originally provided by Crowdstart Capital
After having defined the target audience, we will create the incentive scheme in three consecutive steps:
Phase 1 – Initial Token Distribution
In the first phase, we will distribute tokens to developers at conferences, events and hackathons. This activity will occur primarily in Europe and the distribution will be at the discretion of CSC. The goal of this phase is to get tokens into the hand of active developers and blockchain early adopters/enthusiasts.
Potential Venues for XSC Distribution
In all of these contexts, different amounts of tokens will be made available for various levels of community participation. A wide variety of people will be rewarded for their community participation. Some types of participation could be more highly valued than others. The winners of a competition for building a new type of dApps at a hackathon might receive significantly more XSC than the bulk of the participants. However, the idea is that most types of contribution should result in earning some XSC tokens.
Exemplary reasons for being awarded tokens
Prizes for the winners of hackathon events
Honorarium for development event speakers
Bonus for event participants
Bonus for webinar participants
Bonus for participants travelling long distances to attend events
In order to collect tokens at, for example, an event, all you need is to have an Ethereum wallet which supports ERC20 tokens. During events, we will collect the relevant public keys and distribute tokens live to the participants. After that, participants can trade or hold their tokens or use them to purchase discounted consulting services from CSC. For more information on using XSC tokens to purchase discounted consulting services, please see http://crowdstart.capital.
During Phase 1, tokens may also be awarded outside of events to reward individual contributions to the overall blockchain community. The point here is to get tokens into a wide variety of people’s hands and incentivize participation in building the local development community.
Phase 2 – Smart-Contract-Based Token Distribution
Developers committing code to key blockchain projects can opt-in to receive XSC tokens for every line of code that is accepted for their respective projects. CSC will set up a smart-contract-based system that will pay out tokens according to the accepted commits. CSC will programmatically monitor the git repos of major projects.
Developers sign up on our website with their GitHub username and a public key for an Ethereum wallet. In order to ensure that those people actually doing the development work are also the people who get the token rewards, developers will also have to post their public key in their public GitHub profile.
Once registered, developers just need to do what they do best: Code! For every line of code accepted to one of our registered and monitored projects within the blockchain ecosystem, CSC will transfer tokens to the author of the code. CSC also reserves the right to transfer bonus tokens to developers who solve particularly pressing bugs or issues or who contribute significantly to certain features.
Additional Actions Earning Tokens
Referrals: Developers who refer other developers to the incentive program
Commits to documentation/wikis
How-to’s or blog posts associated with official project documentation
The exact number of tokens that each action will earn is not determined exactly, yet. Project code will likely be rewarded with more tokens than pure documentation for example, but all accepted commits are eligible for earning tokens. Obviously, good documentation and stability of key blockchain projects needs to be improved in order to bring the blockchain ecosystem closer to enterprise-readiness.
CSC will start with providing incentives for development of Ethereum because it is the biggest and most widely accepted blockchain with a Turing-complete programming language. This said, it is also under-documented and could definitely use further support in order to progress and become an enterprise-ready solution. The second blockchain project whose development will be awarded with XSC tokens is IOTA, because of its assumed aptitude for IoT-related projects.
In Phase 3, CSC will incorporate a mechanism for electing new projects to be supported. This mechanism will be based on a liquid feedback model enabling a contemporary scalable, decentralized decision making.
Phase 3 – Liquid Feedback Mechanism
In the third phase, members of the community will be able to suggest projects to be included in the incentive scheme, a model known as liquid feedback. Token-based ballots will be used to enable community voting and determine which blockchain projects should be included.
In this phase, we’ll also be rewarding developers to contribute to our code base. Essentially, over the course of the three phases of the incentive program it should morph from being a mostly manual process to a fully automated process.
One essential part of this phase is that developers will be incentivized heavily to build the secondary smart contract which will continuously monitor the GitHub accounts for commits and facilitate voting.
The kick-off event for this blockchain ecosystem incentive scheme will be the IOTA Hackathon in Gdansk, Poland, 17-19 November, 2017. There, we will award IOTA developers XSC tokens for committing code to the main branch and for other valuable inputs. The IOTA hackathon provides the ideal event for the initial distribution of XSC since during this 2,5-day get-together the Crowdstart Capital team and the hackathoe’s participants can perfectly define and decide on the value of the inputs to the blockchain and, henceforth, on the amount of to-be-earbned XSC tokens.
This post by Joerg Blumtritt describes how blockchain technology supports decision making and voting mechanisms in processes called Liquid Democracy. These processes are the basis for Phase 3 of the CSC Blockchain Evolution Incentive Scheme.
Distributed consensus, realising consistency without central control, is one main achievement of the blockchain. From the beginning of the Internet revolution, there has been the discussion, whether our new forms of media and communication would lead to another revolution as well: a political one.
New forms of political participation are discussed, like Proxy-Voting or Liquid Democracy, which had been hardly conceivable without the infrastructure of the Web. However, all the digital forms of presenting, debating, and voting for policies all suffered from a serious flaw: Either there would be no secrecy of the vote, or the legitimacy of the ballot would not be accountable, due to the lack of provable uniqueness of transactions. The curse seemed to be either to vote in the open or make it impossible to decide if a person was indeed not voting multiple times.
Blockchain is built to heal this very problem, guaranteeing uniqueness of transactions even for totally anonymous participants. And Liquid Democracy, as I will discuss here, promises to deliver a versatile, efficient, and grassroots liberal form of decision making that complements the blockchain idea of consensus.
Politics today is often set equivalent to negotiating opinions in the parliaments, committees, or council. Representatives are given the mandate from the voters to represent their interests. Not everyone can be an expert in every field. To foster adequate decision making, lobbyism has become an integral part of the parliamentary system. First, this is industry associations and interest groups (the JICs, ethnic organisations, religious and cultural associations etc.) relaying their clients’ interests to the representatives by providing arguments. Furthermore there are those groups of experts that gather around certain topics, rather loosely connected compared with the industry associations. Those think-tanks are often initiated by politicians and are much less transparent regarding statutes or goals compared to the associations.
Liquid democracy> is a conceptual alternative to pork barrel politics and lobbyism. It is designed as a method for direct democracy, where voters not only ballot at the decisions but negotiate one with each other every step of forming a political opinion and building the “volonté générale”.
Liquid democracy is a form of proxy-voting. Participants have suffrage and are at the same time eligible, can thus better be called ‘actors’ than ‘voters’. Actors can issue initiatives for projects like laws, changes in laws, budget decisions, etc.
To start the process of decision making, actors formulate their proposal as a so called initiative. The initiative is uploaded to the decision making platform it to be reviewed and discussed. This step can be preceded by informal discussion going on before the actual upload. During this discussion-phase, the initiative’s author can still change the initiative and react to criticism and suggestions. After a fixed time span (the same for all initiatives on one topic), the initiative’s text is frozen and can no longer be changed. In this ‘frozen’-phase, the initiative has to gather support from other actors who openly and actively register as voters for this initiative. Also, alternatives to the initiative can be added to be decided at the same ballot. For each topic, there a quorum of minimum support can be set, and only initiatives which get above this threshold make it to the ballots.
All actors can delegate their vote to some other actor, who then may delegate her vote together with all votes delegated to her further on, thus forming chains of delegations. Delegation can be withdrawn and changed anytime until the deadline for the decision has passed.
Secrecy of the vote
Of course, if delegation is possible to anybody, it requires accountability who gets delegated how many votes. As soon as somebody passes on my delegation, I want to be sure about the possible consequences to have the possibility to decide to withdraw and re-delegate or vote to myself. Before the blockchain, it was at least debatable if computer-based voting systems in general should require full identification of the voters to the public to prevent fraud. With liquid democracy, however, it would become mandatory to disclose the identity of most voters. With the blockchain, it is finally possible to heal this. Delegations can be provably legitimate and transparent without requiring to vote fully in the open.
Presentation instead of representation
In more then 2000 years, from the beginning of the Greek democracy and the Roman republic, the representative system prevailed, in which people delegate their interests to someone to represent them. It is not necessarily the case that representative systems are also democratic but in our contemporary understanding, all democracies are representative, that is, the decision making is done indirectly and not directly. There are obviously hardly any examples of grassroots democracy that could be called a success, apart from a few counties in Switzerland. Is the ideology of representative democracy thus without alternative? Representation, the parliament, has a long list of advantages – from “not everybody can be expert for everything” to “not everybody can join every conversation” – a discussion of which would lead to far here, as would a criticism of representative democracy as such. Here we want to focus on liquid democracy as an alternative hypothesis to representation.
Communities exist by their members’ taking tasks, fulfil duties within the community, and participate in the successes that are communally achieved. In a society, citizens delegate parts of their tasks and duties to the state’s administration. Over the course of the last two hundred years, the citizens of the so called western world have handed over more and more of their very own responsibilities to the state – caring for the sick and elderly, birth and death, provisions for retirement, education and many more.
How these delegated tasks have to be carried out is fixed by the process of representative decision making that characterizes parliamentary democracy.
Elected representatives are assigned to taking care about this for a time of multiple years. That all these jobs can be done, experts have to be paid for and equipped with the necessary means of work. To control the adequate application of these means, finally an administration is needed to oversee it. It is not clear, how the carefully balanced system of checks and controls between administration and parliament would be affected by such a radical change in delegation that liquid democracy would propose. The promise, however is to take back responsibility into the hands of the people.
Direct democracy is usually just seen as plebiscite, that is to “give the decision to the polls”. Basically, the political work in this case is still done by the elected representatives. Proxy vote or the imperative mandate goes considerably farther by tying the votes to a definitive decision behavior of the parliamentarian representing their voters. Imperative mandates are usually bound to decisions of conventions of voters. A party conventions or a citizen councils decides by majority, and the delegatee has to represent this decision in parliament. Proxy voting however allows for every single person to delegate their vote to those who would represent their opinion in the session. All three forms, plebiscite, imperative mandate or proxy voting – as in the same way then the classic “conscience-bound mandate” of the most democratic election laws – assume that there is a group of people, homogeneous enough to be abstracted into one set and then represented by their member of parliament.
In liquid democracy there is no separation of suffrage and eligibility, because everyone can contribute and vote. Everybody presents themselves – and even if they would have delegated their vote to someone else, there is no abstraction of people to groups that are represented. Liquid democracy is a system of direct, non-representative democracy.
A complete presentation of everybody for themselves show of course the marks of Max Stirner’s anarchistic egoism. And communities that are organized in such a non-representative way, like e.g. Wikipedia, in fact well appear like you would imagine Stirner’s anarchy.
A logical outcome of such a non-representative system is also, to no longer distribute governmental transfer payments, subsidies or appropriations top-down, but allow every person the same access. It is thus only consequent that Piratenpartei takes the basic income guarantee as a programmatic goal.
Liquid democracy is often compared with Wikipedia – everybody can participate, all discussions are open. And by means of delegation, if someone would not see themselves as competent for the decision or be busy during the election process, the may trust their political decision to their delegate. This process of Wikipedia-decision making faces some sound criticism: people who cannot articulate themselves very well or who would have to fear that they become “talked into something” or shouted down in the discussion, will not even begin to take part. Everyone who became victim to one of Wikipedia’s deletion-discussions knows how this feels. But still, Wikipedia stands without doubt for one of the very big successes in collective collaboration in the Net. It may appear unbelievable, what was achieved by thousands of people together, without any monetary incentive – and continuously, Wikipedia is brought further, gets enhanced, and this despite the communication culture there is after all gruff, to say it moderately. Wikipedia’s culture nevertheless is not a good example for inclusion; the horrible gender-bias alone is telling.
A concept to soften this spiral of silence is to give the actors the option to perform under a self given name and identity. Since the blockchain can guarantee that every physical person would get only one vote, this ‘autonymity’, the freedom of flexible choice of name, has the advantage, that it is possible to articulate a particular opinion without sticking this permanently to the own personality. However the disadvantages of acting under pseudonym in a system like liquid democracy stand, as discussed above.
Another criticism aims at political reliability. Continuity and predictability are obviously a necessary part of representative systems. The members of parliament represent their mandators only indirectly. For showing to their voters, that their intended politics would be dutifully represented, they have to stay constant and reliable in a few striking aspects, while their motives for most of their decisions would remain undisclosed to their voters. Whip and fidelity to the coalition are the well known consequences – not really in the very sense of our constitution that would see the the decision behavior only bound to the conscience. Since there is hardly any empirical data on Liquid Democracy, it is for now totally unclear, how stable and continuous the policies would be that the liquid decision making process would support.
Consensus instead of compromise
Liquid democracy means everyone is able to contribute, and consensus is to be build above the suggestions. Consensus does not mean majority. A majority overrules those who do not share the opinion – after the ballot, the set of voters will be regarded as homogeneous regarding the decision in question. For the daily party business this means: once a party committee has made its decision, all members have to stand behind this (at least this is expected from the party members).
In a non-representative, direct democracy, having unity behind the majority is not the point, since every opinion remains valid and cannot be overruled. Thus it is especially important to concentrate on finding consensus on the crucial topics. Consensus means to really stand behind the decision and not just be outvoted. So we could call consensus in politics as “agreement on the truth” in opposition to “deciding on opinions”.
The struggle for truth leads, as mentioned above, immediately to a rather gruff tone in the debates. Those inferior with arguments frequently take their last stand: the “Shitstorm”, usually a ranting against decisions or actions without arguments – completely convinced to be right and full of anger, not getting right. Other then the compromise which is closed between the two sides engaged – often formalized as in a coalition agreement – consensus is not fixed and not binding. Like in Wikipedia where existing texts are always open to edition, and where the authors continuously have to defend their words if they would like these to remain, the consensus in liquid democracy can always be left, and an initiative for change be placed. Frequently, so called trolls appear in the course of decision making in liquid democracy – people insisting on certain topics in a very destructive way. As inconvenient such arguing with trolls is, it still leads often to overcome differences and find a broadly based consensus. The continuous attack on established consensus stabilizes.
Liquid democracy is, when thought to its end, a radical breach with the foundations of democracy that we know and take for granted. Fully evolved, liquid democracy turns the whole process of delegation to parliaments, experts and administration around. The global crisis of the established economical and political order makes it worthwhile to think about opening a new chapter of enlightenment and really consequently accept humans as autonomous beings, that may better care for themselves as benevolent representatives ever could by governing them.
People are regarded as elements of different sets which are represented by typical specimens, the representatives.
One speaks for the others
The representative is the only one who can be noticed of a set from the outside.
Works well if people are homogenous regarding their needs and preferences
No two people are the same (As we clearly see now through web analytics, targeting, social media, etc.)
Speak with us, don’t speak for us.”Let’s listen to every voice without ironing out the differences.
Presentation instead of representation
Participants or votershare suffrage and are at the same time eligible, can thus better be called ‘actors’ than ‘voters’. Actors can issue initiatives for projects like laws, changes in laws, budget decisions, etc.
First step is formulating the initiative as a proposal and upload it to be reviewed and discussed. This step can be preceded by informal discussion going on before the actual upload. During this discussion-phase, the initiative’s author can still change the initiative and react to criticism and suggestions. After a fixed time span (the same for all initiatives on one topic), the initiative’s text is frozen and can no longer be changed. In this ‘frozen’-phase, the initiative has to gather support from other actors who openly and actively register as voters for this initiative. Also, alternatives to the initiative can be added to be decided at the same ballot. For each topic, there a quorum of minimum support can be set, and only initiatives which get above this threshold make it to the ballots.
All actors can delegate their vote to some other actor, who then may delegate her vote together with all votes delegated to her further on, thus forming chains of delegations. Delegation can be withdrawn and changed anytime until the deadline for the decision has passed.
Our subsidiary Baltic Data Science (“BDS”) has formally been appointed by WFP to support them on the scale-up of the Building Blocks project.
We are very proud to announce that our close development partner and Polish subsidiary BDS has formally been appointed by the World Food Programme for the further roll-out the existing Building Blocks platform. At the beginning of the this year, we together with our partner BDS started to build a blockchain-based proof-of-concept for WFP and transformed it into a fully-functional blockchain-based transaction platform in Jordan. The inhabitants receive food vouchers that can be used in the village’s supermarket.
So what are the benefits compared to traditional transaction payments? Thanks to the blockchain technology, our innovative system provides higher transparency of aid accounts for beneficiaries and easy tracking of transaction which helps to lower the effort of bookkeeping for vendors and WFP. The biggest, however invisible, advantage is a minimized risk of fraud or data mismanagement.
We are excited to follow the next phase scale-up of the transaction platform and want to thank WFP for their trust and wish both partners a successful roll-out.
If you want to learn more about our services or specifically this project, please contact us at firstname.lastname@example.org or BDS at email@example.com.
The United Nations World Food Programme „WFP“, with its headquarters located in Rome, Italy is the world’s largest humanitarian agency fighting hunger worldwide. WFP is mandated to deliver the food necessary to save the lives of victims of natural disasters, wars, and civil unrest. On average, WFP reaches more than 80 million people with food assistance in 75 countries each year. About 11,500 people work for the organization, most of them in remote areas, directly serving the hungry poor. WFP is part of the United Nations (UN) System.
Headquartered in Gdansk, Poland, BDS is an international data science and blockchain development company specializing in business-focused solutions. BDS develops data-driven applications (mobile/desktop frontends and backends) for international customers as well as blockchain-based applications.
The blockchain tech sphere in the fall of 2017 looks totally different than in the same period of 2016. Then, many people heard about blockchain for the very first time, now there are several dedicated blockchain platforms for specific applications. In the field of Industry 4.0, beside supply chain and robotics, IoT applications provide a hotbed for highly scalable blockchains, such as IOTA, NEO, or QTUM.
For and with one of these IoT-specific blockchains, IOTA, we will organize a hackathon, a week-end full of code, co-creation and ideas.
BUILD THE FUTURE WITH US!
Today is blockchain, tomorrow is industry 4.0 and the internet of everything. Autonomous cars, sensors and intelligent factories are the future but how will they communicate and transact among one another on a worldwide scale? IOTA is a blockless ledger system which enables scalable autonomous machine to machine micro-transactions without fees. Want to get your hands dirty and take part in building the future?
WHAT’S THE IOTA HACKATHON ALL ABOUT?
Developing services or products for the internet of things
Gaining experience with IOTA’s blockless ledger system for cutting-edge machine to machine transactions
Keynote speeches by key players in the industry
Networking, fun, free food and friendly competition
THREADS TO BE PURSUED
IoT Based Business Plans
Hardware Connectivity Layer: Bluetooth, Z-wave, ZigBee or LoRa
Application Layer: MQTT, XMPP
Fog, Mist & Edge Computing for IoT
IoT Maintenance & Lifecycle Management
Identity of Things (IDoT)
WHO CAN PARTICIPATE?
Business Practitioners & Economists
FRIDAY 17 NOV 18:00 – 19:00
Reception and Networking: Get comfortable and get to know one another
19:00 – 21:30
Keynote Presentations: Introductions and food for thought
– Jörg Blumtritt (Datarella)
– Dominik Schiener (IOTA)
SATURDAY 18 NOV 9:00 – 9:30
Breakfast and Coffee: Fuel up for the Hackathon
9:30 – 10:15
Individual Introductions: Barcamp style three keywords per person
30 Second Elevator Pitches: Explain your idea, build a team that can execute it!
10:15 – 11:00
Team Building: Chat with team leaders of interest & decide which team you want to hack with.
11:00 – 12:00
Speakers round: Getting started with IOTA: Dev Tools & Resources from Baltic Data Science
12:30 – 13:30
Lunch Break: Enjoy some delicious food and get ready
13:30 – 16:30
Time to Hack: Build, Test, Iterate
16:30 – 16:45
Movement Break: Get your blood pumping!
16:45 – 19:30
Time to Hack: Build, Test, Iterate
19:30 – 20:30
Dinner Break: Take some time to nourish the body and get ready for the all nighter to come!
20:30 – Late
Hack Till Your Heart’s Content: It’s up to you. The accelerator is open all night. Code till you drop.
SUNDAY 19 NOV 9:00 – 9:30
Breakfast and Coffee: Fuel up for the final day
9:30 – 12:30
Hacking and Presentation Prep: Get your demos running!
12:30 – 13:30
Lunch Break: Nutrition for the final stretch
13:30 – 14:00
One Last Check: Audio Visual and Tech Check for Demos
14:00 – 16:30
Demo Presentations: Show us what you’re made of!
16:30 – 17:30
Jury Session: Enjoy some refreshments while the jury deliberates
17:30 – 20:30
Awards Ceremony: Celebrate with the winners, network and celebrate
To apply for the IOTA HACKATHON 2017 register now!
Don’t wait for too long – the number of participants is limited.
We at Datarella are strong believers in blockchain technology. We have been working on blockchain projects since 2015 – with leading índustry players and organisations. Since we are platform-agnostic, we have worked with Bitcoin, Ethereum, Hyperledger, IOTA, and other blockchains.
One key takeaway of two years of blockchain experience is, that – in the fall of 2017 – most blockchains are still quite immature and a lot of work has to be done in order to make them industry-ready. We see a huge demand for development and investment in not only blockchain-related projects but also in the core blockchain protocols. The key development challenges in 2018 will be to significantly improve the scalability, the stability and the security of blockchain platforms.
As digital organisms fed by communities of developers, blockchain protocols evolve through changes in their code, i.e. either by changes to the original code or through adding a new microorganism – a side chain – by forking the original chain. Both, changes to the original code and forks, could be combined by creating a forkless blockchain with specific rules in the protocol that are created by other rules (see: the Nomic game ). This way, forks would not be needed anymore since rules could be changeable by other rules.
Most industry blockchain projects are developed using side chains. First, that’s to eschew the disadvantages of public blockchains, s.a. PoW, and then, it’s because of the lack of industry-grade conditions in public blockchains. Most, if not all, industry-led blockchain project teams would love to use public chains if they could be used in a reliable way.
Tragedy Of The Commons
That said, strong evolutionary processes in blockchains are needed. But, where’s the incentive for developers to invest resources into the core protocols? The only way to benefit from working on core blockchain protocols is mining tokens and profit from a potential increase in value or joining on elf the blockchain’s foundations and getting paid by them. This imbalance of having no incentive to work on a core technology which everybody would like to see well developed is called the tragedy of the commons: the economic reward for a developer improving blockchain technology is low.
Funding work on core blockchain protocols and thereby the creation of incentives for developers could be provided by private institutions, s.a. Venture Capital (VC) firms, and by public funding, e.g. through a public crowdfunding initiative: the Ethereum foundation could sell Ether through a crowdsale to the developer community working on a specific update in Ethereum’s evolutionary process. For the blockchain’s foundations that would be straightforward thinking.
VCs, however, would have to make sure that their assets, i.e. portfolio companies, profit from an investment in the core blockchain protocol. This could be done indirectly, if blockchain projects don’t need to develop certain functionalities which are already woven in the core protocol, and therefore minimize their efforts and streamline their roadmaps to exit. It can be questioned if that’s an adequate benefit from the VC‘s perspective.
Crowdstart Capital dedicates tokens to the blockchain developer community
With our sister company Crowdstart Capital (CSC) we are planning to address the funding challenge described above. Crowdstart Capital’s goal is to foster blockchain core technologies and applications. CSC wants to contribute to helping blockchain evolve into an enterprise-ready technology. In order to lay a basis for a cryptoeconomic incentive scheme to support the development of blockchain-related projects and to provide incentives to developers to dedicate their work to blockchain‘s core protocols, XSC tokens will be dedicated to the active blockchain community.
Developers committing code to key blockchain projects can opt in to receive XSC tokens for every line of code that is accepted for the respective projects. CSC will set up a smart-contract-based system that will pay out the tokens according to the commits. This incentive is meant as CSC’s contribution to the blockcahin developer community – there will be no further obligations, i.e. CSC does not demand any return for this.
Technologies to be supported by these incentives include the core protocols of leading blockchains, s.a. Ethereum. Also, all projects that participate in the CSC acceleration program are supported. In a second phase it is planned, that members of the community will be able to suggest projects to be included in the incentive scheme. Which project should be included will be voted for by the community in token-based ballots.
We know that we won‘t achieve our goal over night. And we know that we might adapt our plan when necessary. Finally, the most important factor is the blockchain community itself. If we can successfully motivate blockchain developers to join the scheme, to use the XSC tokens and to spread the word to their respective communities – then we can potentially crowdstart something new: an efficient incentive scheme for the evolution of blockchain technology.
„I can honestly say my industry is being disrupted beyond belief right now. The funny thing is, I like it“, said Jamie Burke during yesterday’s Ethereum Munich meetup „The State of the ICO“. Jamie is betting his Outlier Venture’s fund on the idea to launch a handful, large ICOs to invest in communities and therefore in economies, rather than in startups.
Jamie’s fireside chat (no, there was no fire but it was hot as hell) with Datarella’s founders Michael Reuter and Joerg Blumtritt was a fascinating tour de force towards a potential next level of venture investing in general, and a new breed of investors focusing on communitarian, anti-fragile investments rather than amassing a portfolio of companies of which 90% will fail.
Before, lawyers Dr. Nina-Luisa Siedler of DWF and Dr. Markus Kaulartz of CMS inspired the audience with their highly informative and at the same time very sympathetic presentation on the legal aspects of ICOs. Both being long-time experts in the field of blockchain, managed to entertain everybody although their messages were far from being easy-going. Especially their slide „Consequences in case of incompliance“ filled the room with enthusiasm. Their complete slidedeck „Legal Aspects of ICOs“ can be downloaded here.
Again, the Ethereum meetup was a great success: everybody learned a lot, and from what we overheard on the floor, some of the individual conversations until late at night resulted in new ideas for …. future ICOs.
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.
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…
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?
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!
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.
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.  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.  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.  The thing is that, considering the current rate of prescribing errors causing damage or danger to patients being relatively low (ca. 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). 
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:
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.
See point Knowledge deficiencies.
Through the unification of the various systems available currently, the process of transferring prescriptions would be simplified.
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.
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.  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.  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.
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
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.
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