State of Private Voting Report 2025

Transcript

Good afternoon. I'm Lauren Harkness and I'm John Gilding from the PSC team, the privacy stews of Ethereum team, which is uh in the EF. We used to be called Privacy Scaling Explorations, but we've recently gone all in on privacy. And I'm in the Macy team, and Macy is a private voting protocol. and I'm with Shudder and encryption as a service protocol. Our moonshot is to implement encrypted mempools on Ethereum mainet but we also run shutter shielded voting on snapshot and we're working on other forms of private voting as well.

Now, PSSE and Shudder recently collaborated on the state of private voting 2026 report and it was published just a few days ago. You can download a copy of the report at pse.dev and it is a monster. It is 64 pages long. And it's that long because we evaluated 12 different protocols against 24 different private voting properties. That means 288 evaluations in total. Because this is a 30inut

presentation. That means we have 1,800 seconds or 6 seconds per evaluation. So, hold on to your hats because this presentation is going to go No, just kidding. We're not going to do every single evaluation. We're going to pull out uh some of the most important points from the presentation. Uh starting off with demand. Why is private voting necessary? Why is it important? Why do Dows and their members demand it?

One of the reasons is bandwagon effects. If voters are able to see how other uh voters and delegates are voting in real time, they might just hop on to the bandwagon uncritically and vote how others are voting. And we would like to see more engagement and more critical thinking among DAO members. Additionally, if you can see all of the votes in real time, then it opens the possibility to manipulation by whales.

And this can happen in a couple of different ways. Number one, a whale or group of whales can cast their votes at the very beginning of the voting period, thus hoping to actually kickstart that bandwagon effect or to uh disincentivize dishearten disfranchise voters who might vote against them. Conversely, that group of whales might sit on the sidelines. They might wait for all of the votes to play out and if the vote is going in their desired direction, they don't need to do anything. They don't need to vote at all. However, if it's going against them, they can cast their votes at the

last minute, thus change it, excuse me, thus changing the results. And next up, we've got social pressure. So, as an individual, uh, as a voter, as a delegate taking part in a DAO, uh, if your votes are public, um, people, um, can see how you vote, maybe you've got relationships in the ecosystem, maybe you've publicly come out explicitly and said, "I like this project. I don't like this project." If your vote is public, you may decide to vote in your best interests. You may vote for the project you've got the best relationship for rather than the project that you've um that you truthfully think is the most deserving of your vote. And this could

come from the community or uh leadership in the DAO itself. And next is coercion and voting markets. So this is an interesting one. We haven't seen too much demand for this property in recent years. Maybe there's some inklings of like a demand for this property um this year. You might have seen um a few weeks ago there was like a um a vote buying exercise by anti-apture for an arbitum vote. So we're seeing examples now of like how this kind of attack vector can be exploited. So um if you can provide a verifiable receipt of your vote then um that vote can be bribed. It can be bought on a market um

in a blockchain setting. Things are public. They scale quite well. So that could be automated. So this is an attack vector we think is like maybe not too important right now, but we definitely think it's going to be important in the future and especially to take Dow voting to kind of the next the next level to higher stakes um situations. >> Now there's not just one type of private voting. There's many different approaches and each of these approaches has uh various trade-offs, pros and cons. And so we're going to discuss some of the challenges which come with different types of private voting.

Me uh so the first one is transparency and efficiency. Um, obviously there is a long-standing tradition in blockchains of transparency that has also been highly beneficial for Dows uh as decentralized organizations um and it promotes um uh good DAO management and effective and efficient decision-making. So there is a balance that you need to strike between transparency and privacy.

>> Yeah, just a quick note on that as well. If you're um if you can see like a vote happening and maybe it's like in a domain that you don't know a lot about, like maybe it's a technical proposal and you can see a core developer voting a certain way, you can defer your cognitive effort to that person because you trust that they have made an informed decision. So that's also like a a pro of this this transparency. >> Um also user experience. Um we know not everyone is a developer or a cryptographer. Um most DAO managers are surprisingly not technical or not very technical. And even more so, most DAO

members are not technical or very technical either. And so what we really need are solutions which can be integrated into familiar DAO tooling platforms and allowed to be turned on or off by DAO members with a couple of clicks and then to be utilized by most DAO members in the exact same way that they're used to voting uh normally. So without having them to um spend a lot of gas or to uh complete a complex technical operation.

Uh Dow management and whipping votes is a really interesting um case. We often see that DAO managers are not actually that excited about uh private voting because it means that they have less control over the DAO and its operations. um if they can see how a a vote is playing out in real time and the direction of the vote, depending on their priorities, they can actually um use back channel Telegram groups or DMs in order to whip votes and steer the

