Voting with other people’s wallets: plutocracy, blockchain style

“One person, one vote” may be the rallying cry for electoral reform, but governance for cryptocurrency— to the extent one can speak of governance with a straight face in this ecosystem— often operates on a different and decidedly plutocratic principle. Were it not for the extreme volatility of cryptocurrencies against the US dollar, the corresponding slogan would be “one dollar, one vote.” From the design of proof-of-stake algorithms that grant mining shares based on how much capital the miner has committed to the system to the design of polling mechanism that attempt to gauge community opinion on various proposals, influence is unabashedly measured as a function of account balance.

One example popularizing this notion as something of a Gallup-poll for the Ethereum community is Coinvote. Anyone can create a poll and participants vote yay or nay on the proposal, with their vote weighted by the amount of funds they hold. Voting itself does not involve any exchange of funds. Instead of participants cast their vote by sending a specially crafted message, digitally signed using the same private-key associated with their blockchain address. The signature establishes using cryptographic techniques that the voter is indeed the same person who controls the purse strings for the associated blockchain address. This system has been used for gauging community opinion on contentious questions, ranging from the EIP-999 proposal to rescue funds trapped in the now defunct Parity multi-signature wallet to more speculative questions around changing the Ethereum proof-of-work function.

Publications such as CoinTelegraph blithely cite these poll results as if they were representative of the vaguely-defined “community.” But the design is fundamentally unsound. Even if one buys into the dubious  plutocratic ideal that votes count in direct proportion to the voters bank account, Coinvote and similar polling models are fundamentally broken because they fail to account for the quirks of how funds are managed at scale.

Vote early, vote often?

Let’s start with one design subtlety that Coinvote gets right: preventing multiple votes using the same pool of funds. Votes are not counted when they are initially cast but at the end of the polling period, based on blockchain balances at a specific point-in-time. This is important because funds can move around. Imagine that Alice has a pool of ether. She can cast a vote using this pool of funds, then immediately “loan” them out to Bob— or even another blockchain address she controls herself— who casts another vote from the new address. By looking at a snapshot of the blockchain at one specific moment in time, Coinvote avoids double-counting votes from ether that gets shuffled around.

Contractually disenfranchised

The challenges with Coinvote are more complex. First problem is that by virtue of insisting on signed messages, it can not accommodate funds associated with smart contract. Recall that there are two types of Ethereum accounts: externally-owned and smart contracts. The former are what we traditionally associate with cryptocurrency. There is a private-key, carefully guarded by the owner of those funds and he/she wields control over that pool of money by cryptographically signing messages using that secret. The latter is the notion of “programmable money” pioneered by Ethereum. There is no secret associated with such an address per se, but there is a set of conditions expressed in a programming language— the “contract”— associated with the address which determine under what conditions the money can be spent.

Contracts allow expressing detailed logical restrictions around how money can be spent: for example a contract can be designed to only permit sending funds to a small number of “whitelisted” addresses, only if 2 out of 5 shareholders agree but not before March 2021 and no more than 1000 ether per day. It is precisely their expressiveness that makes contracts ideal for storing large pools of funds, with strict controls around spending conditions to prevent theft and misuse. Three out of the ten largest ethereum balances today are held in smart-contracts including the account with highest balance, storing more than 2% of all ether in existence. But that also means the holders of those funds have effectively become disenfranchised: they are ineligible to cast votes by signed messages, since there is no key to sign with.

One work around is for owners of those funds to temporarily transfer funds to a plain address, cast the vote and transfer them back. But that is an unworkable solution: moving out of the contract obviates the security controls imposed by that contract, jeopardizing the safety of those funds while they are controlled by a single key. This is no longer voting with the wallet— it’s voting by waving wads of cash in the air.

