The Evolution Of The Enterprise From Institution To Platform To Protocol In A Tokenised Economy

From the early days of capitalism, when from 1633 the Hollandische Mercurius referred  to capitalists as the owners of capital, on to David Ricardo who, in his Principles of Political Economy and Taxation  is seen as the one who actually coined the term capitalism, until today: the structure and behavior of the enterprise as the main capitalist entity, hasn’t changed that much. With the advent of blockchain technology, the evolution of the enterprise could pick up pace, dramatically.

An enterprise can be defined as the largest participant of an economic system with an ideology based on – in most cases – private ownership of the means of production and their operation for profit. In the early days, the owners of an enterprise would manage its operations themselves. With the advent of the public corporation, ownership and management were separated from each other: in most cases, the owners did not participate in the management of the company but delegated this to employed executives. With this separation of ownership and management, and a trend towards larger entities with hundreds to thousands, to hundreds of thousands of employees, enterprises had to be structured in a way that would enable a proper management and controlling. In democratic countries, there are specific sets of regulations and laws that provide the framework for owners’ and managers’ scopes of action.

The Enterprise As An Institution

Throughout the history of capitalism, enterprises have been regarded as stand-alone, singular entities, existing because of the product and service portfolios they would offer to the market. Aspects of enterprises’ interdependencies and connections with their environments played a minor role: one of the better known examples of this is James Buchanan’s Public Choice theory that describes people’s decision-making process within the political realm. When, with the Industrial Revolution, people became aware of the significant external effects enterprises could have not only on the lives of their employees but on the environment, etc., something changed within the enterprises: owners and managers started wondering how they could address their enterprises overall impact on the outside world.

Another aspect that made managers think of the interdependency of their company with others, was marketing. Companies discovered that it wasn’t enough to produce high-quality products – they had to tell potential customers about it and even had to compete with other companies offering similar products.

The Enterprise As A Platform

Acknowledging external impacts of enterprises and the shift from supply-side to demand-side driven markets mark a clear behavioral change for enterprises: trade  unions, environmental regulations, but also purely economic aspects, such as just-in-time production or supply chain optimization, all have led to a new kind of enterprise – evolving from institutional constructs into a platform, acting as hubs mainly responsible for organizing a network of partners making sure a final product will be presented to the customer.

The enterprise as a platform: these days, most companies would be happy being regarded as a platform. After all, that propels them into the top ranks of the innovative minority according to AccentureBain and other consultancies.

And yet, the platform enterprise isn’t state-of-the-art.

Platforms may offer many positive aspects but they lack all advantages of a decentralized, trustless system, such as a blockchain protocol. Apple, Tencent, Siemens, or other giant platforms are centralistic structures that are successful as long as each platform partner plays along: as soon as one entity in the supply chain fails, the product can’t be delivered on time or with a certain quality. Costs of managing and controlling the platform processes itselves have become immense. In the event of an external irregularity, e.g. an activist group’s protest on the basis of an alleged misbehaviour, followed by a consumer boycott, could force even market leaders to halt the production process or even to discontinue a product line. Platforms are highly sensitive against irregularities because of their centralistic architecture.

The Enterprise As A Protocol

There is a cure for this sensitivity: if platform enterprises improve themselves further and evolve into protocols, they become resilient against internal as well as external attacks and they can regain what most of today’s companies have continuously lost in the past years: credibility and trust in the eyes of consumers. A protocol can be described as a defined set of rules and regulations that determine how data is transmitted in networks. A blockchain protocol is a decentralized database and ledger that allows all participants of the network to work with the identical, consistent data set at any time.

Convergence: Blockchain + Smart Technologies

A protocol enterprise uses blockchain technology to share the database and its additional, external intelligence, such as AI, autonomous machines, VR or AR, to collaboratively manage and control a supply chain process. The system is completely decentralized, featuring automated processes in line with a set of rules and regulations all participants have agreed on – the governance model. A liquid feedback mechanism ensures that all participants have the ability to participate in the network’s opinion making process. Depending on the intended level of openness, either selected third parties or the general public may also join the network. In the first case, a private, permissioned blockchain would allow a pre-defined group of participants to join the network. If everybody should be granted access to the network, a public blockchain would be used.

