Blockchain for Secure Voting Systems: Architecture and Threat Modeling

A pragmatic guide to where blockchain can (and can’t) add value to verifiable election systems, with concrete architectures, threat models, and implementation tips for pilots that won’t get you crosswise with U.S. election guidance.

Decision-makers: this post lays out how to use blockchain as a verifiable bulletin board for proofs and artifacts, not as a transport for marked ballots, and shows the cryptography, privacy, and compliance details that matter in 2025.

Executive summary

U.S. guidance still classifies electronic ballot return as high risk; in regulated public elections, use blockchain only as an append-only, publicly verifiable bulletin board for audit artifacts (not for voting itself). (cisa.gov)
For enterprise, DAO, and shareholder voting—where internet return is permissible—combine end‑to‑end verifiability (E2E‑V), zero‑knowledge anti‑collusion, and BFT permissioned chains. We provide reference architectures, threat models (STRIDE + LINDDUN), and implementation details you can apply now. (en.wikipedia.org)

1) What U.S. election guidance actually allows in 2025

The EAC’s VVSG 2.0 (adopted February 10, 2021) is the federal benchmark most states rely on. It advances software independence, stronger cybersecurity, and explicitly requires air‑gapped systems with no wireless capabilities—constraints that preclude blockchain-based internet voting for U.S. public elections. (eac.gov)
CISA, EAC, FBI, and NIST re‑released their electronic ballot return risk guidance for the 2024 cycle: electronic return remains high risk; paper return is recommended except where law mandates otherwise. (cisa.gov)
The National Academies’ consensus report is blunt: with current tech, do not use the internet to return marked ballots; pursue paper trails and risk‑limiting audits. (nap.nationalacademies.org)
As of July 10, 2025, the EAC announced the first VVSG 2.0‑certified system; VVSG 2.0 is now the only standard for new federal certifications. This cements the “no internet/wireless” stance for U.S. voting devices. (eac.gov)

Implication: for government elections in the U.S., blockchain belongs behind the scenes as a tamper‑evident bulletin board anchoring audit data and cryptographic proofs—not as a voting transport. For enterprise governance, DAOs, universities, unions, and shareholder votes, a broader design space is available.

2) Where blockchain helps (and where it doesn’t)

Helpful

Public, append‑only bulletin board for audit artifacts: post commitments to ballots/proofs, decryption or mixing transcripts, risk‑limiting audit (RLA) manifests, and hash the final canvass. Anchoring to a permissioned BFT chain with periodic anchoring to Bitcoin/Ethereum strengthens immutability and public verifiability. (verifiedvoting.org)
Universal transparency: on‑chain commitments paired with off‑chain proofs (mixnet shuffles, homomorphic tallies) enable anyone to verify correctness without revealing votes. (verificatum.org)
Governance scenarios (DAOs, corporate votes): on‑chain ZK voting with anti‑collusion (e.g., MACI) gives receipt‑freeness and public verifiability. (maci.pse.dev)

Not helpful

Transporting marked ballots over the internet: still considered high risk for public elections. Blockchain does not fix client‑side malware, coercion, or compromised servers. The Voatz case study underscored these risks. (cisa.gov)

3) Architecture patterns that work in 2025

Pattern A: “Bulletin‑board first” for public elections

Use blockchain as a verifiable publication layer for artifacts generated by a paper‑based, E2E‑verifiable election.

Core components

Paper ballots and RLA: produce cast vote records (CVRs) from scanners; run an RLA (ballot‑polling or comparison). Publish manifests, seeds, and outcomes as hash commitments on a permissioned chain; optionally anchor to Bitcoin via OpenTimestamps or Chainpoint. (verifiedvoting.org)
Cryptographic bulletin board: a permissioned chain (Tendermint/CometBFT or HotStuff‑style BFT) replicated by county/state nodes. Target: ≤1–2s finality; ≥3f+1 validator nodes; hardware/ops under election authority control. (docs.tendermint.com)
Anchoring: hash weekly/daily block headers to a public chain for extra durability. Keep PII off‑chain; post only hashes, Merkle roots, and proofs. (opentimestamps.org)

What gets posted on‑chain (examples)

Hash of the CVR export and precinct‑level results; RLA random seed and sample list; cryptographic proofs from any E2E subsystem (e.g., ElectionGuard if used to add end‑to‑end checks to optical scan workflows). (verifiedvoting.org)