Contracts can be designed to interact with other contracts on the blockchain. In principle the problem can be solved with a better design where votes are cast by sending messages to a “ballot-box” contract on blockchain. Since contract invocations require paying mining fees or “gas” in ethereum terminology, this would have to be in addition to and not a replacement for off-chain voting with signed messages. Otherwise it amounts to a poll-tax. But that only shifts the burden to the sender side. Recall that contracts are immutable. Once a contract is published, it can not be modified, upgraded or even patched for bugs. (The illusion of upgradeability as in the Gemini dollar stable-coin contract, is achieved by using a level of indirection: an immutable “proxy” contract at a fixed address maintains a pointer to a second contract that contains the real implementation.) Suppose the Ethereum Politburo decrees a new standard for vote casting/receiving by contracts. All existing smart-contracts in use would still be incompatible with the standard since they predate its introduction, and all associated funds would still have no way to voice their opinion on polls.

Integrity of votes

Speaking of using a smart contract to count votes, there is another benefit to that approach over Coinvote: at least everyone else can verify that votes were recorded accurately. When signed messages are being submitted to a website, there is no guarantee that they will be counted fairly. The organizer could discard votes if they are trying to tip the outcome one way or another. While every vote recorded can be publicly verified— everyone can check the signature on the signed message and inspect the blockchain for the amount of money that vote speaks for— there is no easy way to prove that a vote was suppressed. Suppose a participant objects by producing a signed message they alleged to have used for voting. The organizer can fire back, arguing that it was not delivered in time before the deadline. Or the organizer may not allow the voter to change their mind: a signed message is valid forever. If the voters cast two conflicting votes, the organizer is free to retain the preferred one. We could try to work around suppression by requiring the organizer to issue a time-stamped and signed receipt for each vote cast. But that only shifts the shenanigans to an earlier: Alice voting against a proposal receives her receipt but Bob keeps running into mysterious problems with the website every time he casts a vote in favor.

Moving the vote recording mechanism onto the blockchain at least introduces some semblance of transparency. To the extent that vote suppression is occurring, it is now controlled by miners instead of a centralized organizer. As long as there is competition in mining, every vote cast has a fighting chance of making it into the permanent record of the blockchain— unless that is, the proposal is one miners are unanimous against. Consider voting on a proposal to reduce mining fees: the rational decision for all miners could be to only accept “no” votes and forgo the short-term revenue from recording “yes” votes, in favor of a strategic play to create the appearance of widespread opposition to the measure.

Voting with other wallets

There is a different problem with using blockchain transactions to cast votes: the assumption that one address speaks for one person is wrong. Custodial services— such as cryptocurrency exchanges— commonly pool customer funds into a shared, omnibus account. Typically every customer still has unique deposit addresses, as it is necessary to distinguish incoming funds to decide which customer to credit. But when customers want to withdraw funds, the transaction can originate from any address controlled by the exchange. Wallet software to tries to solve an optimization problem called unspent-output selection, which involves choosing the right combination of available funds to satisfy a particular request. If Alice deposits 1BTC into an exchange and later Bob wants to withdraw 1BTC, it is entirely possible for Alice’s deposit to be used for that request. This does not mean Alice’s funds are gone— it only means that UTXO was among those selected for the transaction initiated by Bob. What goes on under the hood is that the exchange maintains an internal ledger recording the cryptocurrency balances of every customer. Alice still has 1BTC, while Bob’s balance got debited the amount withdrawn. These ledger updates are not reflected on the blockchain: it would be too slow and wildly inefficient in transaction fees if every time a customer bought or sold bitcoin, the corresponding amount of funds had to be shuffled around on the blockchain. (At one point Bitfinex attempted to perform daily reconciliation among customer accounts in response to a CFTC consent decree, but gave up on that design after a 2016 security breach.)

The bottom line is that customers of custodial services can initiate withdrawals from addresses they do not have full control over. This has implications for voting strategies built around sending funds. For example, CarbonVote conducted a poll to gauge community opinion on the DAO bailout. Participants voted by sending a 0-ether transaction to one of two addresses, indicating a preference in favor of or against the proposed fork. A transaction with zero value is allowed in Ethereum and does not result in a decrease in the balance of the originating account. (However the sender must still pay the ethereum transaction fee in “gas” so the poll-tax criticism applies.) As before, the votes are weighted by the balance of funds in the originating address. Knowing how omnibus wallets work, it is trivial to game this poll: withdraw from your exchange account directly to one of the yes/no addresses. If the customer happens to get lucky, the transaction will originate from a very high-value address that holds funds for thousands of other customers. The resulting vote will have outsized influence, far out of proportion to the actual ether held by the person casting that vote.

