CROWDVOTE – Modular Building Blocks for an Ethereum Voting DApp


The next phase of the Crowdstart XSC plan is CROWDVOTE, a crowd-based voting mechanism to distribute CrowdstartCoins XSC to the best blockchain projects out there. In this post, we’ll give you a preview of the technical underpinnings for our CROWDVOTE decentralized application and a short update on where we’re at in the development process.

The DApp is still a work in progress, but we’ve passed some important internal milestones. We’d like to update the community with an overview of the minimum technical requirements for the DApp,  an overview of the development tools we’re using and a description of the tech stack we’re building for the DApp.

We at Crowdstart Capital don’t think that we are the best people to decide who is eligible to receive CrowdstartCoins XSC. It should rather be the responsibility of the entire blockchain community to form opinions and make decisions that define the distribution of the token.  We want XSC to be THE token for rewarding contributions to the blockchain ecosystem at-large. The CROWDVOTE DApp is the tool to enable this.

CROWDVOTE Minimum Viable Product DApp Requirements:

  • Enable Crowdstart Capital to manage an initial list of candidate developers
  • Empower XSC Holders and only XSC Holders to vote for their favorite projects
  • Allow cryptographically verifiable voting without the need to send XSC to any central party or tie up XSC in an escrow contract for the duration of the voting period.
  • Distribute XSC automatically to the winner at the end of the voting period.

CROWDVOTE Roadmap – Beyond Minimum Viable Product

  • Provide a mechanism by which XSC holders can nominate developers and projects to vote on
  • Allow voters to vote on the amount of XSC to be distributed in a voting period

The rest of this post is divided into three sections.

  • Our Development Tools: DApp development can be a bit daunting due to the number of development tools available. In this section, we’ll list the tools we’re using to build the DApp and why we chose them.
  • Technology Stack: In this section, we’ll outline the components of our technology stack and describe how they fit together. One of the most challenging things about DApp development is just understanding how all the technology really works together. This section will address our choice of front-end technology, hosting, authentication and finally our smart contracts.
  • If you’re just anxious to hear about the status of the CROWDVOTE DApp development you can scroll to the very end for an update on our development process.

Our Development Tools:


Truffle: Truffle is one of the most popular development frameworks for Ethereum. It’s written in javascript so it matches the rest of our project quite well and doesn’t require us to switch contexts while developing.  We’re using it in this project to handle smart contract compilation, linking, deployment and binary management as well as migrations.


Node.js: Node is a JavaScript runtime which we use for development.  It allows us to run JavaScript code locally for development and testing.


npm: This is the largest JavaScript package manager out there. It helps manage the installation of the necessary components via the command line.

http-server: This is a simple command line based http server. It allows us to run the React, JavaScript and associated HTML code locally during development and testing.

Technology Stack



JavaScript: We’re using mostly ES6/ ECMAScript2015. The reasons for picking JavaScript were pretty straightforward. The wide adoption of the language for front-end work and the wide availability of libraries/frameworks were both important factors. The fact that we’re connecting to our smart contracts via web3.js (the Ethereum compatible JavaScript API) was also a deciding factor in favor of JavaScript as our primary development language.


React JS: React is an easy to use JavaScript library which allows us to create a reactive DApp front-end which works on many different devices. We did consider developing using Meteor but Meteor is designed to provide a full tech stack including back-end functionality via a server that’s running Node, MongoDB, etc.. For this project, our backend is essentially the Ethereum blockchain which means Meteor doesn’t really fit our needs. For our purposes the React library allows us to make prettier DApp more quickly than would otherwise be possible.


Babel: Babel is a JavaScript compiler that allows us to use the new EC6/ECMAScript 2015 JS syntax without worrying about browser compatibility. Many of the newest features of JavaScript aren’t available for all browsers. One good example of this is arrow functions which despite being very common in modern JavaScript programming, aren’t uniformly supported across browsers.


Webpack: Webpack is a static module bundler for JavaScript applications.  Specifically, this means that it recursively builds a dependency graph that includes every module which our DApp needs and then packages all of those modules into a bundle which can be loaded by the browser. With this approach, any time one file depends on another it is treated as a dependency.



IPFS (Interplanetary File System): IPFS is a peer-to-peer hypermedia protocol. That basically means that it’s a cutting-edge decentralized replacement for the HTTP protocol. We’re initially planning to use IPFS for decentralization and censorship resistance. One potential disadvantage with IPFS at the moment is long loading times. As the network of IPFS nodes scales though it should actually become faster and more efficient than HTTP.