vote in the direction that they would like. Of course, DAO management is not just about achieving a specific result. um ensuring that the DAO reaches quorum is also very important. So while private voting uh is very important, it's also important to have transparency about the amount of voting power which has been deployed so that the DAO can ensure that it has reached quorum and there's several edge cases as well that we you could think about with with private voting. So one example is a it was like a compound governance attack a while back where attackers made a

proposal and uh the community was galvanized by the rest of the D to actually vote no for this proposal. Um so that's like an example of like where the lack of privacy actually enabled people to respond to like an attack in progress. We would kind of contend that this isn't like a really good argument against private voting. Um, private voting uh like provides information asymmetry. Uh, so when when you're when you're voting, you have the same information that like all the other voters have. So like earlier voters have the same information as like later voters. We don't think this like edge case where the compound um governance attack was seen in in advance like

actually uh is like solves uh asymmet uh information asymmetry >> and the reason for that is that a malicious attacker always knows how much voting power they're able to deploy and um the other community members will never have that information. So information asymmetry always exists in an attack situation. Um so private voting does not enable governance attacks. It merely does not prevent information asymmetry in that particular edge case.

Um delegation and the principal agent problems which arise from delegation are super interesting. Uh if you are a token holder with voting power and you delegate your voting power to a delegate, you have created a principal agent relationship. And this is a classic economic problem. There have been lots of solutions proposed over the past decades, but essentially what they all um converge on is the idea of giving the principal transparency about the agents actions so that the principal can hold the agent

accountable or to switch agents if the agent is no longer acting in their best interests. Of course, if you have private delegate voting where the delegates votes are permanently private, then the delegate would dele or the delegator would delegate their voting power to an agent with no accountability. Um, which is an interesting problem. So we looked at 12 different protocols and we could have um uh reviewed them in any number of orders. We could have done

it alphabetically, random, throwing darts at a chalkboard. Uh but instead we chose to take a look at them in terms of implementation maturity. So the first box we've got is high maturity. So we just chose three broad boxes. high, medium, and low. And so these projects you can see in this initial box um have either been running in production for a few years or maybe they're on like the third or like the multiple iterations of the protocol. So Macy and Semore are examples of that. So they're on like the third or fourth iteration. And then Freedom Tool, CIV, and Shutter Shielded Voting have actually been running in production for several years up to 3 four years.

And next up we have the medium maturity category. So these are tools that are beyond research stage um but they're not like fully productionized kind of in the middle of um yeah in in the middle of those of those two boxes. So Dainci is in active development for example but the team behind Da Vinci Vton have been developing private voting protocols for a few years now. So that's why they're in in medium. And finally we have low maturity. So these a lot of these projects are either research endeavors, they never made it to production or they're in active development at the moment and they're expected to go to production. So the Aragon Aztec uh research, the Cicada Protocol, Kite are all research

endeavors and then Enclave and Shutter permanent shielded voting are both in active development at the moment. Rather than go through all 24 properties one by one, uh we decided that we would take a couple of trends um which are most interesting and insightful and review them with you. If you look at all 288 evaluations, if you zoom out and look at them all at once, it looks like this.

Um, we've got all of the uh projects on the top row and then on the left hand side we've got all of the properties and then you can see kind of uh the shorthand high, medium, low in red, yellow, green. So, what we're going to do is we're going to choose a couple of the most important properties and look at how all of the different protocols were evaluated with respect to those properties.

So, first up, we've got coercion resistance. So, you can see there's like a few protocols here that meet this property, then a few that don't. So, it's kind of like equally split. Um yeah, as as mentioned initially, like it hasn't been like a key market demand in the past, but we anticipate that this will be important for private voting protocols in in the future. Like a key aspect of voting normally in in elections is you have a private vote and you also can't prove how you vote. Um Macy v3, Da Vinci, and Enclave are kind of like the best protocols here. Um Da Vinci and Enclave, so they they have like a a mechanism to to change votes.

They have like a key change mechanism where you can change your key and then vote under a different key. So if you get bribed, you can simply vote again later and the briber has no way of knowing that that bribe they initially made was actually effective. Da Vinci and Enclave have also have like an improtocol mechanism to rerandom randomize or re-encrypt uh submitted ballots. So they actually provide like a stronger form of receipt freess and coercion resistance because they have that in protocol mechanism as well. Another one which we touched on earlier is or actually two different properties which go together are running tally privacy and quorum status. Running tally

privacy um means that you encrypt votes as they are cast and keep them encrypted for the duration of the voting period and only decrypt them at the end of the voting period. And this is very important for preventing information asymmetry. In other words, making sure that all voters have the same information when casting their votes, not giving anyone else um more information.