It turns out those favorable circumstances do happen for many exchanges in the case of ethereum. For several exchanges, the majority of ether in hot-wallets is concentrated in a small number of blockchain addresses. The initial polls misinterpreted “votes” from those addresses, incorrectly assuming that one transaction represented the preferences of a single person/entity who controlled those funds. CarbonVote later attempted to correct this problem by disregarding some addresses known to be associated with popular exchanges.

Of course ignoring votes does not solve the underlying problem of accurately capturing the preferences of customers using custodial accounts. They can always temporarily withdraw their funds to a personal wallet to cast a vote but this is complicated by the requirement to hold the ether at that address until the poll is closed. (Presumably the customers opted for a custodial solution because they did not want to manage the risk of storing cryptocurrency directly.) Nor does it prevent a determined custodian from voting on behalf of customers: even if one well-known address is blacklisted for the purposes of counting votes, the custodian can always move funds around to another address such as their cold-storage and cast votes from there.

For a demonstration of how easily a single custodian can tip the scales, consider the EIP-999 poll. By virtue of its controversial nature, this poll received more than four times as many votes as the next most popular poll on CoinVote. Votes against the EIP edged out those in favor by a margin of approximately 630K ether. Revisiting the list of ethereum accounts with highest balances, there are a dozen individual addresses with funds exceeding that difference, almost all of them associated with exchanges. A single custodian using assets under management to vote could have tipped the scales from “no” to “yes.”

There is an analog to this problem in traditional finance: proxy voting through mutual funds. Nominally shareholders attending an annual meeting can cast their own votes on questions put before the owners, such as significant changes to the business or compensation plans. But the majority of individual investors in the US do not own shares of companies directly. They own them through a qualified investment managers such as mutual-funds and ETFs. That means the mutual fund gets to vote on behalf of its own members— a vote that may not be representative of how the investors owning shares in that fund actually feel about the issue. In fact critics have pointed out mutual funds typically prefer not to rock the boat, routinely siding with company management on share-holder proposals.

Voting with borrowed money

Weighting votes in proportion to the amount of money they speak for creates additional incentives that can distort the system. Most democratic election systems seek to discourage vote selling and buying; in the US it is a criminal offense. Vote-by-ether is an invitation to do that.

It need not even involve any complicity on the part of the seller. Suppose an investor feels strongly about shaping public opinion on a particular issue that has a running poll. They can temporarily accumulate a large ether position on exchanges, cast a vote and hold the funds until the poll is closed, liquidating the position afterwards. This is less “vote buying” and more a case of “influence buying” since the counter-parties selling ether to the investor are not deliberately trying to give away their vote. Clearly this strategy is expensive and high-risk. If ether prices move in the wrong direction, the investor can end up losing money. Even if prices remain relatively flat— a rarity in the volatile world of cryptocurrency— there are transition fees associated with moving into/out of ether. Not to mention that the act of accumulating a large ether position alone can end up moving the market, making it increasingly more expensive to accumulate more votes.

There are better strategies for gaming the system. Suppose there is a large cryptocurrency holder with no opinion one way or another on a given issue. That person can always auction off their vote to the highest bidder. Alternatively if they wanted to remain at arm’s length from direct vote selling, they can temporarily “loan” out the funds in a risk free manner. Smart contracts make this easy: the seller transfers the ether to a smart-contract that only permits two actions: withdrawals back to the seller after a deadline or 0-ether votes cast by the buyer. The buyer can vote on an unlimited number of polls while the seller is guaranteed to regain control of the funds eventually.

Final tally on blockchain polls

In conclusion then, the current crop of blockchain polls have serious design flaws ranging from disenfranchising large segments of cryptocurrency users to allowing others to easily manipulate the outcome using funds they do not even control— voting with other peoples’ wallets. Until these design issues are properly addresses, they can not be considered anything more than unscientific straw polls, unreliable as an input for important decisions affecting the cryptocurrency ecosystem.

CP