Ethereum API and Authentication Methods


Our front-end communicates with the backend via Web3.js.  Web3.js is the JavaScript API which implements the generic JSON-RPC spec. Web3.js can also be described as a collection of libraries which allow one to interact with a local or remote Ethereum node using an HTTP or IPC connection.

The easiest way to allow users to interact with the Ethereum blockchain is by using the MetaMask plugin. It exists as a browser extension that enables the signing of transactions on both testnets, private networks and the public blockchain. MetaMask enables an application (decentralized or otherwise) to read from the blockchain and propose transactions to the current user. It does this by injecting a Web3 object and the Web3.js library into the javascript context of the user’s browser. When the user authorizes a transaction via Metamask we use a web3.js call to trigger the sending of a JSON-RPC request to a node specified by the user in Metamask (e.g.,, etc.).

RPC is a general API architecture for data exchange and invocation of functionality. In our case we use it for interacting with the nodes and, in extension, the EVM. RPC is an alternative to the common REST architectural style. It’s used because it provides a more direct server-client connection to the blockchain and because given the immutable nature of the blockchain the CRUD model isn’t exactly optimal.

In the other direction, the node sends information via JSON-RPC back to the user over HTTP and it is implemented by the web3.js API installed on the user computer or in the browser. Users with Metamask installed in a normal browser or who are using a web3.js-enabled DApp browser can interpret this information and update the front-end accordingly.

Smart Contracts

Crowdstart Coin

Programming smart contracts is a bit different from programming other applications. Once contracts are deployed they can only be swapped out for other contracts, not directly updated, assuming that such a modular handoff was provided for in the initial contract code. Additionally, it is best to use battle-tested contracts that have been peer-reviewed where possible since mainnet Ethereum contracts handle valuable tokens and ether. 

To facilitate speedy development and security we’ve based our contracts around the smart contract based voting architecture outlined in Giveth’s MiniMe project.

There are three contracts which act together to provide the voting logic and grant voting rights to XSC holders.


At the heart of this system is a token factory which allows us to clone the XSC token distribution at the start of a given block. You can think of these XSC_Mini tokens like an automatically assigned voter identification card. They are only issued to XSC holders but don’t alter anything about the XSC distribution.  Much like you don’t lose your citizenship if you lose your voter identification card, nothing happens to your XSC if you receive or use XSC_Mini in the CROWDVOTE DApp.

Furthermore, the contracts allow us to reset the quantity of XSC_Mini to match the new distribution at the beginning of each voting period. This is achieved through the use of a separate token controller contract which can freeze/generate/destroy/transfer the XSC_Mini tokens at will. The logical consequence of this is that XSC_Mini has no speculative value.

All of this complexity is hidden from the user.  CROWDVOTE DApp voters holding XSC will automatically be authorized to vote when they access the DApp either via a normal browser with Metamask installed (assuming they are logged in to the account which holds the XSC tokens) or via a Web3.js enabled DApp browser. Users won’t see or interact with the XSC_Mini tokens except when authorizing the gas costs necessary for casting a vote (which is accomplished by sending XSC_Mini to the voting contract in the background). Non-holders will be redirected to one of the decentral exchanges where XSC can be purchased while developers will be redirected to a form where they can request XSC as a reward for contributions to the blockchain ecosystem.

Votes will be tallied automatically by the smart contract to which they are sent and we will enable the contract to directly distribute the XSC rewards as soon as the voting period ends.  Following that the XSC_Mini controller will reset the XSC_Mini balances to match the overall XSC distribution and the process will begin again.

Since the smart contracts are set up in a modular fashion we will be able to eventually reassign control of the XSC_Mini and voting logic in the future.  Our long-term vision for CROWDVOTE is that we will be able to allow community members to define both the voting logic and the nominated developer list decentrally.

Development Status Update

Last, but not certainly not least we want to give you a short update on the status of our development efforts. At this point, we have a CROWDVOTE proof of concept up and running. We still need to rebuild the front-end and redesign parts of the smart contracts to facilitate a custom voting logic. The basics are however already running, so we’re confident that we’ll be able to launch this DApp by the Tech Conference on July 24, 2018.

We’re also planning to launch our own wallet and DApp browser for the conference but we’ll outline that in a separate post later this week.

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.

