The government building version:

What is this page about?

The main VoteChain blueprint tells you what the system does. This page tells you where each piece lives, who owns it, and why it's kept separate from the other pieces. Think of it like a map of a big government building — which rooms exist, who has the keys, and why certain doors are locked.

The two hallways:

Imagine the building has two long hallways that never connect except through a tiny mail slot in the wall.

• Hallway 1 — "Who are you?" This side checks whether someone is allowed to vote. It has rooms for signing people up, catching fraud, and keeping records. It never sees what anyone voted for.
• Hallway 2 — "What did you vote?" This side handles the actual ballots — encrypted, locked in a box that nobody can open alone. It never knows who cast any particular ballot.
• The mail slot between them only passes a tiny receipt number — not a name, not a ballot. Just proof that "something happened on both sides." That's it.

Five important rooms:

• The sign-up desk. Where you prove who you are. It's in a real, physical office — not online — because the most important step should happen face-to-face.
• The big shared notebook room. 74 people from different groups (states, federal agencies, auditors, and oversight boards) all sit around a table. Nothing gets written down unless most of them agree. No one person can change the book.
• The ballot drop box. A public, see-through box where encrypted ballots go. Anyone can walk by and count the envelopes, but nobody can open them.
• The key-holders' vault. A group of trusted people each hold one piece of a combination lock. You need enough of them together to open the box and count the ballots — and they do it in the open, with proof they did it right.
• The watchtower. Independent guards (journalists, universities, watchdog groups) who stand outside and make sure the drop box isn't being tampered with. They compare notes with each other constantly.

Three ways to visit:

• Mode 1 — Walk in. You go to the polling place and use their device. Simplest and safest.
• Mode 2 — Supervised kiosk. Like using a library computer with a librarian nearby.
• Mode 3 — From home. Possible but locked behind extra safety gates. Not the default.

Why keep the rooms separate?

Because if everything were in one room with one key, whoever holds that key could do whatever they want. Splitting things up means no single person, agency, or company can secretly change what happened. Every room has different guards, different locks, and different people watching.

Want more detail? Slide the bar to the right. Or close this and explore the full architecture with diagrams.

Technical summary:

Scope:

A production architecture specification for the combined VoteChain (verification + fraud-review evidence layer) and EWP (cast-to-tally ballot integrity layer). This document maps server roles, operator boundaries, trust zones, data flows, and deployment modes. It is the "where and why" companion to the main PRD's "what and how."

Two-plane separation (core architectural invariant):

• Eligibility plane (VoteChain): ZK eligibility proofs, nullifier uniqueness enforcement, revocation processing, fraud_flag events, and audit anchor publication. Operates on cryptographic attestations only — no PII, no ballot content.
• Ballot content plane (EWP): ElGamal-encrypted ballots, append-only public bulletin board (BB), STH-signed checkpoints, non-equivocation monitoring, threshold decryption (Pedersen DKG / Shamir), and tally proof publication.
• Sole coupling point: Audit anchors — hash commitments anchored to VoteChain by BB STH signers and EWP gateways. Anchors bind the two planes for auditability without leaking voter–ballot correlation.

Server roles (13 components, minimal pilot set):

• Registration Authority cluster: enrollment-service (in-person, state offices), attestation-issuer (HSM-backed, produces signed pillar attestations without on-chain PII), recovery-service (in-person Shamir recovery governance).
• Election Authority services: fraud-detection-engine (ingests SSA/vital/judicial feeds, emits fraud_flag events), oversight-portal (role-gated case management + evidence bundles + audit exports), tally-publisher (publishes final tally artifact + proof bundle, anchors tally hash to VoteChain).
• VoteChain Ledger: votechain-ledger — 74-node permissioned BFT network (Federal 6, State 50, Auditor 12, Oversight 6). Category-quorum consensus: 3-of-4 categories, each ≥2/3 intra-category. votechain-read-api — multi-operator, cached, replicated read path for client/monitor anchor verification.
• Bulletin Board: bb-log (append-only transparency log for encrypted ballots + election artifacts), bb-sth-signer (HSM-backed, signs checkpoints so equivocation is detectable when monitors compare STH histories and demand consistency proofs).
• Threshold Trustees: trustee-service — dedicated HSM environments for air-gapped key ceremony (DKG), partial decryptions at tally, and publication of decryption/shuffle proofs. No single trustee holds a complete decryption key.
• EWP Gateways: ewp-gateway × N (≥2 operator categories, geo-redundant). Handles manifest distribution, cast receipt anchoring (nullifier + leaf_hash + sth_hash → VoteChain), and failover for anti-disenfranchisement.
• Independent Monitors: monitor instances run by academic, NGO, media, and government parties. Continuously fetch BB STH + inclusion/consistency proofs, cross-check against VoteChain anchors via read API. Detect equivocation (split views), anchor gaps (suppression), and checkpoint staleness.