Cryptoeconomics & Token Design

Participants of blockchain networks need tokens to communicate or, more correctly, to transact on the blockchain. These tokens can take different shapes: they can represent a value store only, or they come with a set of instructions defining the so-called token design, or cryptoeconomics of the network. Cryptoeconomics describe the incentive mechanism that motivates participants to actively engage in the network.

In the same way, the token design is the regulatory framework for behaving within the network, it’s the (re-)presentation of each participant’s behaviour and value system. In other words: the token is the representation of the brand equity of the network’s or protocol’s participants. Customer perception will be created through the design and use of the blockchain network tokens. Since all transactions in a blockchain are immutable and, therefore, represent an accurate, consistent history, all actions of a protocol enterprise are open for scrutiny by third parties, s.a. auditors, or the general public, i.e. (potential) customers. CEOs of protocol enterprises won’t have to fear misleading accusations by activist groups. However, they have to be aware that omniscient auditors or customers form their opinions on the company on the basis of a complete behavioral history. Bad times for fraudsters!

A Tokenised Economy

It presumably will take years, if not decades, for existing enterprises to evolve in protocols. Also, many of today’s platforms will not join this evolution and will remain platforms or even morph back into institutions before the end of their business cycle. But for a new breed of contenders, blockchain technology provides the basis for a tokenised product offering already today. These vendors won’t necessarily regarded as enterprises in the first phase, but they might take over the role of today’s market leaders.  The key aspect of a tokenised economy is the token representing the behaviour and values, or, the brand equity, of market participants.

Blockchain technology is still in its infancy: most systems are not enterprise-ready, yet. However, the decentralized and open nature of blockchains provide the basis for a market penetration in an insane mode . Bitcoin, the first blockchain protocol, has evolved into the world’s 6th largest  currency by circulation  according to the Bank for International Settlements. The figure is based on a value of bitcoin at $10,765 each, meaning that the total value of all bitcoins in circulation is $180 bln. Bitcoin evolved into this widely used currency within nine years of existence – being the very first of its kind, initialising the category of cryptocurrencies.

Solarcoin, another cryptocurrency and token, was launched in 2014.  It’s a global rewards program for solar electricity generation: 1 Solarcoin represents 1 MWh (megawatt hour) of solar electricity generation. Verified solar electricity producers,  may get Solarcoins for free when participating in the network. 99% of Solarcoins will be given to solar electricity producers of 97,500 TWh (terrawatt hour) over 40 years. The creators of the Solarcoin foundation expect a market price of $30 per MWh in unregulated and unsubsidised markets. As of today, a Solarcoin costs $0.50 – so, there us a long way to go to reach a $30 price tag. However, at $0.50, Solarcoin has the third largest market capitalisation of all cryptocurrencies, reaching over $45 bln. Since renewable energies, especially solar power, cover more and more of the world’s energy consumption, we could expect the Solarcoin network becoming the or one of the main vendors within this space. And, what else is Solarcoin than a reasonably tokenised product offering?

For us, blockchain technology is more than a database and a ledger: it’s the basis of a tokenised economy. Done right, blockchain protocols not only allow new vendors enter a crowded market, their decentralized and open characteristics provide the tools for decentralized and open business models, such as (a renaissance of) cooperatives, collectives, etc.. Blockchain technology provides the tools – creators and entrepreneurs may now use them and start morphing centralized, vulnerable platform enterprises into decentralized, resilient protocols.

What Is CrowdstartCoin?

CrowdstartCoin (Ticker: XSC) is a digital currency rewarding blockchain developers.

Launched in December 2017, CrowdstartCoin presents the additional advantage of being a tangible virtual currency: in fact, by coupling each line of code committed to projects within the blockchain ecosystem to the production of a CrowdstartCoin, the virtual world joins our physical world. Put another way, CrowdstartCoin works as Reward Miles: any blockchain developer receives CrowdstartCoins for code that she adds to tye development of the blockchain ecosystem – and it’s free!

