The Other Side of DAO: The Rise of On-Chain Vote Buying and Dark DAOs

Source: DAOrayaki

Blockchain seems to be the perfect technology for online voting. They can act as a "bulletin board," a global ledger that has been hypothesized (but never truly realized) in decades of electronic voting research. Even better, blockchain enables smart contracts, which can autonomously execute on-chain elections and exclude election authorities.

Unfortunately, smart contracts are not only suitable for elections but also create favorable conditions for vote-buying. In this blog post, we will explain how and why this is the case.

As a case study, we will present a simple bribery attack fully implemented against the popular on-chain CarbonVote system. We will also discuss how trusted hardware can enable more robust vote-buying techniques that seem difficult to address even under the most advanced cryptographic voting protocols.

Finally, we introduce a new form of attack called Dark DAO, which should not be confused with "Dark DAO," just as DAO should not be confused with The DAO. Dark DAO is a decentralized cartel that buys votes on-chain in an opaque manner (i.e., "in the dark"). We propose a specific implementation based on Intel SGX.

In such an attack, it may be impossible for anyone, even the creators of the DAO, to determine the number of participants, the total funds committed to the attack, or the exact logic of the attack: for example, the Dark DAO could attack token projects like Tezos, secretly accumulating their tokens until it reaches some hidden threshold, and then instructing its members to short. Such Dark DAOs also have the unique ability to execute information asymmetry by sending, for example, deniable airdrop notifications: members within the cartel will be able to verify the airdrop signals, but they themselves can generate seemingly real false signals and send them to outsiders.

The existence of trust-minimized vote-buying and Dark DAO primitives means that all users of on-chain voting are vulnerable to the binding, manipulation, and control of oligarchs and coercive forces. This directly implies that all on-chain voting schemes will inherently degrade into oligarchy if users can generate their own keys outside of a trusted environment. This model is widely recognized as being fundamentally inferior to democratic models, while such protocols attempt to approach democratic models on-chain.

All our schemes and attacks are conducted without considering identity control, allowing users' behaviors to be freely bought and sold. This means that schemes relying on user-generated keys tied to user identities, such as uPort or Circles, are inherently and fundamentally also vulnerable to arbitrary manipulation by oligarchs. Our schemes can also be repurposed to attack proof-of-stake or proof-of-work blockchains and profit from them, which poses serious security implications for all blockchains.

Current Blockchain Voting Mechanisms

Today, blockchain voting schemes are everywhere. Votem is an end-to-end verifiable voting solution that allows voting via mobile devices and uses blockchain as a secure venue for publishing and tallying election results. The popular smart contract IDE Remix provides an election management smart contract as a training example.

On-chain voting faces many challenges, including privacy, latency, and scalability. These are not unique to the voting mechanism itself, and all of these are ultimately surmountable. Vote-buying, however, is another matter.

In political systems, vote-buying is a pervasive and corrosive form of electoral fraud that has a long history of undermining electoral integrity worldwide. Sometimes, the cost of buying a vote is equivalent to a beer. Fortunately, as scholars have observed, normal market mechanisms often collapse in vote-buying for three reasons. First, vote-buying is criminal in most cases. In the United States, this can lead to penalties under federal law. Second, in the case of secret ballots, it is difficult to enforce compliance. Voters can superficially accept your bribe (simply by drinking your beer) and then vote secretly according to their preferences. Third, even if voters do sell their votes, there is no guarantee that the other party will pay.

Such barriers do not exist in blockchain systems. Using the same powerful election management tools: smart contracts can effectively run a vote-buying market. As usual, the complexities of pseudonymity and jurisdiction provide (some) protection against prosecution.

In general, electronic voting schemes are harder to prevent fraud in some respects than in-person voting and have been a topic of interest in academia for years. David Chaum early introduced a fundamental building block for anonymous mixing networks for messages that can be sent and received anonymously by participants, containing receipts. This end-to-end verifiable voting system, where users can check that their votes are counted correctly without sacrificing privacy, is not only a theoretical domain but has been practically used in binding elections.