Um this is done as I mentioned by encrypting the contents of the votes but it's also important to leave unencrypted the amount of voting power which has been deployed and that allows you to calculate the quorum status i.e telling you whether or not enough voting power has been deployed for a proposal to pass or be rejected. Um what's really interesting about the results here is you can see just by glancing at these uh cards is that many of the protocols which provide running tally privacy do not provide quorum status and vice

versa. And we would say that the best of both worlds would provide both. Another one which actually was surprising um we didn't include this in the initial list of properties was um multiplechoice fractional voting and weighted voting. We assumed that most or all private voting protocols would support a range of different types of voting, but that turned out not to be the case. There were actually uh a surprising number of protocols which only support binary yes no voting. And if your voting protocol is focused on a

particular niche like um uh for example um ballot initiatives um which are strictly binary um that's fine. But if you are a general purpose voting protocol um we would encourage you to support a range of different types of voting. And yeah, then we've got vote delegation. So, uh, as you can see, there's a bit of a mix here. And then, um, if you've if you had a look at the re the report already, we've got vote delegation. And then we've got several related properties as well. So, we've got like the fact that you can delegate your vote, which not every project has.

And then we also have these properties such as private delegation, engagement disclosure. So, so private delegation is be able to delegate privately. Engage. Engagement disclosure is disclosing the fact that you are delegating the fact that if you're delegated voting power to the fact that uh the option that you voted for and then also delegate or delegation updatability. Um there's not really I mean this is this is kind of presenting the state of private voting. And so for private delegation there's not really anything in production at the moment that does private delegation. So this is kind of a a key area of future work. Um we've got like the kite project. So kite is a research paper and like a kind kind of

academic implementation at the moment. Um but taking that work to production or a similar piece of work to production um we view as like an important piece of future work future work to kind of take private delegation forward. This was actually one of the hardest properties to evaluate partly because um most of the private voting protocols actually rely on a DAO tool uh in order to implement uh or integrations with DAO tools in order to implement delegation.

And so we often had to look at a combination of uh the private voting protocol and the DAO tool. That's one of the reasons why you see that many of them in yellow say it's possible, but because there's no existing implementation, we didn't really know what we were going to be evaluating. Now private voting has come a long way in the past few years. Uh we have made tremendous progress in terms of the number of projects which have reached implementation maturity and have a long track record of providing robust and

consistent service. We have also seen the development of new cryptographic uh primitives and we've seen different cryptographic primitives being combined in novel ways to unlock new features and that is tremendous and we as a community and ecosystem should be rightfully proud. However, there's still a lot of work to be done. Um, one area is ensuring that we have um, uh, basically backed up all of our protocols so that if they do rely on trust assumptions, we have a fall back.

One of the most common ways of doing encryption and decryption um, for private voting protocols not used by all but by many is MPC uh, or multi-party computation. This means there's a distributed network of nodes which collaborate to generate encryption and decryption keys. But this relies on an honest majority assumption. Um, if there is not a threshold of live nodes, it means that decryption may never occur. Or if there is a threshold of malicious nodes, then the group of nodes may actually release the

decryption keys early, thus thus providing an early um or real-time result. It's important to note that they cannot uh create a false tally. They can merely uh decrypt early or not decrypt at all. But there's a couple of different ways where we can um mitigate those trust assumptions. One of them is we can introduce snitching uh which is a cryptographic primitive where if one node tries to collude with another node, the other node can basically tattletail on them and um they can prove it cryptographically

and that malicious node will be slashed or penalized. Another way to do it is by using time lock encryption as a fallback. So if the distributed network of nodes is offline, you don't need to worry about never uh decryting because time lock encryption at a certain point in the future will uh release the decryption keys. Privacy and delegation uh is another area for future work. As we have already pointed out, private voting is tough and delegation is tough and the intersection

of those things is exponentially more tough. Um there's so many different uh questions and so many different use cases. Um, you know, should you um ask delegates to provide proof that they voted? Uh, should you ask delegates to provide proof how they voted to their delegate? Um, should you allow delegators to redelegate to a different delegate after the voting period has already started?

How is that even possible? Does that even make sense? These are all questions which we are just beginning to explore and yeah a lot of these protocols involve uh cryptography like ZK, FH, MPC which isn't always abstracted away properly. So this can result in um yeah a worse user experience but also it can make these these projects and protocols difficult to to implement in a DAO itself. So improving the the availability of these protocols in Dowo tooling providers is an area of future work. So maybe like building uh modules plugins in kind of the the the leading or the the most popular Dow tooling