Why it’s deployable

Compatible with VVSG 2.0’s software independence and air‑gap requirements because you never use the chain to transmit marked ballots or control tabulators. (eac.gov)

Pattern B: E2E‑verifiable online voting for private governance

For DAOs, associations, or shareholder votes.

Core components

Registration and eligibility: bind identities at NIST IAL2 via supervised or conventional remote proofing; issue credentials/keys for voting. Avoid KBV‑only flows. (pages.nist.gov)
Ballot secrecy and verifiability: pick one of:
- Homomorphic tally (e.g., ElectionGuard’s ElGamal‑style): encrypt votes client‑side; publish ciphertexts; tally via homomorphic addition; publish ZK proofs; decrypt tally with threshold keys. (electionguard.vote)
- Mixnet tally (Verificatum): encrypt votes; mix servers shuffle + re‑encrypt with publicly verifiable proofs (e.g., Terelius‑Wikström or Bayer‑Groth proof of shuffle). (verificatum.org)
- ZK anti‑collusion (MACI): voters submit encrypted commands; off‑chain tally produces zk‑SNARK proofs verified on‑chain; prevents receipts and reduces bribery/collusion risk. (maci.pse.dev)
Bulletin board: a permissioned BFT chain stores commitments to ballots, proofs, and final tallies; optional anchoring to a public chain.

Performance notes

CometBFT/Tendermint commonly supports up to ~10k tx/s with fast finality in permissioned settings—ample for most organizational elections. (github.com)

Pattern C: Hybrid “results transparency” pilot with paper primacy

For jurisdictions exploring transparency pilots without touching tabulation:

After canvass, publish: precinct‑level results, CVR hash trees, chain‑of‑custody artifacts, and RLA outcomes on a permissioned chain anchored to Bitcoin. Zero operational impact on ballot‑marking or scanners; maximal public verifiability. (verifiedvoting.org)

4) Threat modeling: what to defend and how

We recommend combining STRIDE (security) and LINDDUN (privacy) with scoped mitigations for blockchain‑enabled voting.

Security (STRIDE)

Spoofing: fake voter identities or validator nodes. Mitigate with IAL2 proofing (no KBV‑only), mTLS between components, and HSM‑backed keys for validators/guardians. (pages.nist.gov)
Tampering: altering CVRs, proofs, or blocks. Mitigate with authenticated data structures (Merkle trees), write‑once anchored proofs (OTS/Chainpoint), and BFT consensus (≥2/3 finality). (opentimestamps.org)
Repudiation: denial of actions. Mitigate with threshold signatures for key ceremonies and signed publication checkpoints. Use NIST threshold cryptography guidance for scheme selection. (nist.gov)
Information disclosure: leaking voter choices via metadata. Encrypt ballots client‑side; delay and batch transactions; avoid public mempools (submit via relayers/coordinators); ensure proofs reveal no selections. (maci.pse.dev)
Denial of service: network or consensus flooding. Use permissioned validator sets, rate limiting, separate intake from consensus network, and pre‑baked offline publication of proofs if needed. (docs.tendermint.com)
Elevation of privilege: admin key misuse. Mitigate with M‑of‑N threshold admin operations, auditable key ceremonies, and hardware isolation. Follow NIST threshold scheme roadmaps. (csrc.nist.gov)

Privacy (LINDDUN)

Linkability and Identifiability: correlating on‑chain submissions to voters. Use anonymous credentials (e.g., Semaphore‑style group membership proofs), MACI receipt‑freeness, and traffic shaping. (docs.semaphore.pse.dev)
Detectability: inferring participation times. Batch, pad, and add cover traffic; store only commitments and proofs on‑chain. (linddun.org)
Non‑compliance: GDPR/PII on immutable ledgers. Keep all PII off‑chain; store only hashes and proofs; document retention and destruction schedules. (nist.gov)

Risk acceptance boundaries

For U.S. public elections, internet ballot return remains outside acceptable risk; no blockchain design changes that. If you’re evaluating mobile voting pitches, require independent cryptanalysis and transparency—Voatz is a cautionary tale. (cisa.gov)

5) Cryptography choices that won’t age badly

