Harness Client Matrix

Mocked operator clients before, during, and after voting.

Voting Kiosk

Active

Issue credential, clear challenges, encrypt, and cast.

Admin Console

Election configuration plus registration desk tooling.

Registration Desk

Same-day eligibility checks and credential intake.

Board Audit

Ballot lookup, bulletin-board inspection, and anchors.

Receipt Verification

Signature, Merkle proof, and ledger checks.

Operations Monitor

Fraud alerts, health telemetry, and ledger drift.

Reveal & Tally

Publish close artifacts and oversee results.

Trust Portal

Independent manifest, STH, and key verification.

Interactive Proof-of-Concept

Experience VoteChain

Walk through an election from start to finish. Cast a ballot, verify your receipt, and watch the count — all with real cryptography running in your browser.

Preview the flow

This is the only place you launch the experience — it opens in a modal so the harness and every other operator surface stay visible without duplicate controls.

What the tour covers

  • Blind credential issuance + liveness checks
  • Challenge, encrypt, and cast with deterministic proofs
  • Independent receipt verification and tally publication

All mocked clients stay available in the harness once you start.

1
Start Here ~30 sec

Cast Your Vote

Get a digital credential, prove you're eligible, pick a candidate, and seal your ballot in an encrypted envelope. You'll get a signed receipt when you're done.

What happens behind the scenes?

1. Credential generation — Your browser generates a secp256k1 keypair. This is your digital identity for this election — it never leaves your device.

2. Blind issuance — A simulated registration authority issues a blind Schnorr signature. "Blind" means it certifies you without learning which key is yours. Think of it like getting a notarized stamp through a sealed envelope.

3. Zero-knowledge proof — When you cast, the system proves you hold a valid credential without revealing which credential. The server can verify "this voter is registered" without knowing "this voter is Alice."

4. Encryption — Your ballot choice is encrypted with the election public key (ECIES). Nobody can read your vote until the trustees collectively decrypt at tally time.

5. Optional challenge — Before committing, you can "challenge" the machine (Benaloh-style) — it must prove it sealed your real choice. This is auditable without breaking vote secrecy.

Launch the voting client from the primary button above — it opens in a modal, so this walkthrough never disappears.

2
After You Vote ~15 sec

Verify Your Receipt

Take the receipt from Step 1 and independently check: Is the signature valid? Is your sealed ballot on the public board? Was it recorded on the ledger?

Why does this matter?

Ed25519 signature check — Your receipt contains a digital signature from the gateway server. Verification confirms this signature was created with the server's private key, proving the receipt wasn't forged.

Merkle inclusion proof — The receipt includes a hash path proving your sealed ballot exists at a specific position in the bulletin board's Merkle tree. If anyone tampered with the board, the hashes wouldn't match.

Ledger anchor — Finally, the receipt references a VoteChain Ledger transaction ID. Checking this confirms the bulletin board state was committed to the distributed ledger — meaning 3 independent nodes agreed on it.

3
The Payoff ~15 sec

Watch the Count

Open the election monitor. See every ledger event, every bulletin board entry, any fraud flags — then trigger the threshold tally to decrypt and count all ballots.

How does the tally work?

Threshold decryption — The election key was split into shares using Shamir's secret sharing. At tally time, a minimum number of trustees (t-of-n) must contribute their share to reconstruct the decryption key. No single trustee can decrypt alone.

Decryption proofs — Each trustee publishes proof that their contribution was computed correctly. Anyone can verify these proofs independently.

Anchored result — The final tally, all decryption proofs, and the closing Merkle root are anchored to the VoteChain Ledger — creating a permanent, tamper-evident record that all 3 nodes must agree on.

One harness, zero context switching

Cast, verify, monitor, and tally without leaving the modal shell.

The client pills in the harness bar above launch every role in-place. Use the guided journey to tell the story, then pivot to the operator you need without duplicating launchers or navigating away.

Before Voting

Admin + Same-Day Registration

Configure the mock election, manage scopes, and issue credentials. Demo intake by opening the Admin or Same-Day Reg clients from the harness pills.

During Voting

Board Audit + Lookup

Surface the inclusion proofs and public bulletin board without resetting the walkthrough. The Lookup client stays one click away.

Post-Close

Reveal + Tally

Jump straight into the tally dashboard once Step 3 is unlocked. The same modal frame renders the results so your audience never sees a jarring navigation.

Oversight

Monitor + Trust Portal

Show ledgers, fraud alerts, and cryptographic attestations from the monitor and trust clients while the main journey remains visible underneath.

How is this different from real voting?

This POC uses real cryptography — actual Ed25519 signatures, ECIES/AES-256-GCM encryption, Schnorr zero-knowledge proofs, and a distributed ledger across 3 Cloudflare Workers nodes. But it runs entirely in your browser with simulated election data.

Think of it as a flight simulator: the controls are real, the physics are real, but you're not actually 30,000 feet in the air. A production system would add HSMs, air gaps, multi-party key ceremonies, and formal audits.

Session Controls

Reset just your kiosk voter or obliterate the entire election state. These are intentionally isolated so the primary CTA remains focused on casting.