CrowdstartCoin has a social utility for its community: by rewarding a blockchain developer, CrowdstrtCoin acts as an incentive, stimulating the development of the blockchain ecosystem worldwide. CrowdstartCoin is already distributed within three European countries and is intended to be circulated worldwide: any blockchain developer may apply and claim his CrowdstartCoins for free. To do so, the developer simply fills out this form online with data proving that she has committed code to the blockchain ecosystem.

3-Phase Incentive Scheme

The grant mechanism for delivering CrowdstartCoins is based on 3 phases:

In the first phase, CrowdstartCoins will be directly distributed to the active developer community, approached through blockchain conferences, meetups, forums, etc. Developers committing code to key blockchain projects can opt-in to receive CrowdstartCoins for free for code that has been accepted.

In the second phase, the distribution of CrowdstartCoins will be semi-automated by using a smart-contract-based system to pay out tokens according to the accepted commits. Technologies to be supported by these incentives include the core protocols of leading blockchains, e.g. Ethereum, IOTA, Monero, etc..

In the third phase, members of the community will be able to suggest projects to be rewarded with CrowdstartCoins. A liquid feedback model will be used to enable community voting and determine which blockchain projects should be included.

CrowdstartCoin therefore acts as an incentive for the future development of blockchain technology. Since 1 December, 2017, CrowdstartCoin  is officially listed at the cryptoexchange EtherDelta, with the ticker symbol XSC.

Cryptoexchange EtherDelta Officially Lists CrowdstartCoin XSC

As of today, 1 December 2017, our CrowdstartCoin XSC is tradable on EtherDelta, a decentralized cryptoexchange. 

We are very happy that, ten days after having issued the first CSC to IOTA developers at IOTA hackathon, in Gdansk, the tokens have been officially listed on EtherDelta!  From today, blockchain developers can grow the value of their own token that serves as a reward for contributing to the evolution of the blockchain ecosystem!

Don‘t waste your time, devs! Go, claim your XSC – and trade them!

Incentivizing Blockchain Ecosystem Development

The final decision has been made: We will not ICO through our brand Crowdstart Capital. After having worked on the preparation of a token sale based out of Germany several months we’ve reached the conclusion that such an ICO is not advisable at this time.

Two issues have been the decisive factors: First, an ICO based out of Germany would have to be done in the environment of a legal limbo. Other project teams may decide to take the risk of selling a virtual currency to professional and/or individual investors in Germany but we’ve decided that the regulatory uncertainty and risk is too high. With our parent company Datarella, we have built a solid brand reputation within the blockchain ecosystem and we are not willing to put this at risk.

Second, we think that we can better meet our goal of contributing to the blockchain community by giving our Crowdstart Coins away.  Instead of selling tokens to investors and using this cash to provide blockchain-based startups with consulting, services and solutions, we will reward Crowdstart Coins (XSC) to developers who add valuable code to the blockchain ecosystem.

We gained this insight to change our model while working on the cryptoeconomics; i.e. the inventive mechanism within a specific community. Finally, we have come up with a 3-step-process of distributing Crowdstart Coins – “XSC” – to the blockchain community:

A Blockchain Evolution Incentive Scheme

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.

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.

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.

If you’re a developer who committed code to advance Blockchain technology at-large, you’ll be eligible to receive XSC tokens. You can request XSC by filling out the form:

Developer Incentive Program: Claim XSC Rewards

Show us that you’ve got the right stuff!

Blockchain Meetup 10: C8 – A Global Cooperative: Exchanging Assets, Services, Time And Money

Boyd Cohen

Sometimes, old ideas experience a renaissance triggered by the advent of a new technology. The decentralized architecture of the blockchain finds its equivalent in traditional co-operative schemes as they exist in many different shapes throughout the world.

In this meetup we will discuss how blockchain technology is used to shift power from centralized entities to cooperatives. The Collabor8 (C8) Community Token which aims to develop a protocol and token to support a global ecosystem of decentralized but interconnected platform coops focusing on P2P exchange of assets, services, money and time.

Boyd Cohen, C8’s Economy Director and the author of ‚Post-Capitalist Entrepreneurship‘ will present the community process of designing tokens and the cryptoeconomics needed to motivate people to work and interact in a decentralized, collaborative way.