End‑to‑end verifiability: well‑studied methods exist—Helios (homomorphic tally) for low‑coercion settings; mixnets with publicly verifiable shuffles for stronger anonymity; ElectionGuard SDK for modern homomorphic audits. (usenix.org)
Threshold cryptography: use M‑of‑N guardians for key ceremonies and decryption; align with NIST’s threshold cryptography roadmap (NISTIR 8214/8214A, 8214C draft). (csrc.nist.gov)
Post‑quantum planning: ballots require decades of secrecy. Start migrating signature/KEM layers used for eligibility credentials, bulletin board anchoring, and notarization to NIST‑approved PQC: ML‑DSA (FIPS 204) for signatures; ML‑KEM (FIPS 203) for key establishment; SLH‑DSA (FIPS 205) as a backup. (nist.gov)
Proof systems: for anti‑collusion voting (MACI), zk‑SNARKs with on‑chain verification are production‑proven in governance; for mixnets, prefer shuffle proofs with audited implementations (e.g., Bayer‑Groth machine‑checked verifiers). (maci.pse.dev)

6) Practical, precise implementation guidance

Key ceremonies and custody

Use threshold key generation with independent guardians across organizations (e.g., election officials + external auditors). Publish ceremony transcripts and commitments on the chain; never store complete private keys anywhere. Follow NIST threshold guidance. (csrc.nist.gov)

Bulletin board chain (permissioned BFT)

Consensus: Tendermint/CometBFT or HotStuff‑family (≥3f+1, finality on 2/3 votes). These deliver deterministic finality (no reorgs) which is ideal for audit logs; target block times ~1–2s. (docs.tendermint.com)
Data model: only store content hashes, Merkle roots, and proof artifacts (ZK verifiers can live off‑chain with on‑chain commitments). Avoid PII to stay out of data retention traps. (nist.gov)
Public anchoring: periodically anchor the permissioned chain’s block headers to Bitcoin via OpenTimestamps (OTS) or Chainpoint. Store the .ots/.chp proof files with your canvass artifacts. (opentimestamps.org)

E2E verifiability subsystem

Homomorphic tally path (ElectionGuard): encrypt votes; publish encrypted ballot set and NIZK proofs; guardians perform threshold decryption of the aggregate only. Provide a voter‑facing tracker for “recorded as cast, tallied as recorded.” (electionguard.vote)
Mixnet path (Verificatum): publish shuffle transcripts with proofs (e.g., TW/BG) on the bulletin board; independent verifiers can check universal verifiability. (verificatum.org)
Anti‑collusion path (MACI): tally off‑chain; submit zk‑proofs on‑chain; maintain receipt‑freeness and deter bribery/collusion for DAO votes and grants. (maci.pse.dev)

Identity and eligibility

For private elections, adopt IAL2 remote proofing: multi‑factor evidence, address confirmation codes, and optional supervised flows; avoid KBV‑only identity checks. Bind credentials via AAL2 authenticators. (pages.nist.gov)

Audits and public confidence

Run RLAs for paper‑based elections and publish the random seed, sample list, and outcomes as on‑chain commitments; this lets third parties recompute the process. (verifiedvoting.org)
For online private elections, publish complete verifier artifacts: encrypted ballots, proofs, final tallies, and the exact verifier code or hashes. Cite the algorithms and parameter sets used.

Operational hardening

Separate networks: keep voting devices and EMS offline/air‑gapped; your bulletin board node can be physically separate and fed via offline‑to‑online transfer with signed artifacts. This adheres to VVSG 2.0’s posture. (eac.gov)
No internet ballot return in public elections: if law compels exceptions, limit to narrow populations with explicit risk disclosures and enhanced controls, per CISA/EAC/FBI/NIST guidance. (cisa.gov)

7) Worked examples

Example 1: County transparency pilot (paper‑based election)

Inputs: CVRs, precinct results, chain‑of‑custody logs, RLA config and results.
Process: hash each artifact; write Merkle roots to a permissioned BFT chain operated by county + state + independent observers; weekly, anchor chain headers to Bitcoin via OTS. Publish a public portal that recomputes and verifies all commitments. (opentimestamps.org)
Outcome: zero changes to tabulation; major gain in public verifiability.

Example 2: DAO budget vote with anti‑collusion guarantees

MACI deployment on an EVM chain: registration with signed keys; votes encrypted and posted; off‑chain coordinator tallies and posts zk‑proofs; on‑chain contracts verify. Export roots/proofs to a permissioned chain for long‑term anchoring. (maci.pse.dev)

Example 3: Shareholder meeting with E2E verifiability

