IOTA Hackathon – Lessons Learned: Fraud Detection (Part 1)

The IOTA Hackathon took place from Nov 17 to Nov 19 in Gdansk, Poland. Software developers from all over Europe came together to put to test the IOTA Platform with various use cases. The event was sponsored by IOTA, Baltic Data Science (blockchain and big data service), Datarella (blockchain and big data consultancy) and Bright Inventions (mobile app development). Four teams of developers and software experts formed around various use cases and competed for 4,200 IOTA in prize money.

This article describes the lessons learned by the „Freedom Pass“ team, which Kira Nezu from Datarella coached. The technical part of the lessons learned can be found here „IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)“ by the team member Jonatan Bergqvist. The team placed 2nd in the competition.

1. The Task

The team was joined by Bogdan Vacusta, who brought a real-life challenge from the London Council to the IOTA Hackathon. London Councils issue „Freedom Passes“ to disabled residents which allow them to use public transport within the city free of charge. Prior to the issuance of a Freedom Pass, one must obtain a doctor’s certificate to prove disability.

Pizza boxes served as flipcharts for use case scenarios

Unfortunately, scammers have successfully been photoshopping doctor’s certificates for perfectly healthy London residents. No one knows for sure how many Freedom Passes have been issued under false pretenses but the number is likely in the thousands. London Councils have no procedure in place to verify if a certificate has been faked. A simple alert, when one doctor has issued an unusually high number of certificates would be a huge step in successfully detecting fraud.  This step alone could save the public tens of millions of Pounds per year with the help of IOTA.

London Councils loose tens of millions of Pounds per year to fraud

The team’s task was to build a Proof of Concept (PoC) to prevent fraud. So, how can IOTA be used for fraud detection?

2. The Solution

The team decided to create a transaction from the doctor to the applicant, thus certifying the disability of the applicant on the IOTA Tangle. If an anomaly in the number of issued certificates of a doctor occurs, the system alerts the London Councils.

In an ideal scenario, the doctor would issue this digital certification from an app (mobile or web based), signing the transaction with her private key (this measure would actually help prevent fraud). Given the short timeframe at the IOTA Hackathon (less than 24h), the team chose to create sample data and to carry out the transaction on the doctor’s behalf for the PoC. A local database would be fed the details of the doctor and the applicant, as to identify them. So, the system for the PoC was to include the following components:

  1. An input form for doctor and applicant data
  2. An interface to the IOTA Tangle
  3. A database with doctor and applicant data
  4. A backend which analyses the data
  5. A frontend for the London Councils with a list of alerts
System Architecture for fraud detection with IOTA. From the doctor’s ID and applicant’s National Insurance Number, a Seed is generated (you can think of a „Seed“ as a key to access your data on IOTA).

3. The Process

Here’s is how it works:

1. Entering the data
The doctor’s and applicant’s data is entered via a web-based user interface (the team actually populated the database by writing a JavaScript method that wrote the fake data directly to the database, so this UI – although functionable – was not needed for the PoC. You can learn more about this in part 2 of the lessons learned):

User interface for entering application data

2. Certification
The data is written to the local database. Simultaneously a transaction – symbolizing the disability certificate – from the doctor to the applicant is immutably written to the IOTA Tangle. The transaction ID is, in turn, written to the local database adding the ability to prove that the certification has taken place.

3. Analysis & Reporting
The backend analyses the data and alerts the officials in case of any anomalies. ie. (If one doctor has issued unusally many certificates within a certain time frame.)

Anomaly report for issues doctor’s certificates

What we learned

We completed our goal within the timeframe despite running into issues due to working with an immature system along the way.  In the end, we managed to create a Proof of Concept perfectly suitable for the setting of the IOTA Hackathon.

We did run into a few issues along the way which must be addressed by the IOTA team in order to improve the system and make it fit for future use cases:

Speed of transactions: On the IOTA testnet we experienced long wait times when confirming transactions. Submitted transactions confirmed in ~1 minute, reading transactions took circa ~3-5 minutes or more depending on the amount of data. This may be a testnet issue independent of the mainnet.

The Documentation was not up to date, there was missing information and what documentation existed was somtimes misleading (i.e. Properties marked as optional are actually required, not obvious that a replayTransaction function creates a completely new transaction, sending message instead of transaction the sender is not documented on the tangle …)

Releases are not scheduled in advance, if an update is run during development, developers must adapt quickly to accommodate changes. A roadmap by IOTA for releases would be very helpful.

Node.js SDK is based on „callbacks“ (an old technology standard), not on „promises“ (current technology standard).

The API can easily be misused. Values and properties that shouldn’t be passed can go through without any error message. The API is missing descriptive error messages, leaving developers in the dark when it comes to hunting down bugs.

So, why IOTA?

Frist off, one might argue that this task could have been done with a regular database entirely. While this is true, a database is a lot easier to attack by hackers than a blockchain or tangle. Also, this kind of system could have been set up on a blockchain system s.a. Ethereum, why use IOTA? Well, the challenges blockchain systems are struggling to overcome are performance and scalability. Due to block sizes, transaction times constantly increase – thus making the systems less usable for scenarios in which transactions must happen near instantly.

IOTA helps to solve the problems of performance and speed of transactions. The team is in agreement that the IOTA Tangle and similar „non-block“ chain approaches are likely to be most feasible to enable scalability in future. Also, an application using IOTA can quite easily be transferred to related use cases.

Conclusion

Would the team recommend using IOTA for fraud prevention?
The answer is Yes, if the long term goal is to further develop IOTA in general. The answer is No, if the system should be used in a productive environment at this point, since it is still immature. Alternative systems which currently are more mature and could be used for the task include Hyperledger Fabric, Sovrin and Ethereum. These blockchain systems pose scalability issues in the future, whereas development here is also ongoing.

The IOTA application „Freedom Pass“ is very well scalable and transferable to related use cases. However, IOTA must undertake massive improvements regarding performance s.a. speed and documentation as well as for the API and SDK/node.js. If the above issues are continuously improved, the team recommends IOTA for further developing this kind of system for the public. IOTA promises future potential for the public for reconciliation of data, reduction of duplication, auditability, authentication.

Team „Freedom Pass“ at the IOTA Hackathon in Gdansk (from left to right): Michał Łukasiewicz, Kira Nezu, Bogdan Vacusta, Jonatan Bergqvist, Victor Naumik, Rafal Hofman, Artem Goncharenko

Continue to the technical report by Jonatan Bergqvist:
„IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)“

IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)

This is the second installment in the posts about the experiences that Team Freedom made during the IOTA Hackathon. In the first post, Kira set the stage and explained the current issues of the London Freedom Pass. In this post, we’ll get a bit more detailed with regards to how we built the project.

DISCLAIMER: Even though the project is called „Fraud Detection“ the technological focus is very much on IOTA and not at all on machine learning-methodologies or data science, as one would commonly associate with fraud detection and prevention.

After we’d narrowed the scope down sufficiently to what we thought would be achievable during a hackathon, we started getting familiar with the IOTA tangle. We followed this tutorial for making a simple transaction, written only a few weeks earlier but already with some modifications required. After having gotten ourselves familiar with the general concepts of the Tangle (much accelerated by a presentation and Q&A by Chris Dukakis of IOTA) we connected to a testnet node and started issuing transactions.

Before we get into the details of the project, I’ll make a short comment about the decision whether to run a full node, the IOTA Reference Implementation (IRI) or to connect to pre-existing nodes. In short, to run the IRI, one needs a complete Java Runtime Environment, which is one of the reasons why IOTA can’t be run on an IoT device at this point. Each node connected to the tangle exposes an HTTP API through which transactions can be issued. To set up an instance of the IRI, one has to acquire the addresses of the already connected nodes in the tangle. The recommended way to do this is by asking people in the slack-channel #nodesharing. Because of the above restrictions and our requirements in time, we didn’t think it would be necessary to run our own node.