Later work by Benaloh and Tuinstra questioned electronic voting schemes, pointing out that they provide voters with a "receipt" that offers cryptographic proof of a given voting method. This would allow for extremely efficient vote-buying and coercion, which is clearly an undesirable attribute. The authors defined a new property called receipt-freeness to describe voting schemes where such cryptographic proof is impossible. Further work by Juels, Catalano, and Jakobsson simulated stronger coercive adversaries, showing that even receipt-free schemes are insufficient to prevent coercion and vote-buying. This work defined a new security definition for voting schemes called "coercion resistance," providing a protocol where malicious parties cannot successfully coerce users in a way that could change the election outcome.

In their work, Juels et al. noted that "the security of our construction relies on… key pairs generated by a trusted third party, or on a computationally secure key generation protocol that relies on interaction among participants." The assumptions of "trusted key generation," "trusted third parties," or "trusted setups" are standard in the academic literature on coercion-resistant voting schemes. Unfortunately, these requirements have not translated into permissionless models, where nodes can move back and forth at any time without prior knowledge of each other. This (to some extent) naturally implies that users generate their own keys in all such deployed systems and cannot leverage trusted multi-party key generation or any centralized key service arbitrators.

Today's blockchain space, with predictable results, will continue its tradition of ignoring decades of research and choose to implement the most naive forms of voting: calculating token-weighted votes directly in a bourgeois manner, stored in plaintext on-chain. Unfortunately, it is still unclear whether anything better than this tyranny can be achieved on-chain. We demonstrate that permissionless models are fundamentally detrimental to voting. Despite any identity-based or second-layer mitigation attempts, all permissionless voting systems (or schemes that allow users to generate their own keys in untrusted environments) are vulnerable to the same style of vote-buying and coercion attacks. Many vote-buying attacks can also be used for coercion, binding users to specific voting choices through force.

"Your on-chain voting is quite nice…"

Notably, Vitalik Buterin partially explored the severity of bribery attacks in such protocols but did not provide specific mechanisms. This paper describes frictionless mechanisms useful for voting, identity purchasing, coercion, and advanced coordination, and discusses the implications of these specific mechanisms.

Different Characteristics of Attacks

Consider a very simple voting scheme: a token holder gets one vote for each token they hold and can continuously change their vote until a certain ending block number. We will use this simple "EZVote" scheme to build intuition on how our attacks work in any on-chain voting mechanism.

This scheme has several possible upgrade attack vectors.

(1) Simple Smart Contracts

The simplest low-coordination attack on an on-chain voting system involves bribing a smart contract. Such a smart contract would simply pay users based on provable votes for one option (or participation in voting, or abstention if the vote is not anonymous). In EZVote, the smart contract could be a simple contract that holds your ERC20 until after the end date, votes in favor, and then returns it to you; all guarantees in the contract can be enforced by the underlying blockchain.

The advantage of this scheme is that it only requires the trust assumptions already inherent in the underlying system, but it also has significant drawbacks. On one hand, it is possible to publicly disclose how many votes were purchased after the election ends, as this is necessary for handling payment flows in today's smart contract systems. Additionally, the nature of the bribery platform makes it subject to scrutiny from parties interested in maintaining the health of the underlying platform/system.

Depending on the nature of the voting scheme and the underlying protocol, there may be some ways to address these drawbacks. For example, voters could provide ring signatures to vote buyers, proving they are on the list of voters who voted in favor in exchange for payment. We will keep the implementation details and generality of these schemes open.

In general, any mechanism used for private smart contracts can also be used for private vote-buying, addressing the public nature of smart contract-based attacks; in cryptographic terms, the equivalent is that the vote buyer and seller generate keys for fund storage together via MPC, signing two transactions: one agreeing to vote and the other releasing funds to the vote seller after the interval ends. Only after having guaranteed refund and payment transactions will the vote seller transfer funds to that key.

This looks similar to previous work in distributed certificate generation, adding security analysis to ensure fairness. A simple implementation of such a scheme would hinder users from using funds for other purposes during the voting period (such behavior is possible but requires cooperation representing the vote buyer; alternatively, a trusted/custodial escrow could be used).

Trusted Hardware Purchases