Trust zone boundaries:

• Election Authority zone: Enrollment, attestation issuance, fraud detection, oversight, tally publication. Trusted for operational processes but not for unilateral ledger writes — all writes go through consortium consensus.
• Consortium zone: Ledger nodes + write gateway. No single category can finalize a transaction. Write access requires multi-category quorum; read access is public and replicated.
• Trustee zone: Air-gapped key material. Trustees interact only at key ceremony (pre-election) and tally decryption (post-election). HSM attestation binds trustee identity to key shares.
• Public zone: BB log, VoteChain read API, published artifacts. Designed to be fully auditable by any party without special access.
• Monitor zone: No write access to any system. Read-only cross-verification against both BB and VoteChain. Independence is structural — monitors operate their own infrastructure with no dependency on election authority or consortium services.

Air-gapped key ceremonies:

Threshold key generation uses Pedersen DKG (or equivalent verifiable secret sharing) conducted in an air-gapped environment. Key shares are distributed to trustees on HSM-backed devices. The public encryption key is published and anchored to VoteChain. Compromise of fewer than the threshold number of trustees does not compromise ballot secrecy. Key ceremony transcripts are published for independent verification.

Non-equivocation monitoring:

BB checkpoints (STHs) are signed by HSM-backed keys and anchored to VoteChain. Monitors fetch STHs from multiple vantage points and compare. Any divergence (split view) constitutes detectable equivocation. Monitors can demand consistency proofs between any two STHs. Anchor gaps (missing or delayed anchors) trigger public alerts. The design follows the Certificate Transparency model: trust is established through gossip and cross-verification, not through trusting the log operator.

Degraded-mode behavior:

• Gateway failure: Voters failover to alternate EWP gateways (≥2 operator categories ensure no single-operator SPOF). Provisional ballots issued if all gateways are unreachable.
• Ledger partition: If category-quorum is lost, writes queue and the system operates in read-only mode against the last consistent state. Verification events are logged locally and reconciled post-partition.
• BB unavailability: Gateways buffer encrypted ballots locally (signed, timestamped). Upon BB recovery, buffered ballots are appended and anchored. Monitors flag the gap in STH continuity.
• Trustee unavailability at tally: Threshold scheme tolerates up to t-1 absent trustees. If threshold is not met, tally is delayed (not abandoned) until sufficient trustees participate.
• Monitor divergence: If monitors report conflicting STHs, all anchored STH history is published for independent analysis. The system halts tally until consistency is restored or the equivocation is explained.

Deployment modes and security posture:

• Mode 1 (in-person): Election-authority-controlled device, physical presence attestation, air-gapped or hardened network. Highest assurance. Primary pilot target.
• Mode 2 (supervised kiosk): Dedicated kiosk with poll-worker presence attestation. Controlled environment, reduced attack surface vs. personal devices. Co-primary pilot target.
• Mode 3 (unsupervised remote): Personal device, no physical presence guarantee. Explicitly gated: requires additional client-side attestation (device integrity, liveness), elevated monitoring thresholds, and governance approval before activation per jurisdiction. Not a default.

The full document below includes four Mermaid diagrams: high-level ownership map, 74-node consortium topology, EWP cast-to-tally sequence, and a dense full-alignment map with all 13 server components and their data flows.