Back to the task of solving the problem of fraud in the application process for the Freedom Pass in London boroughs. We settled for the JavaScript library since it does a lot of the heavy lifting on top of the API and is by far the best-documented library. (The winning team used the mostly undocumented Python library and still managed to interact fairly smoothly with the tangle). The iota.lib.js implements both the standard API, some useful functionality like signing, unit conversion and reading from the tangle. In our project, we had set out to supply the following interactions between the tangle and our users:

  1. Register Doctor as a seed on the tangle
  2. Register Applicant as a seed on the tangle
  3. Perform a transaction for each certificate between the issuing Doctor to the Applicant.
  4. Verify that a certificate was registered on the tangle given a Doctor and an Applicant
  5. Read information off of the tangle about outgoing transactions from all Doctors

Given the above functionality, how could we leverage the existing IOTA library in the best way possible? Well, since smart contracts or most types of advanced transactions aren’t really possible on IOTA (yet), we will need some off-tangle processing, storage, and UI.

For this, we implemented a backend and some wrapping to process the information from the applications. The server-side was written using Node.JS and the express-framework. To model the logic and structure of the database, we used MongoDB and mongoose. The MongoDB contained a simple key-value store, saving relevant applicant information. One could imagine that is could be upgraded to a graph-model to better mirror the tangle structure and to be able to more efficiently analyze connections between Doctors and Applicants, however, that was out-of-scope during the ~30h of coding we had.

In order for the user to interact with the tangle in an easy way, we built a small web-frontend. It allows the user to enter information about an application such as the national insurance number of an Applicant, postal code of the Doctor and Applicant, phone numbers, etc. At this stage, four things need to happen: 1. The information is saved in the MongoDB-collection, 2. Seeds for the Applicant and Doctor are created based on an aggregate of identifying information, 3. New test tokens are generated and sent to the Doctor’s account and 4. An IOTA transaction is issued from the Doctor to the Applicant.

To save the information into a MongoDB-collection a controller instantiates and returns a new model containing the just entered data. It passes it on to the server.jswho handles the HTTP-requests from the client.

There is no dedicated IOTA API-call for generating seeds, but they do supply a command line command for generating a random seed. We made our seeds relatable to the private information by concatenating the private key with the national insurance number for the Applicants and the Doctor’s ID for the Doctors. After the seed was generated, a fresh address is created for each new transaction.

To make the functions from the iota.lib.js a bit more usable, we wrapped the existing callbacks-based structure in Promises. This allowed our code to become a bit more asynchronous than it is ‚out-of-the-box‘.

Here is an overview of the architecture:

Once the data and the transactions are issued, the next step is to provide a way of viewing the existing applications and certificates. So we created a second page of the UI for listing all applications with relevant information read from the MongoDB-collection. This doesn’t, however, provide such a great way of finding the main type of fraud that we were considering, namely Applicants reusing information about Doctors. This makes it look like a single Doctor issued an unreasonable amount of certificates. A pretty easy case to catch, one would think, but considering it is a completely analog process done by on paper in different boroughs by different administrators, it sums up to quite a large amount of faked applications. This is the type of fraud we focussed on in our processing.

So how can we in a user-friendly way flag cases that should be investigated? We chose the simplest option and created a second view of the UI where each Doctor in the system is listed along with the number of certificates they’ve, supposedly, issued. The list is sorted by the number of certificates issued. Here one could imagine making it a bit smarter by including the date the certificate was issued and creating a more differentiated metric of certificates per time unit, but it wasn’t in scope this time around.  If a Doctor issued more than 10 certificates, they were highlighted in red. A very simple but potentially efficient way of communicating to the user that something needs to be investigated. Of course, the number 10 was completely arbitrary and could have been chosen differently. In fact, to decide that number, one would have to, first of all, analyze historical data.