To start the process of decision making, actors formulate their proposal as a so called initiative. The initiative is uploaded to the decision making platform it to be reviewed and discussed. This step can be preceded by informal discussion going on before the actual upload. During this discussion-phase, the initiative’s author can still change the initiative and react to criticism and suggestions. After a fixed time span (the same for all initiatives on one topic), the initiative’s text is frozen and can no longer be changed. In this ‘frozen’-phase, the initiative has to gather support from other actors who openly and actively register as voters for this initiative. Also, alternatives to the initiative can be added to be decided at the same ballot. For each topic, there a quorum of minimum support can be set, and only initiatives which get above this threshold make it to the ballots.

All actors can delegate their vote to some other actor, who then may delegate her vote together with all votes delegated to her further on, thus forming chains of delegations. Delegation can be withdrawn and changed anytime until the deadline for the decision has passed.


Secrecy of the vote
Of course, if delegation is possible to anybody, it requires accountability who gets delegated how many votes. As soon as somebody passes on my delegation, I want to be sure about the possible consequences to have the possibility to decide to withdraw and re-delegate or vote to myself. Before the blockchain, it was at least debatable if computer-based voting systems in general should require full identification of the voters to the public to prevent fraud. With liquid democracy, however, it would become mandatory to disclose the identity of most voters. With the blockchain, it is finally possible to heal this. Delegations can be provably legitimate and transparent without requiring to vote fully in the open.

Presentation instead of representation
In more then 2000 years, from the beginning of the Greek democracy and the Roman republic, the representative system prevailed, in which people delegate their interests to someone to represent them. It is not necessarily the case that representative systems are also democratic but in our contemporary understanding, all democracies are representative, that is, the decision making is done indirectly and not directly. There are obviously hardly any examples of grassroots democracy that could be called a success, apart from a few counties in Switzerland. Is the ideology of representative democracy thus without alternative? Representation, the parliament, has a long list of advantages – from “not everybody can be expert for everything” to “not everybody can join every conversation” – a discussion of which would lead to far here, as would a criticism of representative democracy as such. Here we want to focus on liquid democracy as an alternative hypothesis to representation.

Communities exist by their members’ taking tasks, fulfil duties within the community, and participate in the successes that are communally achieved. In a society, citizens delegate parts of their tasks and duties to the state’s administration. Over the course of the last two hundred years, the citizens of the so called western world have handed over more and more of their very own responsibilities to the state – caring for the sick and elderly, birth and death, provisions for retirement, education and many more.

How these delegated tasks have to be carried out is fixed by the process of representative decision making that characterizes parliamentary democracy.

Elected representatives are assigned to taking care about this for a time of multiple years. That all these jobs can be done, experts have to be paid for and equipped with the necessary means of work. To control the adequate application of these means, finally an administration is needed to oversee it. It is not clear, how the carefully balanced system of checks and controls between administration and parliament would be affected by such a radical change in delegation that liquid democracy would propose. The promise, however is to take back responsibility into the hands of the people.

Direct democracy is usually just seen as plebiscite, that is to “give the decision to the polls”. Basically, the political work in this case is still done by the elected representatives. Proxy vote or the imperative mandate goes considerably farther by tying the votes to a definitive decision behavior of the parliamentarian representing their voters. Imperative mandates are usually bound to decisions of conventions of voters. A party conventions or a citizen councils decides by majority, and the delegatee has to represent this decision in parliament. Proxy voting however allows for every single person to delegate their vote to those who would represent their opinion in the session. All three forms, plebiscite, imperative mandate or proxy voting – as in the same way then the classic “conscience-bound mandate” of the most democratic election laws – assume that there is a group of people, homogeneous enough to be abstracted into one set and then represented by their member of parliament.

In liquid democracy there is no separation of suffrage and eligibility, because everyone can contribute and vote. Everybody presents themselves – and even if they would have delegated their vote to someone else, there is no abstraction of people to groups that are represented. Liquid democracy is a system of direct, non-representative democracy.

A complete presentation of everybody for themselves show of course the marks of Max Stirner’s anarchistic egoism. And communities that are organized in such a non-representative way, like e.g. Wikipedia, in fact well appear like you would imagine Stirner’s anarchy.

A logical outcome of such a non-representative system is also, to no longer distribute governmental transfer payments, subsidies or appropriations top-down, but allow every person the same access. It is thus only consequent that Piratenpartei takes the basic income guarantee as a programmatic goal.