Continue reading “Blockchain Meetup 10: C8 – A Global Cooperative: Exchanging Assets, Services, Time And Money”

IOTA Hackathon: Open Car Charging Network (Part 2)

PlugInBaby App in iPhone

+++UPDATE+++

We’ve stirred much interest in the issuance of our XSC token at the IOTA hackathon in Gdansk. We therefore decided to prolong our rewards campaign for IOTA developers for 1 week:

If you’re a developer who committed code to advance the IOTA network during the month of November, you’ll be eligible. If you think you’re eligible you can request up to 250 XSC until Friday, 1 December 2017.

Fill out this form now! Show us that you’ve got the right stuff!
Developer Incentives Program: Claim XSC Rewards

For more information on the CSC Blockchain Evolution Incentive Scheme, click here and here.

+++UPDATE+++

This is the second installment outlining the experiences of the winning team “PlugInBaby” during the IOTA Hackathon. In the first post (found here), we describe the idea generation process.  In this post, team member Rebecca Johnson goes into more detail with regards to how the team built the project and what exactly it accomplishes.

Our PoC decentralizes and democratizes access to a  network of electric vehicle chargers by allowing the chargers to costlessly broadcast their status (offline, occupied, available) via 0 value transactions on the tangle. Next, using a mobile app, users searching for a charging station can query the tangle using 0 value transactions to search for tags of available stations. They can reserve a charging spot and book micro transactions necessary to pay for electricity, all using IOTA.

Concept Doodle
A world where individuals leverage open source software and DIY hardware to decentralise the market for energy.

Using the tangle as a database makes the solution quite elegant. The protocol for sending data and value are essentially the same which removes the need for a centralized payment processing layer and allows for the DIY ethic to extend all the way to the end-user.

This approach is also flexible enough to leave room for participation by utilities and other stakeholders since the hardware and software are open-source.  Improvements are welcome and anyone is free to implement the idea. The code can be found here.

Requirements & Assumptions

  • We restricted ourselves to using only IOTA for implementing the database functionality. This carries the theoretical advantages of future scalability, full decentralization and zero transaction costs for messages sent to and from the tangle as well as a mechanism for machine to machine electricity purchases.
  • We assumed that the API and the interaction between the charger and the car app are out of scope for the hackathon.
  • Charging station vendors need to send status messages for their stations (free, in-use, offline) using 0 balance transactions to the tangle. Our back-end provides this capability via terminal inputs. Since this is just a PoC we didn’t build out an API or UI for this portion.
  • A web-based front-end, a back-end connection to the tangle and an API for communication between the two needed to be built. Given this, the team split into two groups of 3-4 developers each.

Back-End:

The experience of the PlugInBaby team was similar to that of the Freedom Pass team. We started out by following this tutorial from Baltic Data Science and gained speed by utilizing some of the resources from the Q&A with Chris Dukakis of IOTA. After that, we connected to a testnet node and started issuing transactions.

Like the Freedom Pass team, we also considered using a mainnet node but the issue of how to connect with neighbors was eventually a knockout criterion. This was actually due to security concerns. One of our team members had a Java Runtime Environment setup on a remote virtual machine and we considered setting up an instance of the IRI. In the end, however, we weren’t comfortable with the security risks that connecting with unknown nodes presented.

In contrast to the other teams, the “PlugInBaby” team used the IOTA Python Library to build and connect the backend. Documentation for this library is quite sparse in comparison with the JavaScript Library. We’d like to thank Andreas OsowskiLewis Freiberg and  Chris Dukakis of IOTA for their round-the-clock support in getting everything up and running.

Our team member Lukasz Zmudzinski has written a great blog post on his site which outlines which Python methods we used to read and write to the tangle in greater detail. We used the Tornado web framework and asynchronous networking library for this project and wrote our own API  to communicate with the front end.

Team PlugInBaby hard at work on frontend development

Front End:

The front end was written primarily in JavaScript and utilizes server.js for Node.  To accelerate development we started using a boilerplate/skeleton for Node.js web applications. We later used bootstrap and AngularJS to improve the styling and make our web app mobile-ready and responsive.

