What a development team builds, in what order, and where the two expert reviews slot in. This is the bridge between the finished strategy-and-prototype kit and a certified, election-grade system.
00 Where this starts
You already hold the hard-to-produce parts: the full architecture, a working cryptographic reference implementation that runs and passes its checks, the front-end verification design, and the complete pitch and pilot materials. This roadmap turns that blueprint into software an election can stand on.
Do not hand-roll election cryptography.
The reference code proves the math. Production is built on vetted, audited components — RFC 9474 (RSA blind signatures) and ElectionGuard (encrypted ballots, threshold guardians, zero-knowledge proofs) — not on primitives written from scratch. Reimplementing cryptography from first principles is where verifiable-voting projects fail.
01 The build, in phases
Each phase produces something testable. Do them roughly in order — phases 2 through 4 can overlap once the token layer is stable.
-
1
Harden the token layer
- Replace the demo blind-signature code with an implementation of RFC 9474 (RSA Blind Signatures), using a vetted crypto library — not hand-written primitives.
- Enforce one-token-per-eligible-voter issuance and single-use spending at the ballot box (double-spend rejection).
-
2
Integrate the verifiable tally
- Build the encrypted-ballot and tally layer on ElectionGuard (open source, used in real U.S. elections): encrypted ballots, homomorphic aggregation, threshold guardians, zero-knowledge proofs.
- Stand up the public bulletin board — an append-only, published record of encrypted ballots, proofs, and the final tally, so anyone can verify.
-
3
Build the verification front end
- Enrollment engine: auto-match established voters; flag the rest to verify.
- Integrate a compliant remote identity-proofing / online-notarization provider for the video path (ID check + liveness + tamper-evident session), plus in-person and assisted paths.
- On successful verification, emit one bit (“eligible: yes”) to the token service — no identity crosses over. This is the sever step.
- Build notice-and-cure: every flag carries an easy path to resolve, never a silent removal.
-
4
Voter experience & verification app
- Voter UX for enroll → receive token → cast → receipt → verify inclusion → re-vote (adapt the existing voter-flow demo).
- An independent verification app so voters can confirm their ballot reached the record.
-
5
Paper, audit & operations
- Produce a voter-verifiable paper record and support a risk-limiting audit against it — this is what makes the system software-independent and VVSG-aligned.
- Key ceremony tooling for guardians; HSM-backed key custody; full audit logging.
02 The two reviews
Neither is optional before a binding election. Schedule them early — they shape the build, not just bless it.
| Review | When | What it covers |
|---|---|---|
| Cryptographer / protocol audit | After Phase 2, once the token and tally layers are stable; re-checked before any binding use. | The blind-signature and threshold protocols, proof soundness, key management, the sever step. |
| Election-law counsel | During Phase 3, alongside the front end; before any binding use. | Enrollment tiers, flagging criteria, due process, accessibility, and jurisdiction-specific election law. |
Whether verification is required or voluntary is settled here — with counsel and the jurisdiction — not in code.
03 Recommended stack
Each layer is built on something that already exists and is already named — not a primitive invented for this project.
| Layer | Build on |
|---|---|
| Anonymous tokens | RFC 9474 (RSA Blind Signatures) via a vetted crypto library |
| Encrypted ballots, guardians, proofs, tally | ElectionGuard |
| Remote identity proofing | A compliant RON / identity-proofing provider (approved platform, credentialed notaries) |
| Key custody | HSMs; guardians on separate, adversarial infrastructure |
| Bulletin board | Append-only public log (transparency-log design) |
| Audit | Voter-verifiable paper + risk-limiting audit |
04 Definition of done (before binding use)
A binding election is not run on this system until every item below is true.
- Token layer on RFC 9474; single-use enforced.
- Tally on ElectionGuard; proofs verify independently; bulletin board public.
- Verification front end live, with video, in-person, and assisted paths, and notice-and-cure.
- Paper record and risk-limiting audit in place.
- Cryptographer audit passed; election-law counsel sign-off obtained.
- A non-binding pilot run and its audit published.
05 How this fits alongside everything else
- You can pitch now. The strategy, the manifesto, the one-pager, and this web page don't wait on the build.
- Start the dry run early. The reference implementation already lets you demonstrate the concept while Phases 1 and 2 harden it.
- The first binding pilot comes after “definition of done.” With a paper fallback and a published audit, per the pilot strategy.