providers is like a good a good piece of work here and just making these like all of this hard work that's been done more available for Dows to actually use because there's a bit of gap a gap there. We've got these tools but like how does a DAO actually implement them? Um because there's there's yeah there's quite a few options to choose from. And yeah um these these protocols are because again they they involve like ZK for example this comes with additional gas costs. So like publishing a vote with Macy itself is like a few hundred,000 gas. You can like batch these offchain and then submit submit onchain uh once to reduce costs. Maybe you can execute the vote on L2s and then publish the result on L1. Um so piece of

future work here. So like increase the the gas effic efficiency of these protocols via different cryptography uh making circuits more efficient. Um maybe doing stuff on L2 and then propagating the vote crosschain to L1 since a lot of activity actually happens on L1. So I think there's been some some like research/ examples here where you can do crosschain voting but taking these to production could be like a next step where you vote on L2 and it's propagated to L1. And then another one is like kind of a non-technical one. So um we the Macy team did a bit of like user research before this endeavor with Shutter and we spoke to a few people from from Dows and there's kind of some apprehension

towards private voting. Obviously we outlined some of the challenges earlier in the talk. Um there are there are benefits to voting transparently, but we we contend that there is there are very strong reasons to enabling private voting and we do think it's important for the for the future of Dows to have this like have this as like a strong um a strong option like enabled by default ideally. So there's some work that could be done here to to actually promote the idea that you know privacy is a good thing like continue that narrative and also that private voting and privacy in voting and Dows is like a good thing too.

Um and a quick one that we haven't got a slide for is um quantum resistant voting as well. So just like Ethereum needs to become quantum resistant um we also need our private voting protocols to to use quantum resistant cryptography as well. Um, and then before I hand over back to to to Lauren, I think it's good to highlight a good a good finding of this report is that the the ecosystem is in quite a good place. Like we've got lots of existing private voting protocols that have like desirable properties.

We've got some that have been in production. We've got some for real life elections. And there's also like a number of exciting protocols coming online such as Da Vinci, Enclave, uh the next version of Shutter. So it's quite we're quite optimistic about the future of private voting and it's yeah it's great to see all of this activity happening which didn't exist a few years ago which is yeah it's good to see. This report is really the first step in this particular project. As a second step, we are going to be conducting interviews with DAO tooling providers, DAO managers, professional delegates, and other DAO participants. So, if you are interested in sharing with us your

priorities and your perspectives around private voting, please um scan this QR code. It'll ask you to add some of your contact information. And I personally will follow up with you to schedule a very short call. And if you have feedback on the report, that's wonderful. If you just have thoughts about Dows and private voting and you've never read the report, that's fine as well. Um would still love to get your priorities and perspectives.

So, this has been a very brief overview of the state of private voting 2026 report. Again, you can read the whole report at pse.dev and we would encourage all of you to do so. And just to reiterate what each of us have said earlier, we are so um uh proud and excited by all of the progress which has been made in recent years. Uh and we look forward to um all of the progress which we anticipate we will make as an ecosystem in the coming years as well.

I think we're out of time. Do we have time for questions? Got a couple of Uh does anyone have a question? Well, since we have a couple of minutes or while you are raising your hand, we um added an Easter egg. We added some superlatives. So, uh these are our recommendations about which voting protocols you should look at uh first when exploring a couple of use cases. So, real quickly, best for a national election, Freedom Tool and CIV, because they've been these are the

two protocols that have been used most in production so far. Civ is going to be used in a upcoming election in the US with 70,000 allegible voters. Freedom tool also been used in in in national elections mainly for like parallel or shadow elections, Iran, Georgia, and Russia. And also honorable mention to Da Vinci which is also like their team has been focusing on on this this uh use case a lot as well. >> Best DAO uh best DAO and user experience. >> Um yes so I'll take this one. So um the the the shutter guys have done quite a good job of like smoothing out the UX for shielded voting. So it's pretty seamless when compared to just voting normally like in a non-shielded fashion.

So yeah, the UX is like almost identical when you're using shielded voting compared to when you're not using shielded voting on on snapshot. Best to prevent pay for vote or pay for delegation. Um yeah, so we added Da Vinci here. I I now think we should have added Enclave here as well since it's like Macy, Enclave and Da Vinci with like the best uh coercion resistant properties but also uh yeah Da Vinci and Enclave also have this in protocol mechanism to to re-encrypt or rerandomize the the receipts which is also an additional additional protection for coercion resistance and for delegation kind of the most exciting one here is kite which

is just a research paper at the moment. So this needs to be taken to production and um uh yeah brought to reality but these guys have fought really hard about what it goes into to private delegation, what features you need and how to build it. And last of all, best to de uh best to solve the delegate principal agent alignment problem. And here the result is error 404 protocol not found. Uh none of the protocols that we evaluated um actually met this property. So this is an area where we would love to see

additional exploration in the future. We are out of time. Thank you so much. Um and we will be here for the rest of the afternoon to engage with you in person.