By Granite State Report
TL;DR
Blockchain can help publish tamper-evident election records and enable the public to verify tallies. It cannot magically solve the hardest problems in voting: malware on voters’ devices, coercion at home, identity proofing at Internet scale, and guaranteeing a secret ballot outside the polling place. The right path for “Democracy 2.0” is a hybrid system: paper ballots + end-to-end verifiability (E2E-V) + public transparency logs (which might be blockchain) + routine risk-limiting audits. This article maps the technology, the tradeoffs, and a credible implementation plan—without hype and with receipts.
Why people keep proposing blockchain for voting
Elections are messy socio-technical systems. Voters want accurate results, privacy, accessibility, and speed—and they want to see that the process worked. Blockchain, a tamper-resistant ledger replicated across many nodes, promises an immutable audit trail and public transparency. That’s alluring. NIST describes blockchain as a “collaborative, tamper-resistant ledger” useful when multiple parties need shared, append-only records. (NIST)
In theory, a voting system could record encrypted ballots or cryptographic receipts on a chain so anyone can verify the published tally hasn’t been altered post-facto. In practice, a lot more is required to make elections secure, private, usable, and legal. U.S. federal and state election authorities have been cautious for good reasons, and the computer security community has raised specific, fix-able and not-so-fix-able concerns. (ACM)
Let’s separate what blockchain is good for from what elections actually need.
First principles: what a trustworthy election must prove
Three bedrock properties, stated plainly:
- Eligibility & Uniqueness: only eligible voters can vote, and only once.
- Secrecy: no one can learn how you voted, and you can’t prove it to a buyer/coercer (“receipt-freeness”).
- Correctness (Evidence, not just outcomes): anyone can check that every recorded vote is counted as cast. This is the idea of software-independence and end-to-end verifiability (E2E-V). (NIST)
“Software-independence” (Rivest & Wack) means a bug or hack in software can’t silently change the outcome; errors must be detectable by a process independent of the compromised software—think hand-auditable paper ballots plus risk-limiting audits, or E2E-V cryptographic proofs. (NIST)
E2E-V systems give each voter a way to confirm that their encrypted ballot is in the public tally and that the math on everyone’s ballots adds up—without revealing how any individual voted. The U.S. Election Assistance Commission (EAC) has been actively exploring how to standardize such protocols. (U.S. Election Assistance Commission)
Where blockchain actually fits
Good fit:
- Public bulletin board for proofs: A chain can be the append-only “bulletin board” where encrypted ballot hashes, zero-knowledge proofs, and tallies are posted so anyone can independently verify that math checks out. This is similar to how certificate transparency logs work for the web. (arXiv)
- Tamper-evidence for published artifacts: Once the results and proofs are posted, a blockchain can make later manipulation obvious, improving public transparency without being in the critical path of casting a ballot. (NIST)
- Governance outside of public elections: DAOs and member organizations use blockchains for open governance where coercion risks are different and participation is online-native. Zero-knowledge tech (zk-SNARKs) is improving privacy and ballot validity in these contexts. (SpringerLink)
Bad fit (or “not yet”):
- Internet ballot return for public elections (voting from a phone/computer and sending the ballot over the Internet). Leading scientific bodies and U.S. election agencies warn the risks are currently unacceptable: device malware, coercion, and scale-grade attacks. (nationalacademies.org)
The National Academies: “At the present time, the Internet… should not be used for the return of marked ballots.” (Verified Voting)
CISA/EAC/FBI/NIST guidance catalogs the security pitfalls in electronic ballot return, from malware to loss of ballot secrecy. (CISA)
The ACM U.S. Technology Policy Committee urged states to avoid Internet voting apps in 2020; the technical caveats remain valid. (ACM)
Case study: when a blockchain-branded app met reality
The Voatz mobile voting app used a blockchain backend in some limited U.S. pilot elections. Independent researchers from MIT found vulnerabilities enabling potential vote manipulation and ballot privacy exposure—even before you get to the blockchain. The paper’s title tells the story: “The ballot is busted before the blockchain.” (internetpolicy.mit.edu)
Takeaway: most of the danger sits off-chain—on the voter’s phone, in authentication, and in the network path. If malware can change a vote before it’s encrypted, a perfect ledger merely preserves the wrong thing immutably. That’s not a feature.
The better model: paper + E2E-verifiability + transparency logs
If “Democracy 2.0” means provable integrity with modern cryptography and the resilience of paper, we already have a working path.
- ElectionGuard is an open-source SDK (Microsoft and partners) that adds E2E-V to existing paper-based systems. Voters still cast hand-auditable paper ballots; cryptographic proofs allow anyone to verify tallies. This has been piloted in Wisconsin (Fulton, 2020) and used in additional jurisdictions since. (electionguard.vote)
- Reports and news coverage document the Wisconsin pilot and subsequent uses; voters retained paper while gaining verifiability. (Source)
In this hybrid design, a blockchain (or simpler public transparency log) can host the posted proofs and hash commitments. If anyone tampers with the posted results or proofs later, the mismatch is publicly detectable. That’s real transparency without moving ballot casting onto personal devices.
Cryptography that matters more than the chain
Three ideas do the heavy lifting:
- Homomorphic encryption: lets officials add encrypted ballots together and then decrypt only the final totals, never individual votes. This is a core ElectionGuard primitive. (electionguard.vote)
- Mixnets: shuffle encrypted ballots and prove (in zero-knowledge) that the shuffle was valid. That breaks any link between a voter and their decrypted selections, preserving secrecy while enabling public verification. (arXiv)
- Zero-knowledge proofs (ZKPs): prove a ballot is well-formed (e.g., “exactly one candidate selected”) without revealing the vote. Modern zk-SNARKs power scalable proofs; research shows feasibility for ballot validity and receipt-freeness. (SpringerLink)
Whether the public bulletin board is a permissioned blockchain, a permissionless chain, or a simpler append-only log, these cryptographic proofs are what deliver verifiability.
What about “fully on-chain” elections?
Academic designs and DAO tooling demonstrate “on-chain” voting with ZK privacy, but they assume away critical issues that public elections can’t ignore: strong identity proofing for millions, protection against coercion/compelled proof of vote, universal accessibility, and the messy realities of provisional ballots and ballot styles. The more serious researchers acknowledge these limits and aim their systems at smaller-scale or non-coercive settings. (ScienceDirect)
Sierra Leone (2018) is a cautionary media tale: headlines trumpeted a “world’s first blockchain presidential election,” but officials later clarified the national election itself wasn’t run on a blockchain; a vendor recorded some regional tallies on its own system. The lesson: separate PR from policy. (Futurism)
Threats blockchain does not fix
- Malware on voter devices: If a phone or PC is compromised, it can change selections before encryption. This is why Internet ballot return is widely discouraged for public elections today. (CISA)
- Coercion and vote selling: A home environment can’t guarantee privacy or prevent someone from demanding proof of how you voted. A transparent ledger can increase receipt risks unless carefully mitigated with cryptographic protocols. (arXiv)
- Voter authentication at scale: Identity proofing without sacrificing ballot secrecy remains hard. ZK credentials are promising, but deploying them universally is a multi-year civic infrastructure project. (jisis.org)
- Usability and equity: Accessibility for voters with disabilities, language access, and the digital divide are policy and UX challenges, not ledger problems. Election agencies stress paper backups and auditable processes precisely to serve all voters. (ACM)
A pragmatic blueprint for “Democracy 2.0” in the U.S.
1) Keep paper ballots. The National Academies and NIST guidance converge here. Paper is legible, auditable, and resists large-scale software failure. Pair with risk-limiting audits after every meaningful contest. (nationalacademies.org)
2) Add end-to-end verifiability. Integrate a vetted E2E-V layer (e.g., ElectionGuard or similar) into precinct scanners or ballot-marking devices. Publish encrypted tallies and zero-knowledge proofs so voters, parties, media, and watchdogs can check the math. (electionguard.vote)
3) Publish to a transparency log (optionally blockchain). Treat the log as a publication layer—not the ballot box. A permissioned chain operated by a diverse set of election stakeholders (state agencies, accredited universities, media consortia) can host commitments, proofs, and hashes of ballot images (not the images themselves), making post-election tampering publicly detectable. (NIST)
4) Harden everything around the chain. Follow CISA/NIST risk management guidance for remote ballot delivery and marking (when used), email hygiene, MFA for election staff, and chain-of-custody for paper. The biggest wins come from basics. (CISA)
5) Standardize and certify. EAC and its Technical Guidelines Development Committee are already discussing requirements and evaluation criteria for E2E-V. States should map procurement to these standards rather than bespoke pilots. (U.S. Election Assistance Commission)
6) Radical transparency with privacy. Publish machine-readable election records (hashes, proofs, audit data) and provide open-source verifiers. Teach media and citizens how to use them. Keep voter choices private via homomorphic tallying and mixnet proofs. (GitHub)
Costs, politics, and the vendor reality
The voting-tech market is small, vendors are risk-averse, and legal frameworks vary by state. Travis County’s attempted STAR-Vote project (pre-ElectionGuard) shows how innovative designs can stall despite expert support. ElectionGuard’s approach—free, open components that vendors can integrate—lowers barriers and spreads the model incrementally. (WIRED)
Bottom line: Blockchain doesn’t remove the need for standards, procurement discipline, training, and audits. It can, at best, serve as a public ledger for evidence after a well-run, paper-anchored election has produced that evidence.
Frequently pitched blockchain voting claims—fact-checked
- “Blockchain makes votes immutable, therefore secure.”
Immutability helps after a vote is correctly captured. It does nothing if malware changes the vote before it’s recorded, as real studies have shown. (USENIX) - “We’ve already had a national blockchain election.”
Not in the way headlines implied. Sierra Leone’s 2018 vote wasn’t run on a national blockchain; it was a vendor pilot with limited scope. Officials corrected the record. (Futurism) - “Without Internet voting, disabled and overseas voters are left out.”
Accessibility and UOCAVA voters deserve better tools—but security agencies advise extreme caution with electronic ballot return. Safer options include accessible ballot marking at home paired with paper return, or tightly scoped pilots with robust risk disclosures. (CISA)
Where research is heading (and what to watch)
- Receipt-freeness with ZKPs: New zk-SNARK-based protocols aim to block vote-selling by making it cryptographically impossible to prove how you voted, even if you want to. Promising for the long run. (ITU)
- Scalable privacy-preserving e-voting: Hybrid on/off-chain systems that keep on-chain storage minimal while publishing verifiable proofs at scale. (ScienceDirect)
- Formalizing software independence: Recent academic work clarifies how to define and test SI more rigorously, which should feed into future standards. (arXiv)
- Standardization of E2E-V: Continued EAC work to set evaluation criteria so verifiable systems can be certified and procured like conventional equipment. (U.S. Election Assistance Commission)
A practical rollout plan (state or county level)
- Adopt risk-limiting audits statewide. Build the legal and logistical muscle first.
- Pilot E2E-V on top of existing paper systems in a small jurisdiction (like Wisconsin’s Fulton pilot), with public observers and published data. (Source)
- Stand up a transparency log consortium (universities, press, civic orgs, state IT) and decide: permissioned blockchain or simpler append-only log—either is fine if the proofs are solid. (NIST)
- Publish open verification tools and hold “verify the election” workshops for campaigns, media, and the public.
- Iterate: expand to larger contests only after independent groups verify published results successfully and audits reconcile.
Related videos (for readers who want to see it in action)
- ElectionGuard: Enabling voters to verify election integrity — tutorial and Q&A with Josh Benaloh. (YouTube)
- USENIX Security ’24: ElectionGuard—A Cryptographic Toolkit to Enable Verifiable Elections (talk). (YouTube)
- Open-source election security: E2E verifiable voting (technical talk). (YouTube)
- Election Security (NIST resources overview)—context for the broader security program. (NIST)
(Note: Many YouTube explainers oversell “blockchain voting.” The selections above emphasize verifiability and audits over hype.)
Suggested inline images for readers (what to look at)
- Photos from the Wisconsin ElectionGuard pilot—paper ballots plus verifiable receipts.
- An example “End-to-End Verifiability in Real-World Elections” report cover—what public artifacts look like when published.
- A generic architecture diagram showing where the ledger sits (publication layer), not as the ballot box.
Bottom line
Blockchain is not a silver bullet for voting. It’s a potentially useful publication substrate for the evidence that modern, paper-backed, end-to-end verifiable elections can generate. If “Democracy 2.0” means giving every voter, campaign, journalist, and skeptic the tools to check the math themselves, then the real work is standardizing E2E-V, deploying risk-limiting audits, and publishing cryptographic proofs on an immutable, widely replicated log—blockchain optional.
That’s how you make elections both boringly resilient and beautifully transparent.
References & further reading
- National Academies of Sciences, Engineering, and Medicine. Securing the Vote (2018) — human-readable paper ballots and strong audits; opposes Internet ballot return. (nationalacademies.org)
- CISA/EAC/FBI/NIST. Risk Management for Electronic Ballot Delivery, Marking, and Return (ongoing guidance). (CISA)
- NIST. Election security program and ballot delivery risks (overview pages). (NIST)
- Rivest & Wack. Software Independence (foundational concept). (NIST)
- MIT (Specter, Koppel, Weitzner). The Ballot is Busted Before the Blockchain—Voatz analysis (USENIX Security ’20). (USENIX)
- ACM USTPC. Statement urging states to avoid Internet voting apps (2020). (ACM)
- EAC/TGDC. Path to E2E-Verifiable protocols and standardization. (U.S. Election Assistance Commission)
- ElectionGuard. Overview, roadmap, and pilot reports (Wisconsin, Idaho, others). (electionguard.vote)
- News/Explainers on Fulton, Wisconsin pilot.
- Sierra Leone correction: What actually happened (debunking the “blockchain national election” myth). (Futurism)
- Zero-knowledge voting research (zk-SNARKs and ballot validity/receipt-freeness). (SpringerLink)
Editor’s note on bias and verification
This report foregrounds consensus positions from NIST, CISA/EAC, the National Academies, and peer-reviewed security research. Where vendors are cited, we also link to independent analyses and public pilots. If you want us to dig into a specific vendor proposal or run a side-by-side on “blockchain vs. append-only transparency logs,” we’ll do it with public artifacts and reproducible checks.