Users can query the tangle for the transactions of vendors with free stations and also read dynamic pricing information. The search mechanism uses information written to tags while the state information about the charging station and the station latitude/longitude are written in the message. This information is then passed via API calls to the front-end for interpretation in the UI.

User Experience:

UI Workflow
UI Workflow
  • Step 1:
    The user uses a smartphone app to query the tangle for available charging stations.
  • Step 2:
    The user selects a charging station from the map. Each station has dynamic pricing which is shown in real-time along with the map pin when selecting the station.
  • Step 3:
    The user drives to the station and lets the station know that they have arrived by sending a message to the tangle.
  • Step 4:
    The charging station tells the app that the car is fully charged.
  • Step 5:
    The user’s IOTA wallet is debited and the transaction is signed by the seed stored in the app.
  • Step 6:
    The charger resets its status to available on the tangle and all the transactions/messages are available for verification.
Tangle Output
IOTA Tangle output: Following charging all transactions are available for inspection in the tangle.

What We Learned:

The PlugInBaby PoC demonstrates the feasibility of an IOTA-based search and payment app for IOTA-based DIY chargers but it is far from ready-for-use outside of the lab/hackathon. A number of issues came up which will need to be solved before this system would be appropriate for public use.

  • Tags only allow for 27 characters which wouldn’t be enough to store latitude and longitude data plus a transaction ID without truncation. The team ended up using the message field to store data (location + charger status) while the tags were used to store a searchable charger identifier.
  • Speed is quite limited on the testnet. Specifically, we found that the testnet confirmation times were quite long late at night (2-3 minutes) when fewer users were online running test applications. This is due to the fact that each new transaction must approve two other transactions. This approach scales well but also requires many active nodes to submit and approve transactions. As both the testnet and the mainnet grow this problem should be mitigated.
  • Transaction caching was required to make the demo useable within the alloted three minute presentation time.
  • While the support from the IOTA team was excellent, we noticed that the documentation, particularly regarding the phython libraries, is quite lacking. This makes development a slow trial and error process.
  • Security and privacy are generally open questions within the IOTA ecosystem. The team assumed these issues to be outside the scope of this PoC. That said we raised privacy concerns regarding the possibility of API misuse and the lack of privacy often during the development process. Improved documentation and more descriptive error messages would go a long way towards making these issues easier to handle.
  • Masked Authenticated Messaging (MAM), the planned Private Transaction layer, and the integration of zero-knowledge-proofs into the IOTA ecosystem are exciting areas for new research given the current limitations of IOTA in the area of security and privacy.

Conclusion

To sum up, the team learned a lot about the implementation of an exciting use case that really makes sense for IOTA. Is this the only way to build such a system? No.  There are many other ways to find, navigate to and pay for electric vehicle charging. Many market-ready centralized systems are already up an running.  Our PoC demonstrates, however, that it’s possible to solve this use case using IOTA alone which allows for the possibility of a scalable decentralized approach. This, in turn, could open up the field to many more players and provide a common system for various entities to build upon.

Hackathon Participants
Team „PlugInBaby“ at the IOTA Hackathon in Gdansk, Poland

 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

IOTA Hackathon: Open Car Charging Network (Part 1)

PlugInBaby App in iPhone

+++UPDATE+++

We’ve stirred much interest in the issuance of our XSC token at the IOTA hackathon in Gdansk. We therefore decided to prolong our rewards campaign for IOTA developers for 1 week:

If you’re a developer who committed code to advance the IOTA network during the month of November, you’ll be eligible. If you think you’re eligible you can request up to 250 XSC until Friday, 1 December 2017.

Fill out this form now! Show us that you’ve got the right stuff!
Developer Incentives Program: Claim XSC Rewards

For more information on the CSC Blockchain Evolution Incentive Scheme, click here and here.

+++UPDATE+++

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 the prize money of 4,200 IOTA. Here in “Part 1″ we summarize the idea iteration process for the contest’s winning team  „PlugInBaby” and the associated pivot that took place while defining the project topic. Part 2 describes the development and design of the project in more detail.

Defining the Need

Idea Consolidation
Idea Consolidation

We started the hackathon with a group brainstorming session followed by some informal voting and group building around the topics generated.

