Stealth Democracy
Sovereignty for the devil's advocate
Hey there,
We'll start our story today with notes on two charismatic founders: Elon Musk and Michael Egorov. In the past few weeks, both have experienced very interesting outcomes relating to governance in some form.
On the 13th of June, Tesla shareholders voted for Elon Musk to receive a $56 billion pay package. It had been structured in 2018 when the company was struggling to deliver orders. In January of this year, a judge ruled against the payout. While this ruling may still be in progress for weeks, here's why I found it compelling. While the board initially approved the package, a judge in Delaware struck it down. The company then went to the retail shareholders to see if the pay should be approved.
About 43% of Tesla stock is owned by retailers, compared to under 25% for both Meta and Alphabet. Large shareholders like Norges Bank (the world's largest sovereign wealth fund) and California's public employee retirement system (the US' largest pension fund) voted against the decision.
And yet, Musk came on top with 72% of the votes in favour of his payday, though a judge will still have to determine whether Musk is eligible to receive his compensation.
Elsewhere, a different story was playing out. In May 2023, Curve Finance's founder, Michael Egorov, took a $100 million loan against his curve tokens. Thanks to a hack on a completely unrelated event, Egorov's debt collateral started liquidating on Friday. Curve's price went from $0.35 to about $.25 in hours.
Noticing these events, Egerov simply tweeted, 'size of my position was too large for markets to handle'’
What I find intriguing about both founders is how governance plays a role in their paydays. Musk cannot simply print out shares and set them on fire to get more rockets to Mars. He has to go through a board, and even when the board approves, a judge can intervene. He then has to go to his shareholders to show support.
Egorov, in contrast, had his DeFi positions out in the public. Everyone knew he was taking a loan. But there were very few mechanisms to stop a founder from partially 'exiting' his project in the guise of a loan. Token holders did not have a say on whether Egorov could take a loan that was too large for the protocol to manage.
Today's piece observes this duality of governance. We collaborated with Dora Factory to understand why governance matters, the implications of bad governance tooling, and what its future could look like.
Failed States & Centralised DAOs
In 2022, Venezuela had close to 304 billion barrels of proved reserves, which should, in an ideal world, translate to rising GDP per capita. But the reality of the region couldn't be more different. Bonds linked to debt from the region are currently trading at five to ten cents on the dollar. The region is currently $154 billion in debt and has been defaulting on loans since 2017.
The national currency, the bolivar, experienced an inflation rate of 150,000% in 2018. Power outages and food and medicine shortages are daily occurrences. According to the UN, some 82% of Venezuelans live in poverty. A quarter of the region's population has fled the nation in the last decade. You can see variations of this across the globe. Emerging markets rich in natural resources often stumble without strong governance.
The writing on the board is fairly clear (*no pun intended*). Centralised strong-arm leaders result in bad outputs. Decentralised ones, with strong governance aiding them, lead to better outputs.
Better resource allocation with checks and balances makes for happy stakeholders. Crypto – or Web3, as we now refer to it – has often made this promise in the past.
In 2017, when the ICO boom occurred, projects often promised to allow users to govern resources that came to them. As the price of Ethereum surged in the years that followed, treasuries ballooned even when projects had little traction. Arca famously proposed in 2021 that Gnosis be dissolved and its token-holders be given rights to pro-rated ownership of assets owned by the DAO.
It was a precursor for what was to come. Protocols, networks, and standalone dApps could routinely claim to be decentralised, but the exact specifics of what came under decentralised governance were often not clear.
Like resources in emerging markets, assets in Web3 projects could be misused to serve the interests of a few people at the cost of many.
When a new token (like zkSync) comes to market, the incentives for teams to ensure thousands of wallets owned by the same individual are not claiming airdrops are at their highest. You want to show you have the largest community – even if it is an individual spinning up thousands of wallets. But what about when decisions are formed?
One could further argue that the transparency provided by blockchains makes it a little inefficient in the context of governance. First, if you are a large asset holder, you are incentivised to decide last, as you can sway decisions either way at the last minute. But more importantly, you can also detect how others within the network have voted.
All of this ignores how asset concentration within DAOs could affect decision making.
A research paper published in 2022 aimed to observe how DAOs' decision making is often decentralised. Many of them routinely use a delegation model to battle voter apathy. Token holders delegate their votes to a third party who is usually a prominent contributor to the network. The study computed Nakamoto coefficients for three prominent DAOs: Compound, Uniswap and ENS. The Nakamoto coefficient measures how decentralised a system tends to be.
The coefficient measured how many delegates it took to add up to more than 50% of the voting power. For Compound, it took only eight delegates; for Uniswap, around 11; and for ENS, about 18. The level of centralisation in DAOs is further raised by the fact that most tokens are not used for governance.
During the study, less than 10% of the tokens within these networks were used for governance.
One could always ask if Uniswap, Compound and ENS were failures in any way. The answer may be "no". They serve the functions they set out to serve in terms of lending or being exchanges. But their governance remains centralised. And history has ample lessons of what happens when power is centralised in a few hands for too long.
What, then, is a fix? The team at Dora Factory has been asking this question for the past three years. Some of their incentives come from the fact that, for the last decade, they have been connecting developers to developers. They were fertile grounds where multiple large-scale ideas were birthed. In the process, they observed what could go wrong when capital and pseudonymous reputations blend.
Growing Cities
DoraHacks has interacted with over 150k developers today. According to their landing page, they have facilitated the distribution of $31 million in grants so far. But that scale did not happen overnight. It took a decade.
The year is 2014. Unlike in the West, startup culture in Asia was focused on scaling quickly and building profitable firms. There was very little space for collaborative creation in the early stages. Developers who simply needed resources from other developers had nowhere to go.
DoraHacks’ organised its first hackathon in late November of that year. Over the years that followed, they became a prominent bridge between large enterprises and developers building frontier tech. Those were the years of fintech, cloud computing, and an initial bubble in chatbots. One of the things they noticed was the lack of funding for early-stage proofs of concept.
At the time, enterprises (such as Google) would sponsor a hackathon with the intention of hiring. There was very little support for founders who wanted to go ahead and build their proofs of concept into full-fledged ventures.
What if there was a better way to coordinate capital for early-stage ideas?
The infrastructure to do it was just around the corner.
By 2017, blockchains had entered the public discourse. Ethereum made it possible for developers to build for a global audience subset. Permissionless innovation was hot. DoraHacks had one of the largest developer networks in the world. Protocols, flush with tens of millions of dollars, were looking to onboard developers to their ecosystem. In those initial years, DoraHacks acted as a bridge between protocol resources and early-stage developers. But the tides were turning.
There was a gap in early-stage financing for startups at the time. VCs were building their theses. There were many options, and those deploying were often not technically adept at selecting the best on engineering merit alone. Developers were entering the ecosystem en masse, but they faced hurdles that came with the cost involved in building decentralised applications and infrastructure.
But what if a protocol could issue a grant to help with it? Protocols and cities are quite similar in that residents flock to them only if there are meaningful things to do in them. For protocols, the meaningful things are applications. For cities, they are amenities. As such, efficiently disbursing grants was one-way protocols could attract developers to build apps.
With more developers, there would be more apps, more users, and more protocol usage, or so the thinking went.
DoraHacks had been conducting hackathons for seven years at this point. And in that period, they had also created infrastructure for capital disbursal. Grant distribution was a key problem as there were few records of how money was given and what it was used for. Even when grants were disbursed, there were issues. Remember that protocols were sending hundreds of thousands of dollars on top of a couple hundred lines of code and promises to build a product.
Nothing stopped developers from simply running away or colluding with decision-makers.
One of the issues that soon became apparent is how VC-backed companies would dip into protocol grants to sustain themselves. When a firm raises VC money, it is usually for private profit. The shareholders (or owners) benefit. But what happens when they request capital in the form of grants from protocols? Distributing protocol grants would make sense if the product will be a public good.
But too often, VC-backed companies are not building public goods.
So when they do raise grants, which are non-dilutive, they take away resources that could have gone to a developer building on the protocol. It did not help that too often, there were overlaps between VC funds that backed the protocol (and thereby owned enough tokens to sway a vote) and firms with the same VC funds on their cap tables applying for grants from protocols.
The playing ground was simply uneven for early-stage developers.
Any time there is a new mechanism for sending money digitally, there is usually a phase where fraud dominates the medium. In the late 1990s, as eBay took off, vendors were often caught by surprise as they would make a shipment and wait for a bank wire to arrive. PayPal eventually fixed this. In 2023, lending protocol Goldfinch lost $7 million by underwriting bad loans in emerging markets. Part of what fixes such situations is better identification of the parties involved.
As I write this, DoraHacks has distributed some $70 million and interacted with over 120k developers, but they realised that venture-building requires effective governance.
So they set out to build Dora Factory, a suite of tools that simplify running collusion-free governance.
There are huge implications for what it enables developers to build, but before we go there, let's start with how resource distribution happens today and how Dora Factory helped improve it.
Coordination Problems
Over the years, there have been several attempts to fix the identity issue within Web3. As early as 2017, ICOs would ask community members to send in their AML/KYC documentation before token sales. Protocols must walk a fine line while asking their members to verify their identity. Enforce it too strictly, and you may lose users. Make it too loose, and fake wallets overrun the network.
One of the most common methods used to verify the validity of a wallet is to assess the assets within it. Last year, some airdrops validated wallets by checking whether they held a MadLad or Pudgy Penguin NFT. Since it costs thousands of dollars to acquire these, the probability that an individual would spin up thousands of wallets holding these is low.
A different mechanism used is DegenScore Beacon. It looks at how early a user is to a protocol and their past transaction activity to measure the value of a wallet.
While these solutions look at on-chain activity, alternative approaches consider bridging offline IRL identity with on-chain wallets. For instance, zkPass allows users to validate their real-life identity (such as with a passport) or variables (such as bank balances) using a browser extension. Similarly, Gitcoin's passport product allows users to mint stamps to validate their ownership of a Twitter handle or GitHub account.
Dora Factory's DoraID takes a staking-based approach to validating wallets.
At its core, DoraID uses cryptoeconomic mechanisms to validate identity. Instead of relying on centralised issuers (such as passports), it requires users to stake any ERC-20 token (of a developer's choosing) for a given period to validate their accounts. Users staking tokens in their system can withdraw tokens only after a predetermined staking period is over. Accordingly, this deters bad behaviour once a wallet is verified. Part of what makes DoraID interesting is that it allows for validating wallets at scale without reliance on centralised parties.
But why is any of this needed? Effective governance and capital allocation are not possible in completely anonymous networks. Economies are built on trust. When you buy milk from a local grocer, you know you are getting real milk because you have purchased milk from him hundreds of times. When you buy milk online, you partly do it because there's a platform adding trust to that economic interaction.
Identity verification in pseudonymous networks is a bridge that builds trust.
A good look at how capital is often disbursed to developers could explain why this matters. Quadratic funding is the commonly accepted method of disbursing grants through hackathons. Quite often, protocols or individual donors match donations made towards projects.
The challenge arises when a single large donor puts in a large sum of money, thereby leaving very little for other projects, even when it is a public good.
In other words, a project that receives $500 from a single donor could expect to see the same matched from a protocol. It could take resources away from a different project that saw, say, 10 individuals put in $50. Quadratic funding offers a solution to this problem by using a quadratic formula. It looks at the sum of the square roots of individual contributions and then squares the sum to look at the matching amount.
So, 10 individuals donating $1 each could receive a larger matching donation from a protocol than a single individual donating $10.
Naturally, such incentive mechanisms incentivise individuals to spin up wallets or ask friends to donate. Since the delta (extra sum received) from each fake wallet is considerably higher (due to the square of the sum being used), the incentive is strong for people to game the system. And because hackathons are a huge outlet for resource disbursal to developers, Dora Factory had to develop solutions that address these challenges.
After all, even for systems as simple as giving money away (like grants), the incentives can skew in complex ways.
1. Maybe an allocator at the protocol can expect kickbacks.
2. Or a developer could incentivise a platform (like Dorahacks) to allocate resources towards them. Reputation is a continuum.
3. Delivering on promises developers may have made in the past alone does not guarantee that their behavior will not change in the future as other incentives emerge.
4. For instance, multiple L2s could go into a bidding war to have a developer build within their ecosystem.
If all this sounds like a traditional democracy—and its corruption by commercial interests— it is because a lot of capital distribution and management has to do with governance.
Oftentimes, startups, by virtue of their positioning, see opportunity sets that may not be evident to others. Or even better – startups, by virtue of their positioning, can expand into an adjacent market where many new entrants die quick deaths. In the early 2000s, Amazon needed solutions to handle inbound traffic. So AWS started as a project to optimise their own web infrastructure. Soon, they recognised that they could commoditise it and offer it to other startups. Dorahacks was at a similar juncture.
They had access to a great deal of early-stage ventures that were launching from their hackathons. They were also interacting with multiple large protocols handling billions of dollars.
This positional wedge helped them notice how building tooling that can assist in coordinating resources could be crucial. They were not the only players working on DAO tooling between 2021 and 2023.
But the fact that they were building off a core resource – their network of developers – helped them survive the bear market, one where many other DAO tooling products failed.
Protocols for Governance
The team at Dora Factory could see how developers often collude to receive larger shares of a grant pool. Having large protocols like Cosmos, Aptos, Polygon and Solana working with them meant they were in a good spot to build tooling for governance that could be used by these large protocols. By this point, they had already developed DoraID and tinkered with a gradual taxation mechanism for quadratic funding, but more had to be done to enable strong governance.
This is where MACI and aMACI come into play.
In an ideal world, voting should have a few characteristic features.
In particular, it should be as follows:
1. Fair – You should be able to have accurate votes.
2. Anonymous – Ideally, nobody goes after a voter for voting for the competition.
3. Censorship-resistant – All votes should count, regardless of who they have gone to.
4. Collusion-resistant – Ideally, external economic incentives (bribes) don't stand in the way of decision-making.
zkSNARKs involve the use of polynomials to create and verify proofs. We won’t get into the details of how these work, but you can refer to this excellent primer by Vitalik if you want to understand the math behind them.
In the context of voting, we want to use zkSNARKs to create a system where a coordinator (vote counter) should be able to produce a result and prove that it was calculated correctly without revealing each individual vote. Such a system should also make it impractical for voters to indulge in bribery (collusion). MACI is this system.
But how does it work? You can break it down into four key parts.
Signing up – First, the user (a voter) signs up for a registry (a smart contract controlled by the coordinator) with a public key. Ideally, the user should only be able to sign up if they are able to do the following:
Prove that they are not a bot (using a mechanism such as GitHub passport)
Prove that they personally control the public key (to prevent them from using someone else's key)
Put down a non-trivial deposit (to disincentivise them from sharing their key with a third party, who would be able to steal the funds)
Meet other conditions making them eligible to vote (DAO membership, NFT ownership, etc.)
The signup smart contract also determines how many votes an eligible user gets. This is where developers can use DoraID. Requiring users to stake assets (of any amount) makes it gradually more expensive to sybil an ongoing election with each new wallet that must participate in it.
Key Change - At any time, voters can interact with the registry smart contract to change their public key. They can do this by encrypting the new public key in a message signed by their existing public key. Correspondingly, this feature is what enables anti-collusion, as we will soon see.
Voting - Voters use their public-private key pair to generate a shared key with the coordinator. Every individual voter shares a distinct key with the coordinator. Then, they can cast their vote in a message encrypted using this shared key so that the vote is only visible to the voter and the coordinator and not any other party. This makes each vote anonymous to the outside world.
Say a voter changes their public key after casting a vote. They can now cast a vote with the new public key. Doing so would override their previous vote.
Processing Messages - Once the voting period ends, the coordinator generates zkSNARKs that prove that they processed each message correctly. What does this proof include? Firstly, each vote message should be decoded correctly. Second, invalid votes – those overridden by new votes – should not be counted.
Tally Votes - Once all the messages are processed, the coordinator creates another zkSNARK proving that the valid messages processed the sum to a given tally result. This is done without revealing who any individual voter voted for. Now, anyone can use the proof published by the coordinator to ascertain that the result published comes from valid messages sent by voters.
Such proof can also be generated only if the coordinator processes all valid messages voters submit. Coordinators can't censor any votes, or they would be unable to create valid proof.
We’ve seen how MACI enables privacy, correctness, and censorship resistance. But in a hypothetical world, how do you ensure that voters do not collude amongst themselves? Part of what makes elections functional is that individuals are not expected to share who or what they voted for. In public blockchains today, this is not the case.
Here is where anonymous MACI (or aMACI) steps in.
Let's go back to our hypothetical example of a briber. Suppose there is a vote to decide if WIF should be promoted on the Las Vegas Sphere. Assume I benefit from this outcome and want to bribe Shlok to vote in favour of the proposal. Shlok shows me the decrypted message of him voting as I desire. But, remember, Shlok also has the option of changing his public key and overriding his vote. He could then decide not to show me the subsequent messages.
Knowing this, would I still pay Shlok a bribe based on the proof he shows me? Probably not, unless I have absolute certainty he voted some way, which, with MACI, I don't.
When a briber has no way of ascertaining with certainty that a voter votes a certain way, the incentive to bribe reduces drastically. MACI relies on this.
Historically, running a MACI round was not accessible to the average user. The tooling for it simply didn’t exist.
Dora Factory is interesting partly because they have combined the tooling to make this happen into a simple script. Any community seeking a collusion-free voting infrastructure could query their toolset to implement it with relative ease.
However, this implementation of MACI suffers from one major drawback. It relies too much on the operator.
First, while voters and third-party participants are disincentivised to collude, nothing prevents an operator from colluding with a voter.
Second, while the operator cannot fake voters or tamper with tallying, they can simply choose not to publish a proof at all, paralysing the voting mechanism.
To fix these issues, Dora’s team began working on the first live implementation of Anonymous MACI or aMACI. In MACI, a coordinator can act maliciously, as they can know the voter's identity if only a small minority changed their keys.
They can collude, either with the voter or an external party, to share details of how participants voted. aMACI changes this by introducing a mechanism to add anonymity to the voting process.
Recall that MACI provides users with the ability to change their public keys. In practice, this action is broken down into two messages: a key deactivation message and another message to add a new key. The key deactivation message produces a new deactivation record. Then, when a user wants to add a new key, they must reference a valid deactivation record to prove that their previous key has been deactivated.
aMACI works by the user generating a zero-knowledge proof that a deactivation record for the public key they wish to deactivate exists and that they own the private key of that public key. They do this without revealing the exact deactivation record, thus anonymising the new key from the previous key from the coordinator's point of view.
aMACI only works if most users switch the keys they used to sign up for voting. If no user switches keys, the process resembles a normal MACI round. If only a few users switch keys, the coordinator can track these users. Thus, a protocol using aMACI should encourage users to switch keys periodically to shield their anonymity from the coordinator's attention.
Here's the interesting bit. Since the keys can be changed any number of times, anybody can be an operator. That is, if a lousy operator is stalling the election results, the community can choose a different operator and re-run the election process. Effectively, the ability to periodically change keys creates additional barriers to stalling a vote.
There are two things to note here.
1. First, for a voting round that uses only MACI, replacing an operator used to be a hard task. So if, for whatever reason, an operator decided to stall votes, there was nothing you could do. One fix to this would have been to create a marketplace where operator reputation is tracked. So, depending on the nature of the vote, you hire an operator with a track record of tallying results and sharing effectively.
The operator, in turn, receives a fee. In other words, within the mandate of MACI, operators have an incentive to act well, as there are economic (and reputational) incentives for doing so. If I were an operator in a vote and simply decided I didn’t want to publish results, I may no longer have communities that wish to work with me.
2. aMACI disrupts that reliance on operators even further. Participants in a vote can simply replace the operator any number of times. This disrupts the reliance on a single operator. It opens up pathways for community ownership and truly decentralised governance.
In essence, aMACI is infrastructure for censorship resistance coordination of resources. The cost for running these votes is currently denominated in $DORA. You pay a network fee and a fee for the number of votes you participate in. Total vote expenses are proportional to the number of participants that take part in a vote.
You can read this blog post for a detailed explanation of how aMACI works.
Recall that MACI relies on zkSNARKs for the operator to prove they correctly processed and tallied the vote messages. Now, zkSNARK is a cryptographic concept that can be implemented in multiple ways, with each implementation having its tradeoffs.
To understand this better, consider the different ways writers can create a book. Most use a typewriter or a computer. However, if they want, they can produce a manuscript by hand, using pen and paper. A minority might even prefer a voice-to-text dictation tool. While each method has distinct advantages and disadvantages, they all produce the same thing: a book with the author’s ideas.
Similarly, zkSNARKs have various implementations like Groth16, Pinocchio (created by Microsoft), Libsnark (created by Zcash), Circom, and more.
MACI was originally built using the Groth16 implementation of zkSNARKs. Before a prover can create proofs or a verifier can verify them, Groth16 requires the generation of a common reference string (CRS).
A CRS is a publicly known string of data generated during the setup of a zkSNARK proving system. It contains an encoding of the rules and parameters necessary for generating and verifying proofs and must be developed in advance by a trusted party. Also, the information used to generate a CRS should be destroyed as soon as the CRS is created. Otherwise, it can be used by malicious actors to forge fraudulent proofs.
The CRS generated in a Groth16 setup is unique to a particular circuit (a circuit is the zk interpretation of a program). If there was even a slight change in the circuit–say, the correction of a bug or the change in the parameters that made a voter eligible–the CRS would have to be generated again. Generating the CRS is a security-critical, resource-intensive process. Regenerating it each time there is a change in logic is not scalable.
This prompted the Dora Factory team to move from a Groth16-based implementation of MACI to a PLONK-based one. The zkSNARK proofs created using PLONK create a structured reference string (SRS) instead of a CRS that can be shared amongst different circuits below a certain bounded size. This meant that if there was a small change in the logic of the program, the expensive setup phase would not have to be repeated.
But remember, each implementation has tradeoffs. While PLONK makes the trusted setup process easier, it generates larger proofs that require more memory and compute resources to verify. The gas fees to validate these messages increase by ~50%. This tradeoff was deemed acceptable by the Dora team, given the added flexibility and scalability PLONK provided them.
You can dive deeper into the flavours of zkSNARKS here. Dora Factory has been using MACI in their hackathons since at least 2022. In 2022, ETHDenver used a MACI voting round to determine winners. In fact, if you go here, you can still download all the proofs used to manage the votes and final tally.
Later that year, DoraHacks also partnered with OpenSea and Replit to conduct a hackathon involving $45k in grants. DoraHacks has also been using live implementations of aMACI since 2024. ETHVietnam, in March of this year, used a variation of aMACI to determine winners.
So far, we have gone through solutions for reducing collusion and ensuring people can do it anonymously. But what's the point if the voting itself cannot scale? Placing a vote on Ethereum today can cost anywhere from $5 to $20, depending on gas costs at the time of doing the transaction. There is also the fact that each vote tends to be a new smart contract.
So, if you need consensus from large numbers of people on large numbers of decisions, you will not be able to affordably do it on a high-cost network. This is partly why many of the DAOs that exist today rely on low-cost networks like Polygon.
But while most networks are focused on fees (like Base), the tooling needed to replicate MACI and aMACI is not easily available. So, if you are a developer building a consumer application (like Mirror or Farcaster) that requires constant, crowd-sourced selections (more on this soon), you will be in tough luck trying to create a collusion-free voting infrastructure. Dora Factory addressed this issue by creating a standalone chain that combines these modules.
Dora Vota
Last year, Dora Factory released Dora Vota, a Cosmos-based chain that makes it easier to coordinate resources in a cross-chain world. Any IBC (Interblockchain Communication Protocol)-based token would be able to use Dora Vota to conduct MACI or aMACI-based voting rounds. Think of it as a chain that specialises in voting. Earlier this year, when we spoke with Sunny Aggarwal, one of the earliest developers at Cosmos, one of the challenges he mentioned was rent-seeking.
Even when great developers build on them, ecosystems tend to struggle if early adopters do not support new ventures within them. Vota acts as a bridge for decision-making on one chain and resource allocation or tooling from another. For instance, running a native QF round is not possible on the Cosmos hub today. Vota bridges that gap.
So, theoretically, it opens up avenues for developers to seek resources from multiple ecosystems without relying on a single network. Think of it as the lowest-cost infrastructure for conducting a high number of votes with the least degree of collusion and the most anonymity.
In August 2023, Dora Factory tied the DORA token to Vota. The token is designed to be used as fuel within the network. In the future, it is anticipated that users will pay in $DORA to start a voting round, too. Alternatively, anybody running voting rounds can sponsor the round in $DORA. Markets have begun noticing how these toolsets come together.
In May, the Cosmos ecosystem approved a $1 million grant to conduct ten rounds of quadratic funding donations.
Big Governance
At this point, we have gone deep into the technical aspects of this system's operations. But what’s the economic rationale for it? To understand what is at stake, we need to give each vote a dollar figure to each vote. Now, there are multiple ways to get behind this number. One way would be to assess the amount of money spent to acquire individual votes. This would make sense if it were a single decision.
India, one of the world's largest democracies, had spent about $16 billion gathering votes from 960 million voters. That comes to about $16.5 per vote. A different way to value the vote would be in relation to the region's GDP. A decision pertaining to a region with a GDP of $4.1 trillion was made by 960 million people or about $4.2k per vote. However, value is subjective, and since I’m not spending my time corrupting democracies, going further down that rabbit hole makes no sense.
But think of it this way: If you can calculate a voter's impact based on a DAO's revenue, you can sway decisions when it is profitable. This is the argument made by Joel Monegro in 2020. His approach to valuing a decision involved looking at the total number of coins involved in a decision and multiplying it by the price of the asset.
According to his example,
To explore this back-of-the-envelope style (i.e., imperfectly), let's consider ZRX, which is used to vote on 0x governance. Some 6.5 million ZRX tend to vote on each decision, which, at ~$0.20 per token, implies there's $1.3 million backing each decision. However, that number is not the actual cost of the decision.
On Compound, you can borrow ZRX at ~3.30% APR, which means it would cost about 590 ZRX in interest to borrow that much ZRX for a day in order to vote. This means that, under similar conditions, the total cost of the next decision would be about $120 (at $0.2/ZRX), and the marginal cost per vote would be just about $0.000018.
But here’s the kicker: A DAO may have hundreds of decisions being made in a given year. So, in 0x's instance, you may have to multiply that $120 by 100 to get the 'true cost' of governing 0x. That is still crude math. A different way to look at it is to determine what portion of an asset's revenue is at risk from what number of voters.
In a hypothetical example, let us take MakerDAO. Over the past year, they made $250 million in revenue, according to TokenTerminal. In their last governance decision, the governance forum had 101k MKR (worth $234 million) supporting the decision. But there were only 33 people in support of it. The nuance could be that the figure is so low because Maker uses delegates.
But it makes one wonder, is each voter (with delegation) really worth $7 million (234 million/33)?
It is incredibly hard to assess the true value of a vote, but that is beyond the scope of this article. I'll spare you from reading about more statistical crimes, but here’s the point:
For the past five years, we have been investing in increasingly complex mechanisms to drive governance. Protocols spend more money on airdrops and decentralising themselves as they have no mechanisms to do these things properly today.
The question then becomes, 'Can you model the value of better governance?'
We know statistically that more decentralisation and stronger governance lead to better economic outputs. How much would a firm be willing to give up if it had the necessary infrastructure?
There are two ways to calculate this. One is that a very small portion of total fees is generated by prominent blockchains and their dApps. The assumption is that a small 'tax' for governance can be baked into the ecosystem to strengthen decentralisation further.
According to TokenTerminal, cumulatively, $18 billion in fees have been generated on-chain since 2021. If we presume a tax rate of 1%, there's some $180 million pursuing governance over the past two years. Now, you can get creative and argue the cost of governance should be 5% – and that would take you to $900 million.
Much like taxes in the real world, these numbers are subjective. But accounting for the following facts,
TokenTerminal does not account for emerging chains (like Solana), and
there are multiple large dApps on those networks.
It is safe to presume that across the cross-chain world (including Bitcoin, Solana, and Cosmos), there may be some $2 billion for capture by governance infrastructure. That is assuming that in the next five years, across dApps, revenue will scale to $40 billion, and 5% of it could go to governance. The doubling of revenue is pessimistic. The 5% allocation towards governance could be optimistic.
But by crude math (yet again!), Stripe processes about $1 trillion in volume, and its valuation is at $65 billion with a take rate of 0.8%.
There's a reason I draw that comparison. I believe, in the future, governance could be as mundane as swiping your card. What would that look like?
Beyond Grants
So far, we have looked at DoraHacks purely through the lens of grants and protocol governance. But if you zoom out, it becomes fairly apparent that the infrastructure can be used for any use case requiring real-time consensus formation. Currently, most networks run on validators that come to some form of consensus after every block, which is machine-driven consensus. But what if human consensus was used for driving products?
The unit economics of governance is intriguing. When conducting a vote is expensive (like in a parliamentary election), we do it less frequently, leaving time and resources in centralised hands for a long time. When the cost of conducting elections (or decision-making) decreases, we do it more frequently, producing faster decision-making.
As voting becomes cheaper, we'll have more ways to tap into the wisdom of crowds. Platforms use this knowledge today.
During the early 2000s, when Google was in its infancy, it used Pagerank to differentiate itself from its peers. It gauged which websites received the most human traffic and ranked them in search queries. Each user's clicks amounted to a vote. Similarly, Reddit and Hackernews evolved to surface content that is 'human' consumption friendly by using upvotes instead of algorithms.
What if every like on Farcaster was recorded on-chain? What if an Audius stream could be recorded on-chain? If you consider user interactions with products as votes – either in the form of monetary spending (such as a swap on Uniswap) or attention (time spent reading an article) – you will see why Vota is intriguing.
For example, if large numbers of users swap with a pool on Uniswap, you can argue that trend is a measure of that pool's legitimacy.
In this instance, each swap is a vote towards that pool. The same applies to Web3 native social networks.
What’s the point of these things? They create open-source, crowd-sourced and community-owned alternatives to human curation. As more retail users come on-chain, an open web of verified pools or content streams is highly desirable. Presently, Web3 native social networks monitor user engagement to surface interesting content. So, a tool could measure the number of mints or re-casts on Farcaster to determine whether a piece of content is viral.
This works because the cost of minting or recasting is negligible. But by using a tool like DoraID, you can tie economic validation to a user's behaviour within a product.
Arguably, Web2 scaled without any of this. Your pesky cousin doesn't share controversial content on Facebook because it would reflect on his reputation. Similarly, Spotify has an incentive to deter malicious content from its platform as there is reputational damage associated with it.
Web3 networks (and products in general) being pseudonymously developed means they have lower reputational risks. In the heyday of DeFi, developers commonly shut down one protocol and spun up another. Test in prod or something like that. Anyway, I digress.
Using a governance tool for content moderation may sound far-fetched. But there is a different part of the market where it may be incredibly useful today: prediction markets. Quite often, resolutions for prediction markets can be centralised, which leaves users at the mercy of the platform. Conversely, if resolutions are left to the mercy of the crowds–one where every user has a vote – votes could be manipulated.
VCs routinely wait for a lead investor to commit before they join a round. VCs are often incentivised to wait until someone with social clout enters the round. But what if fundraising platforms like Echo (by Cobie) or Angellist abstracted elements of who comes into the round or how much is being raised? There are two ways it could play out. One is that rounds would take longer to close. The other (and more desirable) outcome could be that founders would be able to close raises faster as people would be making independent decisions.
Taking such an approach to fundraising helps form on-chain cap-tables from the get-go. This also allows backers in early-stage products to track how resources are spent (presuming they raised stablecoins) whilst being able to criticise how management is running a venture. Such a stack requires multiple toolsets – but Vota's specific fit is for the mandate of making it easier to raise and allocate capital and source decisions from backers.
This may seem far fetched because venture funding has multiple moving parts. But there are places where it could be implemented right away. Elections that function better when nobody knows who selected whom, could be using Dora Vota. One place, would be art related selections. Like at the Grammy’s. It may be a while before we upend how creatives are awarded, but a likely candidate to embrace aMACI in elections is college elections as they are usually early adopters.
This logic could extend to nation-states. Part of what makes modern nation-states interesting is referendums. When citizens feel they are no longer heard or valued, they can rally together and run a referendum, the most recent prominent being Brexit. What if there was a mechanism to conduct referendums more frequently?
In an ideal, utopian world, the French president would have been able to conduct a referendum before allocating resources to the Olympics. Or a city mayor could be voted out after a few quarters as the infrastructure to voice dissent exists.
Community ownership without participation and governance is a lot like a peanut butter and jelly sandwich without the peanut butter and jelly. When token prices fall, even the bread gets stale. The fix is better governance.
I know, I know, I'm getting ahead of myself here. My point is that as the base layer and tooling for governance improves, the design space for what is possible rapidly evolves. What we really have with Dora Factory is tooling. It provides a standard, as open as what NFTs were. It remains to be seen what can be built on top of them.
They are ultimately tools for coordination.
Their uses are only limited by imagination.
Reading the great degeneration,
Joel John
Note: An earlier version of this article suggested Curve’s token were being burnt to restore prices. As one of our readers pointed out, it was fake news and linked to a scam link. We apologise for the error.
There is no vote to burn any CRV to stabilise the price, the link is a scam.
Great stuff