To sum up, Team Freedom had a lot of fun and learned tons about IOTA, ideation, cooperation, and creation in a short time-frame. We managed to build a functioning Proof of Concept for how IOTA can be used for the secure issuing of medical certificates in order to prevent and detect fraud. The application to the Freedom Pass was done so that it would be easier to understand what was being done and why. But that does in no way mean that the base structure cannot be used for other purposes, in fact, it was written specifically to be general enough that it is also interesting in other areas.

Is this the only way that the problem could have been solved? No. Was it the easiest way of solving it? Absolutely not. However, we believe that only by experimenting and utilizing one of the few scalable and future-resistant distributed ledger solutions can we achieve applicability. There is, generally speaking, almost no distributed ledger application that could not have been done without the use of a distributed ledger, but it would have incurred great financial, organizational or trust costs. IOTA is a very cost-effective and scalable solution, but with the caveat that it is still in its infancy.

Freedom!

 Here is an overview of all reports on the IOTA Hackathon’s projects:

1st place – „PlugInBaby“:

…describes the idea and the pivot of the project
Team „PlugInBaby“: Open Car Charging Network (Part 2)
…describes the technical level and provides resources

2nd place – „Freedom Pass“:
Team Freedom Pass: Fraud Detection (Part 1)
…describes the high level of the project
Team Freedom Pass: Fraud Detection (Part 2)
…describes the technical level of the project

Blockchain and Liquid Democracy – Phase 3 of the CSC Blockchain Evolution Incentive Scheme

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.

Liquid Democracy
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.

Initiatives
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.

Delegation
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.

Delegation

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.

Representation (=aggregation)

  • 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

Presentation

  • 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

Electorate

  • 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.
    Initiatives
  • 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.

Delegation
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.

IOTA Hackathon Kick-off Event For CSC Blockchain Ecosystem Incentive Scheme

Crowdstart Capital (CSC) seeks 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
  • Software companies
  • Open source software development organizations
  • Software startups

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
  • Blockchain derivatives
  • 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
  • Blockchain-related conferences
  • Hackathons
  • Incubator events
  • Blockchain meetups

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.

The Process

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.

A secondary smart contract will enable voting by people who already have some XSC. The community will be able to propose which projects to support in Phase 3. The framework for Phase 3 – a Liquid Democracy, or, Liquid Feedback process – will be described in the next post.

Kick-off at IOTA Hackathon, Gdansk

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.

Update On The Crowdstart Capital Token Sale

The Crowdstart Capital token sale will start on December, 1,  and will end on February, 28, 2018.

The reason for the new start date is ongoing discussions with regulatory bodies. Since we are making every effort to to conduct a quasi-compliant token sale, we will begin the token sale four weeks later than the originally planned date.

The reason for the extended token sale period is to allow interested token buyers and ourselves more time to really understand the business model behind Crowdstart Capital. During the last few weeks we have learned that many potential token buyers like and support our model in general. However, many of them want to learn more about how we accelerate blockchain startups and blockchain technology in general, in order to get a better sense of their future investments.

If you are interested in buying XSC tokens, you may reach out to the Crowdstart Capital team on Slack or via email. In early November, we will offer our first live chat in which we will discuss several aspects of the token sale. If you want to stay informed, please register for updates in our Slack.

The Crowdstart Capital Vision – An Incentive Scheme For The Blockchain Ecosystem

We at Crowdstart Capital are strong believers in blockchain technology. We have been working on blockchain projects at Datarella GmbH 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.

CSC dedicates tokens to the blockchain developer community

CSC’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.

In Search of the 1% of Startups that Work on Products People Actually Want

Three out of four startups fail and 90% of those in the tech industry don’t survive. To become highly successful, good timing, a portion of luck, exceptional leadership and a high dose of resilience are needed.

We at Crowdstart Capital are convinced that these traits and contexts are necessary but not sufficient factors for success. Even within a positive context, the venture capital world remains a gambling game with so many startups working on products nobody wants. Missing market needs are the most common reason for startup failure, way before a lack of liquidity and other factors.