Liquid democracy is often compared with Wikipedia – everybody can participate, all discussions are open. And by means of delegation, if someone would not see themselves as competent for the decision or be busy during the election process, the may trust their political decision to their delegate. This process of Wikipedia-decision making faces some sound criticism: people who cannot articulate themselves very well or who would have to fear that they become “talked into something” or shouted down in the discussion, will not even begin to take part. Everyone who became victim to one of Wikipedia’s deletion-discussions knows how this feels. But still, Wikipedia stands without doubt for one of the very big successes in collective collaboration in the Net. It may appear unbelievable, what was achieved by thousands of people together, without any monetary incentive – and continuously, Wikipedia is brought further, gets enhanced, and this despite the communication culture there is after all gruff, to say it moderately. Wikipedia’s culture nevertheless is not a good example for inclusion; the horrible gender-bias alone is telling.

A concept to soften this spiral of silence is to give the actors the option to perform under a self given name and identity. Since the blockchain can guarantee that every physical person would get only one vote, this ‘autonymity’, the freedom of flexible choice of name, has the advantage, that it is possible to articulate a particular opinion without sticking this permanently to the own personality. However the disadvantages of acting under pseudonym in a system like liquid democracy stand, as discussed above.

Another criticism aims at political reliability. Continuity and predictability are obviously a necessary part of representative systems. The members of parliament represent their mandators only indirectly. For showing to their voters, that their intended politics would be dutifully represented, they have to stay constant and reliable in a few striking aspects, while their motives for most of their decisions would remain undisclosed to their voters. Whip and fidelity to the coalition are the well known consequences – not really in the very sense of our constitution that would see the the decision behavior only bound to the conscience. Since there is hardly any empirical data on Liquid Democracy, it is for now totally unclear, how stable and continuous the policies would be that the liquid decision making process would support.

Consensus instead of compromise
Liquid democracy means everyone is able to contribute, and consensus is to be build above the suggestions. Consensus does not mean majority. A majority overrules those who do not share the opinion – after the ballot, the set of voters will be regarded as homogeneous regarding the decision in question. For the daily party business this means: once a party committee has made its decision, all members have to stand behind this (at least this is expected from the party members).

In a non-representative, direct democracy, having unity behind the majority is not the point, since every opinion remains valid and cannot be overruled. Thus it is especially important to concentrate on finding consensus on the crucial topics. Consensus means to really stand behind the decision and not just be outvoted. So we could call consensus in politics as “agreement on the truth” in opposition to “deciding on opinions”.

The struggle for truth leads, as mentioned above, immediately to a rather gruff tone in the debates. Those inferior with arguments frequently take their last stand: the “Shitstorm”, usually a ranting against decisions or actions without arguments – completely convinced to be right and full of anger, not getting right. Other then the compromise which is closed between the two sides engaged – often formalized as in a coalition agreement – consensus is not fixed and not binding. Like in Wikipedia where existing texts are always open to edition, and where the authors continuously have to defend their words if they would like these to remain, the consensus in liquid democracy can always be left, and an initiative for change be placed. Frequently, so called trolls appear in the course of decision making in liquid democracy – people insisting on certain topics in a very destructive way. As inconvenient such arguing with trolls is, it still leads often to overcome differences and find a broadly based consensus. The continuous attack on established consensus stabilizes.

Liquid democracy is, when thought to its end, a radical breach with the foundations of democracy that we know and take for granted. Fully evolved, liquid democracy turns the whole process of delegation to parliaments, experts and administration around. The global crisis of the established economical and political order makes it worthwhile to think about opening a new chapter of enlightenment and really consequently accept humans as autonomous beings, that may better care for themselves as benevolent representatives ever could by governing them.

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


  • No two people are the same (As we clearly see now through web analytics, targeting, social media, etc.)
  • Speak with us, don’t speak for us.”Let’s listen to every voice without ironing out the differences.
  • Presentation instead of representation


  • Participants or votershare suffrage and are at the same time eligible, can thus better be called ‘actors’ than ‘voters’. Actors can issue initiatives for projects like laws, changes in laws, budget decisions, etc.
  • First step is formulating the initiative as a proposal and upload it to be reviewed and discussed. This step can be preceded by informal discussion going on before the actual upload. During this discussion-phase, the initiative’s author can still change the initiative and react to criticism and suggestions. After a fixed time span (the same for all initiatives on one topic), the initiative’s text is frozen and can no longer be changed. In this ‘frozen’-phase, the initiative has to gather support from other actors who openly and actively register as voters for this initiative. Also, alternatives to the initiative can be added to be decided at the same ballot. For each topic, there a quorum of minimum support can be set, and only initiatives which get above this threshold make it to the ballots.

All actors can delegate their vote to some other actor, who then may delegate her vote together with all votes delegated to her further on, thus forming chains of delegations. Delegation can be withdrawn and changed anytime until the deadline for the decision has passed.