A more concerning vote-buying attack scheme involves using trusted hardware, such as Intel SGX. Such hardware has a key feature called remote attestation. Essentially, if Alice and Bob are communicating over the Internet, SGX-enabled trusted computing allows Alice to prove to Bob that she is running a certain piece of code.

Trusted hardware is often viewed as a way to prove that the code you are running is not malicious: for example, it is used in DRM to prove that users will not copy files that are only temporarily authorized to them, such as movies. Instead, we will use trusted hardware to bind cryptocurrency users, paying or coercing them to use trusted hardware-based cryptocurrency wallets, which can prove to restrict the space of behaviors they are allowed (for example, by forcing them not to vote in a certain way in an election) or allow buyers to trust minimally but restrict the use of users' keys (for example, a vote buyer can force a user to sign "I vote A," but cannot steal or spend the user's money).

The simplest way to use such technology for vote-buying is to simply allow users to prove they are running the vote buyer's malicious wallet code in exchange for payment, with both parties protected by remote attestation technology.

In our "EZVote" example, users simply use a cryptocurrency wallet loaded on Intel SGX to run the vote buyer's program. SGX will assure the user that the wallet will never steal their money (unless Intel colludes with the vote buyer). Users can prove that they can use the wallet to do everything they could do with a regular Ethereum wallet, including transferring their money out (though in this case they would not be compensated). Users run their own wallets without needing to trust a third party to control or secure their funds. Users may not even need to trust Intel or the trusted hardware vendor to ensure their funds are safe, as they can compile their own wallet!

When predefined trigger conditions occur, such an SGX program will automatically vote on EZVote according to the vote buyer's commands and send receipts to the vote buyer. The buyer themselves will run an SGX enclave that maintains the total number of users who claim to have voted in favor, as well as their address list. Given trust in the new exchange, the buyer does not need to see the complete list of member users or know the total staked amount. At the end of the voting period, the vote buyer's enclave will pay all users who have not moved funds or changed their votes. This will be accomplished by periodically publishing Merkle roots from the enclave, summarizing the users to be paid on-chain and providing each user with evidence that they will ultimately receive payment. Users can request payment after a certain period by providing proof included in the published Merkle history. In some particularly vulnerable voting designs, the SGX enclave can improve efficiency by simply pre-collecting users' "consent" votes as transactions, publishing them at the end of the voting period, and providing them with payment.

Hidden Trusted Hardware Cartel (Dark DAO)

When trusted hardware is combined with the concept of a DAO, more concerning attacks emerge, resulting in a trustless organization aimed at manipulating cryptocurrency voting.

An Example of a Basic Dark DAO

The above diagram outlines a possible architecture. The vote buyers will support the DAO by running a network of SGX enclaves, which themselves execute consensus protocols (shown here as dark clouds to indicate their invisibility from the outside). Users will communicate with this enclave network and provide evidence that they are running a "vote-buying" (for example) Ethereum wallet with a current balance of X coins. This "evil wallet" proves that it is running the attack code paid for by the vote buyer, while the vote buyer proves that the code they are running guarantees payment to users at the end of the attack (potentially in conjunction with smart contract-based protocols that enhance vitality and honesty in the cryptoeconomy).

Vote buyers can track the total amount of funds committed to voting through the system, using the built-in privacy features of the new exchange to hide this fact from the outside world. Users can obtain provable payouts by participating in such a system, achieving all-or-nothing settlements in decentralized exchanges based on the new exchange. Vote buyers can obtain provable guarantees that clients will never cast votes contradicting the voting policy they desire.

What makes such an organization dark is that the vote buyers do not need to disclose to anyone (even possibly themselves) how many users are participating in the system. The system can simply accumulate users, paying them to run the attacker's custom wallet software until some threshold is reached to activate the attack (for example, the coins held by such software); in this way, there is no need to detect failed attempts. More destructively, the individual incentives of any small user clearly point towards joining the system. If small users believe their votes are inconsequential, they may receive rewards without perceiving marginal declines. This is especially true in on-chain voting, where historically low turnout rates have been observed. Non-voting users may be ideal targets for selling votes.