After narrowing the focus down to the topics, “Autonomous Agents” and “Decentralized Stack” the group focused on idea generation.  Any potential topic needed to utilize the special characteristics of IOTA (scalability, speed, zero transactions costs) while avoiding limitations such as the lack of a Turing complete language and smart contract capabilities.

Initial brainstorming considered applications in manufacturing, autonomous transportation, supply chain management and distributed sensor technology.  Eventually the basic idea of using IOTA as a distributed database allowing individuals or autonomous agents to identify free parking spaces in cities and also search for those spaces crystalized out of the brainstorming process.

Pizza Box Brainstorming
Pizza Box Brainstorming

After several hours of work on the concept and the potential implementations, we found structural problems with the plan. In our initial approach, the team imagined that individuals or autonomous agents/smart cars would identify free parking spaces, notify others of their presence by writing to the tangle and potentially be compensated for the service. A number of important questions were however left open with this topic.

Critical Questions that Lead to the Pivot:

  • Why should a system for finding free parking spaces be built using IOTA?
  • Wouldn’t another technology be more appropriate?
  • Why not use a blockchain which allows for smart contracts?
  • Would people really use such an app?

Pivot to an open car charging network

After several hours of discussion, the team still couldn’t adequately answer the above questions so we turned to another idea. Instead of logging free parking spaces, we would provide a link between an IoT network of decentralized charging stations and traditional or autonomous cars needing charging services.

Currently, electric charging infrastructure is almost always mediated by large corporations and organizations. This project seeks to change this.  The team drew inspiration from ElaadNL which built a Proof of Concept (PoC) Charging Station for electric cars running fully on IOTA. Their charger is built using off the shelf tech and could be adopted by individuals who wish to offer electricity from their private microgrid or solar installations. What’s missing in the ElaadNL implementation is a user-friendly way to select and navigate to the charging station.

ElaadNLPoC
ElaadNL IOTA Electric Car Charger PoC

The ElaadNL PoC app works on a “Pull” basis where the user has to enter a charger code to search for the status of a particular charger.  The team wanted to design something that would work on a “Push” basis and push the location of open chargers to users within the familiar confines of a google map interface.

The team envision a world in which individuals could take an open-source IoT charger kit and set up an IOTA-based charging station wherever they have access to power and a parking space. This could open up a whole new layer of community-based decentral charging.

Concept Doodle
A world where individuals leverage open source software and DIY hardware to decentralize the market for energy.

The project, so conceived was well matched with the strengths of IOTA. Scalability and transaction speed would be needed due to continual improvements in the speed of charging and the fact that the search mechanism of the system would have to operate very quickly to guarantee a good user experience. A system with zero transactions costs was also judged to be appropriate for the type of microtransactions that need to occur between a car and a smart charger enabling real-time pricing for electricity.

We owe a shout out to ElaadNL for their PoC. The existence of such charger allowed us to think in a modular fashion and abstract away the charger component to focus instead exclusively on the building a system to find the chargers and transact with them.

IOTA Hackathon winning team “PlugInBaby!”. Team members (from left to right): Yoon Kim, Andrew Young, Rebecca Johnson, Lukasz Zmudzinski, Dominik Harz, Alexei Zamyatin, Linna Wang, Nicolas S – and the moderator Michael Reuter of Datarella to the far right

 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

IOTA Hackathon: 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 functional – 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 unusually 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 a message instead of a 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)”

The team was supported 24/7 throughout the hackathon by members of IOTA – many thanks Chris Dukakis, Lewis Freiberg and Andreas Olowski for their time and effort!

 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

IOTA Hackathon: Fraud Detection (Part 2)

This is the second installment in our posts about the experiences of the “Freedom Pass” team during the IOTA Hackathon. In the first post (found here), 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 analyse connections between Doctors and Applicants, however, that was out-of-scope during the ~24h 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:

“Freedom Pass” System Architecture

Once the data and the transactions were issued, the next step was 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.

UI for entering Doctor’s and Applicant’s data

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.

Hitlist of certificates issued by Doctors

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!
Team “Freedom Pass” at the IOTA Hackathon in Gdansk, Poland

  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

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

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