Is there a way for founding teams to better meet market expectations? How could they avoid choosing wrong development paths? First, they must make sure to work on a product the market needs or will need in the future. Second, they should stick very closely with the principles of the lean startup, and work in an extremely focused and agile way to detect any deviation from the optimal path. Third, they should closely watch the players in the market they aim for: do they still wait for the original product idea or have their needs changed?

Easy as it sounds, these requirements are tough to match. Here, Crowdstart Capital comes into play. During a period of 6-12 months, we support startups by guiding them through the above mentioned challenges. Based on our close relationships and working experiences with corporate clients, we make sure that all developed products meet the expectations of either a client’s business unit or broader market needs. In other words, we bridge the gap between the startup and the market.

Our colleagues in venture capital firms rightly point to a startup’s lower potential exit value if it closely aligns its fate with some corporate enterprise. That is true. The more open approach of traditional VCs maximises the exit value since several players in the target market could bid for the startup. However, a traditional venture capital investment phase takes 3-4 years, compared with 6-12 months at Crowdstart Capital. In theory, the Crowdstart Capital model should be as least as efficient as the traditional one, if not more. In practice, we will see first results in mid 2018. If theory and practice coalesce, CSC supported teams will belong to the 1% of startups making sense.

Crowdstart Capital vs Traditional Venture Capital

At first sight, there might be no big difference between an investment by Crowdstart Capital CSC or a traditional venture capital firm – both select promising startups, invest, create value and, finally, help them being acquired  by a target company.  However, If you look at the details, two major differentiators can be unveiled.

First, Crowdstart Capital does not manage a fund financed by so-called Limited Partners, or LPs, typically comprised of financial institutions such as banks, insurance companies or hedge funds. CSC invests money originated with a digital token sale, or ICO. By offering its digital token XSC, CSC collects money that is invested in startups. The XSC token holders do not own any shares in CSC, nor in the portfolio companies, and they are not entitled to receive any financial return in the form of a dividend or another payout.

Instead, the token holder can trade their XSC tokens on cryptocurrency exchanges and profit from a potential increase of value. The fundamental, underlying reason for an increasing value of each XSC token over time is embedded in the CSC investment scheme: 75% of the profits made in the case of a financial transaction, such as an acquisition, will be reinvested. That means, every positive financial transaction may add to the total value of XSC tokens. Since the total amount of issued tokens will not change, each token should profit from the CSC investment scheme.

The next major differentiator between CSC and traditional VC investments is the specific investment process. A traditional VC typically acts quite opportunistically by trying to stir interest for their portfolio companies with a big number of different potential target companies in order to maximise the takeover price. We at CSC, as our colleagues over at traditional VC firms,  also like to profit from investments. But, our goal is not to maximise the takeover price. Instead, we focus on a streamlined, efficient investment and startup development process that is closely aligned with our industry partner’s strategic roadmaps: by guiding our portfolio companies right from the start, working together with them to build their products in a way they can smoothly be integrated into our industry partner’s business units, we optimise the startup’s way to exit.

Within a 6-12 month’s period, a startup should be ready to be acquired and to add value to our partner’s balance sheets immediately. This guided tour to exit can be regarded as a leaner, quicker and more solid version of the traditional VC approach.

We at CSC are fully aware that our approach is a new one. In the fall of 2017, we can not yet prove that the CSC way works. However, we can prove that we have been quite successful in our field of investment, the Blockchain technology. With our company Datarella, we have been working on Blockchain projects with industry leaders since 2015. Our most visible project is the Building Blocks project, United Nation’s first Blockchain project ever, that we developed for the UN branch World Food Programme in a Jordanian refugee camp in the first half of 2017.