Dark DAO operators can further muddy the waters by launching attacks on choices that the vote buyers actually oppose, using them as potential false flag operations or smear campaigns; for example, Bob could run a Dark DAO favorable to Alice to legitimize an election outcome that Bob believes he might fail. Activation thresholds, payment schedules, overall attack strategies, the number of users in the system, the total amount committed to the system, etc., can all be kept secret or selectively or globally disclosed, allowing such DAOs to ultimately adjust to structured incentive changes.

Since the organization exists off-chain, the cartel of block producers or other system participants cannot detect, scrutinize, or prevent the attack.

Such a dark organization has several direct practical drawbacks. Foremost is that using Intel SGX requires permission from Intel, which is unlikely to occur for malware. Additionally, side-channel attacks, hidden software backdoors, or platform attacks or audits of Dark DAO wallets in Intel SGX could undermine the scheme, although the costs of such attacks are likely to increase significantly with the ongoing advancement and development of trusted hardware. Ultimately, we hope that other trusted hardware will provide remote attestation capabilities similar to Intel SGX, meaning such attacks would not require SGX; this is why we interchangeably use "SGX" and "trusted hardware." For example, remote attestation can be implemented on certain Android secure processors. Our schemes apply to any hardware device that allows for confidential data and remote attestation.

Attacks on Classic Schemes: CarbonVote and EIP999

To demonstrate the effectiveness of these vote-buying strategies, we first look at governance key coin voting executed in existing cryptocurrency systems. Perhaps the most significant of such votes is DAO CarbonVote. The operation of this vote is simple: accounts send funds to one address to vote in favor and another to vote against. Each address is a contract that records the votes for that given address. The CarbonVote frontend then tallies the votes and displays the net balances of all accounts that voted in favor and/or against. Later votes replace previous votes, allowing users to change their minds. At the end of the voting period, a snapshot of the support situation is taken and used to gauge community sentiment. This voting method has been reused for other controversial ecosystem issues, including EIP-186.

One possible trust-minimized vote-buying smart contract in this framework involves using escrow; users send Ether to an ERC20 token contract, which holds the Ether until the voting ends. For each Ether they deposit, users receive 1 VOTECOIN.

The contract is pre-programmed to vote in favor at the end of the voting period, holding 100% of the users' Ether. After the voting ends, each VOTECOIN token can be fully refunded to the original Ether that created it. Users retrieve their original Ether, along with any bribe the vote buyer wishes to pay them for this service.

We have implemented a complete open-source proof of concept for such contracts, allowing any vote buyer to fund the contract's BRIBEPOOL. Users can pay from the BRIBEPOOL by temporarily locking their Ether in the contract and can reclaim 100% of their Ether at the end of the target vote. Attacks can be pre-paid from the BRIBEPOOL to the vote seller (once they lock the tokens, the vote is guaranteed), over time as bonuses, or both.

Voting code for Ethereum smart contracts to purchase votes for DAO CarbonVote

Users can also sell their VOTECOIN after locking their Ether, effectively making VOTECOIN a tokenized vote-buying derivative. The vote seller can then immediately offload any risks associated with locking funds to parties indifferent to the voting outcome: since each ERC20 is programmatically guaranteed to ultimately receive all original ETH, this effectively transforms the underlying asset into a derivative asset specifically for voting in a predefined manner. If guaranteed non-negative returns, buyers uninterested in the voting outcome should always lock their ETH and can essentially choose to offload it later to other equally uninterested buyers. If the BRIBEPOOL's bonuses are paid over time in addition to pre-payment, these derivative tokens could even be used to speculate on whether the attack itself was successful.

This smart contract can be simplified by using oracles such as Town Crier (or combining multiple oracles, prediction markets, etc.). Because the CarbonVote system publishes results including a complete voter log on Etherscan, it is relatively simple to use any external network scraping oracle to check how someone voted, and if the vote included in the final snapshot aligns with the buyer's preferences, payment is made.

Similarly, a model akin to Dark DAO can be easily employed. Each user simply runs a wallet that also votes on CarbonVote in the desired manner at some point after each transfer transaction (this could effectively become standard behavior for many wallets). Users will only be compensated after such votes are registered, incentivizing them to ensure that this voting transaction is included on-chain. The network cannot determine how many votes in a given CarbonVote were generated by such vote-buying cartels and how many were legitimate.