IAL2 identity proofing for voters; ballots encrypted client‑side; homomorphic tally (ElectionGuard‑style); threshold decryption of aggregate; publish proofs and commitments to a permissioned chain; anchor to Bitcoin. (electionguard.vote)

8) Lessons from failures and audits

Mobile/blockchain voting without full transparency is unacceptable risk for public elections. The Voatz analysis found vulnerabilities enabling vote manipulation and privacy breaches; regardless of vendor rebuttals, the academic consensus and CISA posture remain cautionary. (usenix.org)
Even advanced E2E systems can stumble: the 2019 SwissPost e‑voting system had critical cryptographic issues in its shuffle proofs—reinforcing the need for independently verifiable cryptography and audits. (crypto.stackexchange.com)

9) Emerging practices to watch in 2025–2027

Standardized threshold crypto: NIST’s threshold cryptography work (IR 8214 series) is maturing—expect clearer recommendations for threshold signatures and decryption used in guardianship models. (csrc.nist.gov)
Post‑quantum migration: FIPS 203/204/205 are final; start PQC‑enabling bulletin‑board signing/KEM layers and identity credentials (long‑term ballot secrecy demands it). (nist.gov)
Machine‑checked proofs: formal verification of shuffle proofs (e.g., Bayer‑Groth) is progressing; prefer implementations with machine‑checked verifiers where possible. (usenix.org)

10) Build checklist: from RFP to pilot

Security and compliance

Scope internet exposure: no internet ballot return for public elections; if any remote ballot marking is allowed for accessibility, require paper return. (cisa.gov)
Define the bulletin board: permissioned BFT network, validator governance, evidence retention, and public anchoring cadence (e.g., every N blocks via OTS). (docs.tendermint.com)
Choose E2E path: homomorphic (ElectionGuard‑style), mixnet (Verificatum), or ZK anti‑collusion (MACI) depending on use case and coercion risk. (electionguard.vote)
Identity proofing: adopt NIST SP 800‑63 IAL2 practices (address confirmation, multi‑evidence, minimal KBV). (pages.nist.gov)

Engineering

Publish everything needed for independent verification: inputs, commitments, proofs, and verifier code hashes.
Keep PII off‑chain; store only hashes and proofs to avoid immutability/privacy conflicts. (nist.gov)
Use threshold ceremonies with multiple independent guardians; publish ceremony artifacts. (csrc.nist.gov)

Auditability

If paper‑based: run an RLA and post commitments; if online private: publish universal verifiability artifacts. (verifiedvoting.org)

Bottom line

For U.S. public elections in 2025, the safe and compliant use of blockchain is as a verifiable bulletin board for transparency—paired with paper ballots and RLAs—not as a channel for marked ballots. (eac.gov)
For private governance, E2E‑verifiable, privacy‑preserving, and anti‑collusion voting is practical today using homomorphic tally, mixnets, or MACI, with a permissioned BFT chain providing an immutable audit trail and optional anchoring to Bitcoin. Start PQC‑enabling signatures/KEMs now. (electionguard.vote)

If you’re planning a pilot, start small: publish audit artifacts for a paper election on a permissioned chain, anchor to Bitcoin, and invite external verifiers to check your proofs. That single, concrete step demonstrably improves transparency without increasing risk. (opentimestamps.org)

References (selected)

VVSG 2.0 adoption and requirements; first 2.0 certification (2025). (eac.gov)
Electronic ballot return risk (CISA/EAC/FBI/NIST, 2024 release of guidance). (cisa.gov)
National Academies “Securing the Vote” (internet voting not secure at present). (nap.nationalacademies.org)
Risk‑Limiting Audits explained (Verified Voting). (verifiedvoting.org)
ElectionGuard (homomorphic E2E‑V). (electionguard.vote)
Verificatum mixnet and shuffle proofs (TW/BG). (verificatum.org)
MACI and Semaphore (anti‑collusion, anonymous group proofs). (maci.pse.dev)
Tendermint/CometBFT and HotStuff (BFT consensus for permissioned chains). (docs.tendermint.com)
PQC standards FIPS 203/204/205 (2024). (nist.gov)
Voatz security analysis (MIT/USENIX). (usenix.org)

Description: A concrete blueprint for using blockchain to improve election transparency—without violating U.S. guidance—plus threat models and implementable architectures for private online voting that combine E2E verifiability, BFT finality, and modern zero‑knowledge techniques.