Based on our extensive working experiences in the field of Blockchain as well as our team’s personal experiences in building companies, investment funds and working in C-level positions in major global companies, we strongly believe that CSC will become a success in the startup landscape. We actively seek conversations with venture capitalists and would like to learn from them, and to discuss various investment approaches.

First and foremost, we focus on our digital token sale that will start on November, 1st. Before, we offer a portion of our digital tokens to selected professional investors in a pre-sale. We thank all participants in the token sale in advance and are looking forward to investing in promising Blockchain projects!

Guiding more startups to successful exits

Most of the new business ideas I have are nonsense. They come up; I instantly like them, I discuss them with whomever I can find – until I realize that they aren’t half as good as I thought they were in the beginning.

Having been an entrepreneur for more than 20 years, this insight is an easy one – in the late 90’s, that was much harder to accept. Maybe it’s a matter of wisdom of age, or just the fact that today most key performance indicators of the startup exosystem are common knowledge: VCs must agglomerate quite a bunch of portfolio companies until one of them proves to be the exit star that cross-subsidizes all others and pays for the complete fund. Then, there are well-known startup techniques, such as agile business development, that allow for a lean approach, minimizing costs and risks of wrong development paths.

In other words: the startup world has become more transparent, better known, more mature. And, yet. Despite these myriads of mentoring classes and acceleration programs and these libraries full of How-To-Found-A-Business-Books, it seems that the gap between a startup’s plans and expectations and the market’s needs has not diminished much. Each day, I read about startups with ideas I don’t grasp even after thinking several times about them. Sure, it could be my fault, lacking some fantasy like everybody before Steve Jobs presented us the iPod. But, I’m not alone: well-respected entrepreneurs and investors are telling the same story: the majority of startups produce useless products and services.

Since lamenting never makes any sense, there must be a way to change this imbalance. Some aspects of the typical startup process should be adapted to allow a more professional, streamlined way of leading a startup to a successful exit. This is exactly what my colleagues and I are trying to achieve: to bridge the gap between a startup’s precondition and the need of a real, existing consumer, or corporate business partner, respectively.

With Crowdstart Capital we combine our experiences as entrepreneurs, investors and top managers, as well as our existing business with leading industry companies and guide Blockchain startups in the fields of Industry 4.0, Energy, LegalTech, Helthcare and Space on their way to exit. We will ICO in November and start investing in Blockchain projects right afterwards. It will be a fascinating journey – if you feel addressed, come and speak to us.

 

The October 2017 CrowdStart Capital Ramp-Up

In the midst of mega-ICOs, the Bitcoin fork and high volatility on the crypto markets, we have prepared our blockchain technology accelerator program CrowdStart Capital for its launch in October. Starting on the 1st of October, we will offer 250 million CSC tokens at $0.01 in a token sale ending on October, 31, or after a minimum threshold number of tokens have been sold.

The purpose of CSC is

  1. To invest in a relatively unexplored niche-market (i.e. blockchain technology) based on decades of experience in business, blockchain technology and investment.
  2. To open up investment opportunities in what is commonly known as venture funding to a larger crowd.
  3. To take a leading role in the encouragement of innovation and adoption of blockchain technology (more here) through investment, mentoring and application promotion.

Each blockchain-related startup will pass through a tight mentoring process of 6-12 months in order to being prepared for a subsequent purchase by a strategic investor. The startups will be selected by CSC based on its extensive project experience with corporate clients.  Thus, the CSC model is a hybrid combining both, the positive aspects of a venture capital approach with those of a corporate venture approach: startups will experience a ‘guided tour to exit’. CSC’s corporate partners profit from an efficient business development process resulting in a perfect match with their strategic needs.

Since most of the CSC team members have been founders themselves and know about the challenges and potential paths of startups, we are quite confident that our model will work out successfully. If you are a founder of a blockchain-related company and you think that the ‘guided tour to exit’ is an option for you and your team, please join our Slack and present your company in the „Promote My Project“ channel.

We are very much looking forward to working with passionate blockchain founders!

JOIN THE CSC SLACK