Any of these schemes inherently minimize trust when pooling assets among multiple vote buyers; bribery smart contracts can simply allow anyone to pay into the BRIBEPOOL, and the architecture of the new exchange network can similarly open participation.

Some schemes, such as EIP999 voting, have more serious issues. In these schemes, if a user votes twice, the later vote is chosen. A simple yet severe attack is to simply collect users' signatures for both "yes" and "no" votes and spam the selected signatures at the end of the election period, relying on the ability to overwhelm the blockchain to ensure that most of such votes persist. Alternatively, because the contract deployer can vote for all funds in a given contract, another attack is to simply coerce users to use a contract-based wallet deployed by the vote buyer during the voting period, allowing them to arbitrarily control the voting rights of all funds locked in the contract without holding custody of those funds.

Bitcoin is not immune either. The Bitcoin community often relies on coin voting, and similar vote-buying schemes can be applied (such as Ethereum smart contracts in this work, or Dark DAO style; Bitcoin itself does not provide native support for sufficiently rich contract purchases of votes).

Beyond Voting------Attacking Consensus

Astute readers may point out that all permissionless blockchains essentially rely on some form of permissionless voting, namely the consensus algorithm itself. Whenever a blockchain reaches global consensus on certain properties of the state, what happens is essentially permissionless (often coin or PoW-weighted) voting in a permissionless setting.

In these cases, "vote-buying" has already been explored to some extent, which may not be surprising. For example, smart contracts on Ethereum can be used to attack Ethereum and other blockchains through censorship, historical revision, or incentivizing empty blocks. This attack directly targets the proof-of-work voting itself, bribing miners based on their weighted work. There is little reason to believe that proof-of-stake systems would be immune to similar attacks, especially in the presence of complex delegated voting structures, where incentives may be unclear and formal analysis may be incomplete or nonexistent.

