My First Aragon App: Voting Supercharged with DAOstack’s Holographic Consensus

Part 1 - Introduction

I’ve been wanting to play with Aragon for ages, but could never find the time to do it. When I did find a bit of time to give it a try, my approaches would bluntly be turned away, because as soon as I went into Aragon’sdeveloper portal, I’d quickly become overwhelmed by the huge amount of information that was presented to the curious bypasser. There’s an aragonOS , an aragonAPI , an aragonPM , an aragonCLI , an aragonUI , an Aragon Network , an Aragon Court , and many, many more components... These people seem to have built a completely parallel Aragon universe, which is certainly not something that some timid person peeking in can unwrap.

Despite my initial failures, I kept coming back and trying over and over again, because I had a faint idea of what Aragon represents, which has an immense appeal to me: a platform that allows you to create on-chain organizations that manage just about any kind of human organization you can possibly think of, in a decentralized and trust-minimized way.

If this works, it could be a huge leap forward for human governance, something we’ve been needing for decades in my opinion. We would not only be able to use the internet to exchange information, as some sort of global human subconscious, but also to exchange value and to make decisions in huge groups of individuals that are not even geographically related. The whole concept of what an organization actually is could be turned upside down, taking Yuval Noah Harari’s concept of “myth”, presented in his book Sapiens , to a radical new level.

This is what got me into Ethereum in the first place. So, I kept bumping my head against the wall again and again until, eventually, I punched a hole through the Aragon stack and entered this universe. I started to get the big picture. I was shocked when I understood that you don’t need to know the whole stack to build something very meaningful with it. You can focus on one component at a time, and take it slowly from there, step by step.

So, I decided to build a simple Aragon app. A simple, but real app. I’ll share my experience with you in a series of articles; how I went from one end of the Aragon stack to the other, taking it one step at a time, and ending up with a complete Aragon app.

An Aragon app is basically just a module that you can plug into an Aragon organization. You interact with it, and with any other apps in the organization, through the Aragon client.

But before we get started, we need to decide what to build.

Enter Holographic Consensus

DAOstack has some very interesting ideas about decentralized decision making, and how to avoid collapsing when it scales. You can read more about it in their Holographic Consensus articles Part 1 , and Part 2 . They’ve presented the Genesis Protocol v0.2 , in which they lay out the specs for an implementation of the protocol. DAOstack’s tech is built around these principles, and tightly coupled to them.

Aragon, on the other hand, presents a much simpler voting scheme out of the box with its Voting app , where people just, well, vote . But - and here’s the important part - despite Aragon not addressing scaling issues directly with a prescribed single solution, Aragon presents a very powerful counter-offer: It’s built upon the concepts of flexibility and modularity. You can create a DAO, unplug its default Voting app and plug in whatever you want in its place. We will be doing just that: replacing the more generic Voting app with a supercharged “HCVoting” app, implementing DAOstack’s Holographic Consensus protocol.

Now, we need to understand what Holographic Consensus is, and what problem it was created to solve.

Scalability problems in voting schemes

Holographic Consensus was designed to mitigate an inherent problem with an organization's power to make decisions through voting. In simple terms, as an organization scales, by either having more members voting on proposals, or by having more proposals being voted on, the resource of attention starts to become scarce. The members of the organization simply have too much information to process, and the chance that a given proposal reaches majority consensus (e.g. at least 51% of the total voting power supporting the proposal) starts decreasing. At a critical point, the organization simply loses its ability to resolve proposals before they expire, and hence loses its ability to make decisions.

You could argue that this problem is addressed by Aragon's Voting app, which allows a minimum quorum parameter to be set. To illustrate, consider a proposal that has a minimum quorum of 100 tokens, with a voting token whose total supply is 1000. This proposal allows a decision to be made with relative consensus (as opposed to absolute consensus), which is basically a decision made by a portion of the total voting power. Instead of requiring 51% of the total token supply to back the proposal, which would be 510 tokens, only 51% of the minimum quorum is required, which is only 51 tokens. This allows an organization's decision making capacity to scale, being able to process more proposals at a given time. Problem solved, right? Well, according to DAOstack, not quite.

DAOstack raises a valid point to challenge this solution: As the minimum quorum parameter is lowered, the organization starts losing its ability to represent the general intent of its members. And as the organization scales, this minimum quorum parameter would have to be lowered again and again, until the organization can scale, but on the flipside, it also loses resilience and becomes a little flaky.

If only a fraction of the total voting power is making decisions, then complementary fractions of the voting power may not be participating in certain votes, and consequently are not properly represented by some of the decisions that are taken. And, if this happens often, misrepresentation will start to become commonplace, until eventually, the members of the organization stop believing in it. The myth begins to dissipate and the illusion begins to break. This problem results in a natural tension accumulating between an organization’s ability to scale, and its resilience —a  tension that could eventually wreak havoc in the organization.

Fortunately, DAOstack proposed a solution to the problem with Holographic Consensus, which aims to enable unlimited scalability of an organization’s decision-making power, without it ever losing any resilience.

How Holographic Consensus solves the problem

The idea is pretty neat, and quite simple one once you understand it. A proposal can have tokens staked on its outcome to predict if it will eventually end up being supported or not. "Upstaking" a proposal means betting that the proposal will be supported by voters, and "downstaking" a proposal is betting that the proposal will be rejected (either by it not gaining enough support or by the voters explicitly voting against the proposal). Once the proposal is resolved, the losing pot of the stake that predicted the incorrect outcome is split proportionally amongst the winning stakers.

So, behind every proposal, there is a miniature market that tries to predict its outcome. As a result, voters can drive their attention straight to proposals that have enough “confidence”, that is, proposals that have a proper amount of upstake vs downstake. Members have a reliable way of knowing which proposals are interesting, and it’s all accomplished in a decentralized fashion, since it’s driven by individual economic incentives.

However, the power of the protocol doesn’t end there. There’s more. If a proposal manages to achieve a significant level of confidence, and keeps it up for a while, it can get "boosted". A boosted proposal is a proposal that can be resolved with relative consensus without a minimum quorum whatsoever .

If a proposal is boosted, the total voting token supply doesn’t matter at all, only the tokens involved in the vote are counted. That is, if merely three tokens out of a total supply of 1000 were involved in the vote, and two support the proposal—66% support—that’s enough to approve the proposal! So, stakers are not only betting on which proposals will eventually be supported and signaling voters towards them, but they are actually catalyzing the decision making process dramatically.

The plan

So, the plan is to implement all this in an Aragon app. I will only assume that you are familiar with Ethereum, writing smart contracts in Solidity, and using NodeJS with Truffle. No previous Aragon experience is needed. By the end of the series, you should have built a fully fledged Aragon app, with its smart contracts, unit testing, and even a frontend that loads inside an organization and interacts with other installed applications.

Stay tuned for part 2, where we will begin building this thing from scratch. See you there!