This post is a deep dive into my thoughts on creating the Voter Hub. It may become a bit more technical than you desire. You can find the accompanying Plain English version here.
In 2024, I introduced the VoterHub concept as the foundation for replacing the United States’ fractured voting infrastructure with a decentralized, citizen‑controlled system built on modern identity standards and Hedera Hashgraph’s consensus network. That initial work focused on the core failures of the current model: declining trust, outdated and error‑prone voter rolls, and the absence of a verifiable identity layer capable of supporting national‑scale elections without concentrating power in a single database or authority.
Over the past year, the conversation around digital identity has matured, and discussions with developers, identity specialists, and civic‑tech practitioners have clarified one thing:
The limiting factor is no longer technical feasibility but institutional architecture.
If VoterHub is to grow from a bold proposal into the backbone of a new national voting system, it needs a governance structure, standards, and operational rules that are credible enough for states, cities, and institutions to adopt in stages.
This document advances VoterHub from a problem statement and end‑state vision to a structured, standards‑driven framework for the identity and verification layer that will ultimately underpin a fully decentralized voting system. It outlines the governance model, DID method, threat model, and phased rollout plan required to validate the system through controlled pilots and to build the trust necessary for eventual nationwide replacement of today’s voter rolls and ballot‑casting infrastructure. The goal is not to dilute the original vision, but to define the structure that makes it buildable—step by step, from local pilots to state‑level adoption and, ultimately, a new national voting architecture grounded in citizen‑owned digital identity.
Design Principles
A national decentralized voter ID system must be grounded in clear, non‑negotiable principles that guide its architecture, governance, and implementation. The following principles define the foundation of VoterHub:
1. Citizen Control
Individuals must control their own credentials and private keys. No authority — state, federal, or private — may access or replicate them.
2. Minimal Disclosure
Verification must reveal only what is necessary to confirm eligibility, using selective disclosure and zero‑knowledge proofs.
3. Institutional Neutrality
The system must operate independently of political cycles, partisan influence, or proprietary platforms.
4. Federated Governance
No single entity may control issuance, verification, or rulemaking. Governance must be multi‑stakeholder and transparent.
5. Interoperability
The framework must align with W3C, NIST, and global digital ID standards to ensure compatibility across states and systems.
6. Auditability Without Surveillance
All state changes must be publicly auditable without exposing personal data or enabling correlation.
7. Portability and Longevity
The system must be adaptable to future technologies and remain functional across decades of institutional evolution.
1. Acknowledging the Original Vision
Last year I introduced the VoterHub concept as a national framework for decentralized voter identification built on Hedera Hashgraph. The intent was simple: demonstrate that modern identity standards, zero‑knowledge proofs, and high‑throughput consensus networks could restore trust in U.S. elections by replacing outdated voter rolls with a verifiable, citizen‑controlled digital identity. That first post established the “why” — the trust crisis, the turnout collapse, and the need for a secure, scalable, non‑partisan identity layer capable of supporting 193 million voters.
2. What I’ve Learned Since
Over the past year, it has become clear that the technical feasibility of VoterHub was never the real barrier — the deeper challenge is institutional architecture. Developers, identity specialists, and civic‑tech leaders consistently asked the same questions: Who governs the system? Who issues and revokes IDs? How is privacy guaranteed? What is the threat model? How do pilots scale into standards? These conversations revealed the blind spot in the original proposal: a national decentralized voter ID system is not just a technical build; it is a governance framework, a standards body, and a multi‑stakeholder ecosystem. The follow‑up must shift from “here’s the idea” to “here’s the structure, the governance, and the phased path to implementation.”
3. Governance Model
A national decentralized voter ID system cannot rely on a single authority, platform, or political entity. It requires a governance structure that is transparent, multi‑stakeholder, and resilient enough to operate independently of election cycles or partisan influence. The appropriate model is a federated governance framework composed of three layers: (1) a Standards Council responsible for defining the DID schema, verification protocols, privacy requirements, and interoperability rules; (2) an Issuance Authority Network composed of state‑level agencies and certified partners responsible for identity verification and credential issuance; and (3) an Independent Audit and Oversight Board tasked with continuous security review, public reporting, and validation of system integrity. Hedera’s role is strictly infrastructural — providing consensus and timestamping — while governance, issuance, and oversight remain distributed across recognized civic and institutional actors.
This structure ensures that no single organization controls the identity system, no private entity can monopolize issuance, and no political body can unilaterally alter the rules. The Standards Council defines the technical constitution; the Issuance Network executes identity lifecycle operations; and the Oversight Board provides transparency, accountability, and public trust. This separation of powers is essential: it aligns with global digital ID best practices, reduces systemic risk, and creates a governance model that can scale from pilot projects to national adoption without compromising neutrality or security.
4. DID Method Outline
A national decentralized voter ID system requires a clearly defined DID method that establishes how identities are created, anchored, verified, updated, and revoked on Hedera Hashgraph. The method must follow W3C DID standards to ensure interoperability with existing identity ecosystems while remaining tailored to the unique requirements of voter identification. At a high level, the VoterHub DID method consists of five core components: (1) Identifier Structure, defining the format of a did:hedera:voter identifier and its associated DID Document; (2) Key Management, specifying the cryptographic keys used for authentication, signature verification, and zero‑knowledge proof generation; (3) Anchoring and State Changes, outlining how DID creation, updates, and revocations are recorded on Hedera’s consensus service with immutable timestamps; (4) Verification and Privacy Controls, establishing how verifiers confirm eligibility without accessing personal data, using selective disclosure and ZKPs; and (5) Revocation and Recovery, defining procedures for lost keys, compromised credentials, and lifecycle management.
The DID method must be deterministic, publicly documented, and governed by the Standards Council introduced in Section 3. Issuance authorities (state agencies or certified partners) create and sign the initial DID Document, while citizens retain control of their private keys within a secure wallet. Verification relies on cryptographic proofs rather than personal information, ensuring that eligibility can be confirmed without exposing identity attributes. Revocation events — such as a lost device or legal status change — are published to the Hedera network through standardized transactions, allowing verifiers to check credential validity in real time. This structure ensures that the VoterHub DID method is interoperable, privacy‑preserving, auditable, and capable of supporting both small‑scale pilots and national deployment.
5. Threat Model Overview
Any national‑scale decentralized voter ID system must be designed with a formal threat model that anticipates adversaries, operational failures, and systemic vulnerabilities. The purpose of the threat model is not to imply fragility but to demonstrate that the architecture accounts for realistic risks across the entire identity lifecycle. At a high level, the VoterHub threat model addresses five categories: (1) Identity Compromise, including lost devices, stolen private keys, and social‑engineering attacks; (2) Infrastructure Attacks, such as denial‑of‑service attempts, consensus manipulation, or endpoint compromise; (3) Insider Risks, including misuse of issuance authority credentials or unauthorized access to verification systems; (4) Privacy Violations, such as correlation attacks, metadata leakage, or attempts to infer voter behavior; and (5) Governance Failures, including misaligned incentives, unclear revocation procedures, or inconsistent implementation across states.
Mitigation strategies are built into the architecture rather than added afterward. Private keys are citizen‑controlled and recoverable through multi‑party recovery mechanisms without exposing identity attributes. Issuance authorities operate under strict, auditable signing policies, and all state changes — creation, update, revocation — are immutably timestamped on Hedera’s consensus layer. Zero‑knowledge proofs ensure that eligibility can be verified without revealing personal data, preventing correlation or inference attacks. Independent auditors continuously test the system for vulnerabilities, while the governance framework ensures that no single entity can alter rules, suppress revocations, or manipulate verification logic. The threat model is not static; it evolves through public review, red‑team exercises, and ongoing collaboration with security researchers to ensure long‑term resilience.
6. Phased Rollout Plan
A national decentralized voter ID system cannot be deployed in a single step; it must progress through controlled, measurable phases that validate the technology, governance, and operational processes before any large‑scale adoption. The rollout plan follows a six‑phase progression, each designed to test a specific layer of the system while minimizing risk and maximizing institutional learning.
Phase 1 — DID Issuance Pilot (Controlled Environment)
A small, voluntary cohort (e.g., a university, a civic‑tech organization, or a municipal partner) receives decentralized IDs issued through certified authorities. This phase validates identity proofing, issuance workflows, wallet usability, revocation procedures, and key recovery mechanisms. No voting functionality is included.
Phase 2 — Verification Pilot (Eligibility Without Voting)
The same cohort participates in a simulated “check‑in” process where eligibility is verified using zero‑knowledge proofs. This phase tests verifier logic, selective disclosure, privacy guarantees, and the performance of Hedera’s consensus service under moderate load.
Phase 3 — Network Stress Test (Technical Scalability)
A synthetic load test simulates millions of DID verifications and state changes to validate throughput, latency, and resilience. This phase ensures that Hedera’s infrastructure can support national‑scale operations and that the DID method behaves predictably under peak demand.
Phase 4 — Municipal Election Pilot (Low‑Risk Real‑World Use)
A small municipality conducts a local election using VoterHub for identity verification and ballot access. Paper ballots remain the official record, but the pilot demonstrates real‑world usability, accessibility, and operational readiness. Independent auditors evaluate performance and publish findings.
Phase 5 — State‑Level Pilot (Full Lifecycle Test)
One state voluntarily adopts VoterHub for a statewide election cycle, including issuance, verification, revocation, and post‑election auditing. This phase validates interoperability across counties, integration with existing systems, and the governance model’s ability to handle real‑world complexity.
Phase 6 — National Standardization
After successful pilots and public audits, the Standards Council publishes the national VoterHub specification. States adopt the framework at their own pace, supported by certified issuance authorities, independent auditors, and a mature governance ecosystem. Hedera remains the consensus layer, but the system is designed to be portable, interoperable, and future‑proof.
This phased approach ensures that VoterHub evolves from concept to national infrastructure through evidence, transparency, and iterative validation — not assumptions or abrupt transitions. It demonstrates technical feasibility, institutional readiness, and public trust before any large‑scale deployment, and provides the standardized foundation required to transition from today’s fragmented voting machinery to a fully decentralized national voting system over time.
7. Call for Specific Technical Roles
With the governance framework, DID method, threat model, and phased rollout plan now defined at a high level, the next step is assembling a focused group of contributors who can translate the architecture into working prototypes. The goal is not to gather a large crowd but to recruit a small, highly capable set of specialists who understand decentralized identity, distributed consensus, and civic‑grade security requirements. The following roles represent the minimum technical foundation required to begin Phase 1 and Phase 2 pilots:
- 1. Hedera Consensus Service (HCS) Architects – Engineers with experience designing high‑throughput, audit‑grade workflows on Hedera. Their role is to define how DID state changes, revocations, and verification events are anchored to the network with predictable performance and cost.
- 2. Decentralized Identity (DID) and Verifiable Credential (VC) Engineers – Specialists familiar with W3C DID standards, credential schemas, selective disclosure, and zero‑knowledge proof frameworks. They will shape the DID method, credential formats, and verification logic.
- 3. Wallet and Key‑Management Developers – Engineers capable of building or adapting secure, user‑friendly wallets that support key generation, recovery, and ZKP interactions. Their work ensures that citizens can control their credentials without compromising usability or security.
- 4. Security and Cryptography Reviewers – Independent experts who can evaluate the DID method, ZKP implementation, key‑recovery mechanisms, and revocation processes. Their role is to validate assumptions, identify weaknesses, and ensure the system meets civic‑grade security standards.
- 5. Civic‑Tech Integration Engineers – Developers experienced in connecting identity systems to existing government workflows, such as DMV, SSA, or state election systems. Their work ensures that pilots can operate alongside current infrastructure without disruption.
- 6. Accessibility and UX Specialists – Designers who understand the needs of rural communities, older populations, and users with limited technical experience. Their role is to ensure that the system is inclusive, intuitive, and deployable at a national scale.
- 7. Independent Auditors and Observers – Professionals who can evaluate pilot performance, publish transparent reports, and validate that governance, privacy, and security requirements are being met. Their presence is essential for public trust and institutional credibility.
This targeted recruitment approach ensures that VoterHub begins with a disciplined, technically competent foundation rather than an unfocused open call. Each role contributes to a specific layer of the architecture, and together they form the core team required to move from concept to operational pilot.
8. Invitation to Join a Working Group
With the foundational architecture now defined, the next step is to establish a small, focused working group responsible for shaping the first two phases of the VoterHub initiative. This group is not a public forum and not an open community call; it is a structured collaboration between identity engineers, Hedera specialists, security reviewers, and civic‑tech practitioners who understand the requirements of building verifiable, privacy‑preserving public infrastructure. The working group’s mandate is to refine the DID method, finalize the issuance and verification workflows, document the threat model, and prepare the technical specifications required for the initial pilot deployments.
Participation is voluntary but selective. Contributors should have demonstrable experience in decentralized identity, distributed consensus, cryptography, secure wallet design, or civic‑grade system integration. The objective is to produce a clear, implementable specification — not to debate the existence of the problem or the need for modernization. Individuals or organizations interested in contributing to this structured effort may contact me directly to discuss alignment, scope, and next steps. The goal is to assemble a disciplined team capable of moving VoterHub from conceptual architecture to operational prototype through transparent, standards‑driven collaboration.
9. Scope and Limitations
A national decentralized voter ID framework must be explicit about its scope to avoid misinterpretation and ensure that stakeholders understand both its capabilities and its boundaries.
VoterHub begins as an identity and verification infrastructure and does not immediately replace existing ballot‑casting procedures. Its purpose is to provide a secure, interoperable, citizen‑controlled identity layer that states can use both to verify eligibility and prevent duplicate or invalid registrations, and as the foundation for transitioning from today’s voting system to a fully decentralized one over time.
VoterHub provides a standards‑aligned architecture that can be integrated into existing systems, but it does not require states to abandon their current infrastructure on day one. Additionally, while the system is designed to support national scale, early pilots will be limited in scope to ensure that governance, privacy, and security controls function as intended. These limitations are intentional: they ensure that VoterHub remains a neutral, interoperable identity framework during the transition period, rather than a centralized election technology platform.
10. Why This Matters Now
The window for modernizing voter identification is defined not by political cycles but by technological convergence. Over the past several years, decentralized identity standards, zero‑knowledge proof frameworks, and high‑throughput consensus networks have matured to the point where they can support verifiable, privacy‑preserving public infrastructure at a national scale. At the same time, states are reassessing their identity systems, federal agencies are exploring digital credentialing, and global partners are deploying interoperable digital ID frameworks. This alignment creates a rare opportunity: the technical, institutional, and standards ecosystems are now capable of supporting a decentralized voter ID system that would have been impractical a decade ago.
Acting now also ensures that modernization efforts are guided by open standards rather than proprietary platforms. If states move independently without a shared framework, the result will be fragmented systems, inconsistent privacy protections, and limited interoperability. VoterHub provides a structured alternative — a neutral, standards‑aligned architecture that states can adopt at their own pace while maintaining compatibility and public trust. The timing is not driven by urgency for rapid deployment but by the recognition that the foundational technologies, governance models, and institutional readiness have finally aligned. This is the moment to define the framework before disparate solutions fill the vacuum.
11. Next Deliverables
With the foundational framework now defined, the next phase of work requires producing a set of concrete deliverables that translate the high‑level architecture into implementable specifications. These deliverables are not optional; they form the technical and governance artifacts that developers, auditors, and institutional partners will rely on during pilot planning and execution. Each item is designed to be modular, publicly reviewable, and aligned with established digital identity standards.
- 1. DID Method Specification (Version 0.1) – A formal document detailing the
did:hedera:votermethod, including identifier structure, DID Document format, key types, signature algorithms, revocation mechanisms, and anchoring procedures. This specification becomes the technical constitution of the identity layer. - 2. Governance Charter (Draft) – A charter defining the roles, responsibilities, decision‑making processes, and accountability mechanisms for the Standards Council, Issuance Authority Network, and Oversight Board. This ensures clarity before any pilot begins.
- 3. Threat Model and Security Requirements – A structured document outlining adversary models, attack surfaces, mitigation strategies, and required security controls. This becomes the baseline for audits, red‑team exercises, and independent review.
- 4. Pilot Requirements and Evaluation Criteria – A detailed outline of what Phase 1 and Phase 2 pilots must demonstrate, including identity proofing standards, wallet requirements, verification logic, performance thresholds, and audit expectations. This ensures pilots are measurable and comparable.
- 5 Technical Architecture Diagram. – A visual representation of the system’s components — issuance, wallets, verifiers, Hedera consensus, revocation registry, and audit interfaces. This diagram provides clarity for engineers and decision‑makers.
- 6. Implementation Roadmap (6–12 Months) – A timeline identifying milestones, dependencies, working group responsibilities, and expected outputs. This roadmap guides contributors and ensures coordinated progress.
These deliverables form the bridge between conceptual architecture and operational deployment. Once completed, they will enable the first controlled pilots and provide the transparency and structure required for institutional adoption.
12. Glossary of Key Terms
Decentralized Identifier (DID) – A W3C‑standardized, cryptographically verifiable identifier that allows individuals to control their own identity without relying on a centralized authority. In VoterHub, DIDs represent voter identities anchored on Hedera Hashgraph.
DID Document – A JSON‑LD document associated with a DID that contains public keys, service endpoints, and metadata required for verification. It defines how verifiers interact with a given identity.
Verifiable Credential (VC) – A digitally signed credential that asserts specific attributes (e.g., citizenship, residency, age) without exposing personal information. VoterHub uses VCs to confirm voter eligibility.
Zero‑Knowledge Proof (ZKP) – A cryptographic method that allows a user to prove a fact (such as eligibility) without revealing the underlying data. ZKPs ensure privacy during verification.
Hedera Consensus Service (HCS) – A high‑throughput, low‑latency consensus layer used to timestamp and order DID state changes, revocations, and verification events. HCS provides auditability without storing personal data.
Issuance Authority – A state agency or certified partner responsible for identity proofing and issuing voter credentials. These authorities sign the initial DID Document and manage lifecycle events.
Revocation Registry – A publicly auditable record of invalidated or compromised credentials. In VoterHub, revocation events are anchored on Hedera to ensure real‑time verification.
Selective Disclosure – A privacy mechanism that allows users to reveal only the minimum necessary information (e.g., “over 18”) rather than full identity attributes.
Standards Council – The multi‑stakeholder body responsible for defining the technical specifications, governance rules, and interoperability requirements for VoterHub.
Oversight Board – An independent group tasked with auditing security, reviewing governance decisions, and publishing public reports to maintain transparency and trust.
Pilot Cohort – A controlled group of participants used to test issuance, verification, usability, and security before broader deployment.
Interoperability – The ability of identity systems, wallets, and verifiers to work across states, agencies, and platforms using shared standards and protocols.
13. Standards Alignment and References
VoterHub is intentionally aligned with established digital identity and cryptographic standards to ensure interoperability, auditability, and long‑term viability. The framework does not introduce new identity primitives; instead, it builds on widely recognized specifications that have undergone extensive public review. This alignment ensures that states, developers, and auditors can evaluate the system using familiar reference points and proven methodologies.
W3C Decentralized Identifiers (DIDs) – The identity layer follows the W3C DID Core specification, including DID syntax, DID Document structure, key representation, and resolution processes. This ensures compatibility with existing decentralized identity ecosystems.
W3C Verifiable Credentials (VCs) – Credential formats and verification logic adhere to the W3C Verifiable Credentials Data Model, enabling selective disclosure, cryptographic integrity, and interoperability with standards‑compliant wallets and verifiers.
Zero‑Knowledge Proof Frameworks – Privacy‑preserving verification is based on established ZKP libraries and protocols, including BBS+ signatures and emerging W3C ZKP standards. These methods allow eligibility verification without exposing personal data.
Hedera Consensus Service (HCS) – State changes, revocations, and audit events are anchored using Hedera’s consensus layer, which provides deterministic ordering, low‑latency finality, and immutable timestamping. HCS is used strictly for consensus and auditability, not for storing personal information.
NIST Cryptographic Standards – Key generation, signature algorithms, and hashing functions align with NIST‑approved cryptographic primitives to ensure compliance with U.S. federal security guidelines.
Global Digital ID Frameworks – The governance and interoperability model draws on best practices from international digital identity systems, including eIDAS 2.0, ISO/IEC identity standards, and national digital ID programs that emphasize privacy, portability, and multi‑stakeholder governance.
These standards provide the foundation for VoterHub’s technical and institutional credibility. They ensure that the system can be independently evaluated, integrated into existing infrastructure, and adapted as global identity standards continue to evolve.
14. Call for Participation
The next phase of VoterHub requires a small, disciplined group of contributors capable of shaping the first operational specifications and pilot deployments. This is not an open community forum; it is a focused working group composed of identity engineers, Hedera specialists, cryptographers, civic‑tech integrators, and security reviewers who understand the requirements of building verifiable, privacy‑preserving public infrastructure.
Individuals or organizations with relevant expertise who wish to contribute to the development of the DID method, governance charter, threat model, or pilot requirements are invited to reach out directly. Participation is selective and based on demonstrated experience in decentralized identity, distributed consensus, secure wallet design, or civic‑grade system integration. The objective is to produce clear, implementable specifications that can support controlled pilots and independent audits.
Those interested in joining this structured effort may contact me to discuss alignment, scope, and next steps.
The purpose of this follow‑up is to move VoterHub from a conceptual proposal to a structured, standards‑driven initiative capable of supporting real‑world pilots. The governance model, DID method outline, threat model, and phased rollout plan presented here form the foundation for a system that is technically feasible, institutionally neutral, and operationally scalable. The next step is assembling a focused working group of identity engineers, Hedera specialists, security reviewers, and civic‑tech practitioners to refine the specifications and prepare for controlled pilot deployments. VoterHub is no longer an idea in isolation; it is a framework ready for disciplined collaboration. Those with the expertise and interest to contribute to this effort are invited to engage and help shape the next phase of development.