A disturbing concept related to the Dark DAO we explore is what we call "Fishy DAO," named after a classic Flash game. In this (super fun!) game, you start as a small fish. The rules are simple; you can eat smaller competing fish but cannot eat fish that are the same size or larger than you. After each meal, you grow a little bigger until you eventually (if you're lucky) grow to dominate the ocean. A modern similar game that does not require Flash and adds networking is agar.io.

Just like Fishy, but small fish can also ally with big fish!

Fishy DAO will use the above-mentioned Dark DAO-like techniques to do the same for blockchains. Using SGX, Fishy DAO members can receive non-transferable notifications (DAO members can verify the authenticity of messages, but non-members cannot determine whether the messages are forged) when the attack threshold is reached, allowing them to short the currency market shortly before such attacks occur. Each Fishy DAO attack on a blockchain brings some profit to Fishy DAO, and even failed attacks can lead to publicity that makes Fishy DAO notorious for pursuing profits but potentially unethical (in some frameworks). If Fishy DAO fails to reach the required threshold, it will simply disappear and refund its participants, possibly but not necessarily burning some of their money to incentivize them to recruit participation.

Fishy DAO requires Dark DAO technology, as observable participation would provide market signals for the underlying blockchain's price, making attacks unprofitable by allowing risk pricing. It is precisely the information asymmetry between DAO members and broader ecosystem participants that makes such attacks possible.

Other Applications

Note that the implications of Dark DAO extend far beyond the above scope. For example, a Dark DAO could aim to profitably purchase users' basic income identities, prepaying small fees to obtain users' regular basic income payments. Or a Dark DAO could conduct credit checks by renting such keys from creditworthy users (with minimal trust constraints) to facilitate key-based identity verification. Alternatively, a Dark DAO could run an evil mining pool that can prove attacks on ASIC-based proof-of-work cryptocurrencies, with the scale of its attack pool potentially undetectable and unstoppable.

It is also conceivable that with identity, the identity system itself could have social security against purchasing behavior. For example, certain identity systems might allow users to appear in person to revoke or manage their identities, which could circumvent automated technological protections against identity theft in society. There are still ways to address this: a classic solution for loans is through collateral. Potential "guarantors" like businesses could also provide social repayment guarantees for users who cannot afford collateral through physical/legal intimidation and contracts. If such a permissionless basic income system is deployed alongside current market systems, payday loan and bail bond agencies would be very suitable for such business, at least in the United States (in many other places, there may be less popular institutions willing to intervene for appropriate cuts).

The coordination space of blockchain mechanisms is vast, and the environment is harsh. All identity-based schemes for voting or financial incentives should be very cautious about the implications of the underlying permissionless model on long-term viability, scalability, and security.

Core Insights

Perhaps you are a scholar browsing this article or an interested user wondering what all this means. From our thought experiments above, several interesting and very surprising insights can be drawn (see references).

• Permissionless electronic voting requires trusted hardware. Perhaps the most surprising result is this. In any model where users can generate their own keys (as required by the "permissionless" model), as described above, using trusted hardware, low-coordination bribery attacks are essentially possible. The only defense is more trusted hardware: to know that users can access their own key materials (and thus cannot be coerced or bribed), it must be guaranteed that users have seen their keys. Trusted hardware can achieve this through trusted hardware token setups (similar to how governments use electronic voting for democracy) or through SGX-based systems that guarantee any voter has disclosed their key materials to any operating system they are running. This essentially realizes the kind of trusted setup/generation assumptions that academic electronic voting schemes have been using for years. Clearly, any voting in the presence of trusted hardware requires such assumptions, and in the absence of this assumption, it can be proven that low-friction purchasing/selling/bribing/coercing votes is possible, which is a surprising result with serious implications for on-chain voting.

• The space of voting and coordination mechanisms is vast, and people know very little about it. Through specific examples of how to handle things, such as smart contract voting on Ethereum and voting changes, it is clear that broad design decisions fundamentally alter the incentive structures of voting mechanisms (we explore these in Appendix A below). These mechanisms are extremely complex and can change their incentive structures through other coordination mechanisms, such as smart contracts and trusted hardware-based DAOs. The characteristics of these mechanisms, especially when multiple such mechanisms interact or are actively attacked by resource participants, are poorly understood. Such mechanisms should not be used for direct on-chain decision-making in the short term.

• The same class of vote-buying attacks applies to any identity system. These attacks are not just for votes. Imagine an identity system that grants users the right to a basic income payment every week. I could simply prepay cash to purchase your identity, thereby buying a share of next year's income, if my funds' time value is lower than your time value, I should indeed do so (as wealth asymmetries often imply). Any system involving identity is thus: under relatively low trust, behaviors constraining user identities can be bought and sold in the open market. This has serious and fundamental implications for the robustness of any on-chain economic mechanism with permissionless identity components.

• On-chain voting fundamentally degrades into oligarchic rule. Voting and democracy fundamentally rely on the assumptions of anonymous voting and identity infrastructure that only exists in the physical world (meatspace). These assumptions do not carry over to blockchains, making the same technology fundamentally break down in permissionless models. As long as users can generate their own keys (see above), external, even trusted identity systems cannot solve this problem.

• Governance based on hard forks provides users with the only exit from this oligarchic rule. Given the above circumstances, a natural question to ask is whether we have already entered the era of oligarchic rule. The answer is "perhaps not." There is evidence that the temporary, informal, fork-based governance models managing blockchains like Bitcoin and Ethereum actually provide strong protections for user rights. In this model, any upgrade must provide users with active choices, and if they disagree with rule changes, user groups can choose to exit. On the other hand, on-chain voting creates a natural default, especially when combined with distracted or indifferent users, leading to strong anti-fork inertia.

• Interactions between multiple blockchains can undermine the incentive compatibility of all chains. Importantly and critically, the Fishy DAO-style attacks we explore indicate that multiple competing blockchains have the capacity to fundamentally affect the internal balance of all such chains. For example, in a world with only one smart contract system, Ethereum, internal incentives might lead to stable equilibria. With two players, where the weaker is incentivized to initiate bribery attacks to destroy their competitor, this balance could be disrupted, altered, and undermined. A key and surprising open research area is the macroeconomic modeling of competition between blockchains, deeply understanding how this internal equilibrium fails. We intuitively find that key black swan events currently lurk within the complexities of blockchain governance and interoperability.

Clearly, these all require further exploration, refinement, and proof. But I believe we at least provide some intuition as to why we think the above holds in a principled analytical framework.

Conclusion

The trend of on-chain voting in blockchains is inspired by humanity's long-standing traditions of voting and democracy. Unfortunately, the protective measures available in the real world, such as enforced private/deniable voting, approximate identity control, and the attributable nature of widespread fraud, are fundamentally unavailable in permissionless models. On-chain voting cannot provide any anti-coercion guarantees for these users when using public keys generated by users themselves. Carefully designed voting schemes do little to quell (and in many cases actually exacerbate) the issues. On-chain voting schemes complicate incentive mechanisms further, leading to unstable and chaotic incentives that can be altered at any time through trustless smart contracts or Dark DAO-style vote-buying, bribery, and mourning schemes.

We encourage the community to maintain a high level of skepticism regarding the results of any on-chain voting, especially as on-chain voting becomes an important component of decision-making in blockchain systems. The space to design mechanisms that enable new forms of abuse at lower coordination costs than ever before supports the stance that voting should be used for signaling rather than decision-making, and a variety of voting mechanisms should fill these roles. Without such protections, all on-chain voting systems remain susceptible to degrading into oligarchic rule through direct vote-buying and participation purchasing, even vote tokenization.

Such attacks have significant implications for the future security of all blockchain-based voting systems.

Acknowledgments

We would like to thank Patrick McCorry for his useful and comprehensive feedback throughout the lifecycle of this article, as well as his pioneering work on vote-buying and on-chain voting systems.

We also thank Omer Shlomovits and István András Seres for their helpful comments on early access versions of this article.

Appendix A---Differentiating Metrics for On-Chain Voting

We note several different differentiating factors in on-chain voting systems:

• Vote-changing ability: If users cannot change their votes, any method that provides cryptographic proof of encrypted receipts can be used for ordinary vote-buying. Smart contracts can simply bribe users in advance to obtain their votes, which can never be changed now. However, most schemes allow users to change or retract their votes, meaning bribery requires some continuous time component (or occurs after taking a snapshot of the votes). Exponentially increasing spending over time provides an interesting solution that can prevent coins from moving and encourage long-term signaling, while spending bonuses at the completion of voting are tools that potential vote buyers can use to create viable vote-buying schemes when users are allowed to change their votes.

• Smart contracts/delegated voting: Who can vote for funds stored in smart contracts? This is an unresolved issue that plagues existing designs; the original CarbonVote allowed any contract that could call functions to vote and then change their minds. EIP999 voting allows contract deployers to vote on behalf of the contract, a decision widely criticized as aimed at influencing voting outcomes. However, neither of these designs seems ideal. In fact, intuitively, a single design seems difficult to fairly capture all the nuances of custody in smart contracts: the range of smart contracts holding funds can vary from simple multi-signature accounts to complex decentralized organizations with their own revenue streams and financial relationships between contracts. Which of these tokens have voting rights, and how to fairly distribute these rights remains a completely unexplored philosophical requirement for building a fair on-chain voting system. Forcing contract authors to provide explicit functionality may also be insufficient, as the demand for this functionality may change in the future without backward compatibility (through chain voting or forks).

• Denial/Provability: All the schemes explored in this paper have features that make them particularly susceptible to vote-buying: they provide voters with some form of trust-minimized cryptographic proof through on-chain logs, secure web interfaces, or the state of smart contracts. Such schemes are particularly vulnerable to vote-buying because they allow smart contract-style logic to easily verify votes. Some traditional electronic voting schemes in the academic literature offer a property called coercion resistance. In these schemes, users can change their minds after coercion using the keys they used to vote, and the votes do not belong to individual users. In general, the privacy issues associated with voting linked to any type of long-term identity, especially those holding tokens, are quite serious. This concern would completely disqualify any serious voting system in the real world and might disqualify all thoughtfully designed on-chain voting design standards.