Research, not a deployment

MVE is experimental. It is not certified, approved, or intended for any official election. Architecture, cryptography, software, hardware, law, and operations require extensive independent review before any real-world use.

Research / Prototype — Not for real elections. Do not deploy for a real election, polling station, or voter registration system.

Why this project exists

A trustworthy election requires confidence in far more than casting a ballot: eligibility, secrecy, recording, counting, transmission, aggregation, auditing, publication, dispute resolution. A weakness in any one stage can undermine the entire process.

MVE treats elections as a complete verification system — not a voting app. Every digital step must produce independently verifiable evidence.

What the prototype proves today

As of 2026-10-03, a zero-dependency TypeScript prototype runs the full election loop end to end: seeded demo, booth opening under two approvals with firmware and certificate gates, anonymous-token voting with paper slip and commitment-bound receipt, closing under three approvals with reconcile-or-refuse and dual signatures, sealed offline transmission, public portal with API and open dataset, independent verification, risk-limiting audit sampling, and disaster-recovery rebuild.

Proof, not promises: 91 automated tests, strict type-checking, zero audit vulnerabilities, and a privacy lint gate that forbids any voter-to-vote join. Scale evidence: 10,000 simulated stations and 449,898 ballots with full paper trail in about twelve minutes, recounted 10,000 of 10,000 as MATCH. The run guide lives with the code.

Seven core principles

Do not ask citizens to trust the machine. Give them a way to verify the election.
  • 1. Voter privacy. Never create a recoverable link between identity and choice. Eligibility and anonymous ballots live in separated domains.
  • 2. Ballot secrecy. Verify acceptance without transferable proof of choice. Nothing may make vote buying or coercion easier.
  • 3. Voter-verifiable records. Each voter checks a physical record before it enters a secure box — an audit trail no database failure can erase.
  • 4. Cryptographic verification. Every result package carries identity, counts, timestamp, software hash, and signature. Changing one number invalidates verification.
  • 5. No single point of trust. No single admin, server, vendor, or key controls an outcome. Critical operations require multiple parties.
  • 6. Offline-first polling. A station never stops because the connection dropped. Signed sync happens when connectivity returns.
  • 7. Public transparency. Station results, totals, hashes, audits, incidents — independently verifiable. Personal data never exposed.

System architecture

Independent components so compromising one layer never compromises the election. Public portal over a transparency layer of hashes and signatures, fed by result and audit services over an election core. At the edge, each station produces both an encrypted ballot and a paper record.

Identity, configuration, anonymous ballots, audit events, and public records never share a single store. There is deliberately no query that reconstructs who chose whom.

MVE system architecture flowchartPublic Portal feeds the Transparency Layer, which splits into Result Service and Audit Service, rejoining at the Election Core, then Stations A, B and C, Voting Device, Paper Record, and Physical Audit.PUBLIC PORTALResults · Audits · Statistics · Verification APITRANSPARENCY LAYERHashes · Signatures · Public recordsRESULTSERVICEAUDITSERVICEELECTION COREDistricts · Stations · EligibilitySTATION ASTATION BSTATION CVOTING DEVICEPAPER RECORDPHYSICAL AUDIT
  1. Public Portal
  2. Transparency Layer
  3. Result Service and Audit Service
  4. Election Core
  5. Stations A, B, C
  6. Voting Device
  7. Paper Record
  8. Physical Audit

Signed result packages

Each station emits a signed package binding counts to place, machine, and moment. Altering 201 to 301 changes the hash — detectable by anyone holding the dataset.

Signed result packageEvery field of a station result package, sealed by a digital signature. Change one number and verification fails.SIGNED RESULT PACKAGEelectionELECTION-IDpolling_stationSTATION-IDdeviceDEVICE-IDballots_issued487ballots_counted487invalid_ballots0resultsA 201 · B 176result_hashHASHSEALED · DIGITAL-SIGNATURE
Tamper-evident — change one number and the signature dies.
  1. election: ELECTION-ID
  2. polling_station: STATION-ID
  3. device: DEVICE-ID
  4. ballots_issued: 487
  5. ballots_counted: 487
  6. invalid_ballots: 0
  7. results: A 201 · B 176
  8. result_hash: HASH
  9. signature: DIGITAL-SIGNATURE

Audits, observers, and incidents

Risk-limiting audits sample physical ballots against reported totals under rules fixed before election day. Observers file structured incident reports with case numbers. Statistical anomalies flag turnout or timing patterns for human review. An anomaly is a question, never a verdict. AI may assist detection — it must never decide fraud, validity, or outcome.

Polling-station workflow

Before opening, the station proves itself: device identity, firmware integrity, election and ballot configuration, secure storage, keys, hardware state — sealed into an auditable opening record. Opening takes three people: presiding officer, authorized observer, second officer. No single hand opens a station.

During voting the order never varies: check eligibility, confirm no double vote, issue anonymous authorization, private selection, generate the voter-verifiable record, let the voter check it, deposit the paper, seal the electronic ballot, log the audit event. At closing the arithmetic must close — registered, authorized, issued, electronic, physical, unused — and any gap opens an investigation on its own.

Security model

Assume every attacker at once: network operators and botnets, compromised officials and stolen credentials, stolen devices and rogue USB sticks, phishing and coercion, poisoned updates and modified firmware. The answer is zero trust — no component believes another by default.

  • Authenticate everything. Every sensitive operation verifies identity, authorization, and integrity, then signs the event into the audit trail.
  • Keys under threshold. Hardware-backed, rotated, held by many, rooted offline, revocable in emergency. No administrator holds the whole election.
  • Fail drilled. Encrypted sync, disaster rebuild, intrusion detection, independent monitoring — rehearsed, not assumed.

Privacy by separation

Three domains that must never become a hidden join. Identity proves eligibility and stops there. The ballot domain counts anonymously. The audit domain signs device events. A privacy lint gate enforces the separation in code — a voter-to-vote join fails the build.

Privacy separation diagramIdentity, Ballot and Audit are three separated domains. No store joins them.IDENTITYVoter→ Eligibility→ AuthorizationBALLOTAnonymous ballot→ Encrypted vote→ CountingAUDITDevice→ Event→ Signature
No store joins them — no query rebuilds who chose whom.
  1. Identity domain
  2. Ballot domain
  3. Audit domain — never joined

What MVE will not do

  • No remote phone voting in V1. Uncontrolled environments introduce coercion and compromise this architecture refuses.
  • No blockchain-only claims. Ledgers do not solve authentication, malware, or procedure; evaluated only where they add concrete value.
  • No identity-to-vote database. A searchable mapping between citizen and choice must never exist.
  • No AI verdicts, no proprietary crypto, no black boxes. AI flags, humans decide. Standard reviewed cryptography. Open clients and protocols.

Roadmap: prototype done, pilot and review open

Research, architecture, prototype, and adversarial simulation are drilled in code. Controlled pilot and independent review remain fully open — simulation only, no pilot authorized, staffed, or scheduled. Entry runs through staged gates with shadow rules, starting at ten stations.

  • Done in prototype. Election loop, anonymous ballots, result signing and verification, audit sampling, incident intake, public portal and API, and failure drills across network, power, devices, and data loss.
  • Open. Independent cybersecurity and cryptographic review, privacy and legal review, accessibility review, and a controlled pilot under a legal framework that does not yet exist.

Public verification and API

After lawful publication, verification belongs to everyone: station and district results, totals, hashes, audits, incidents, statistics. The portal serves humans; the API serves machines — and neither serves identities or choices.

Public API endpointsEight read-only endpoints. Never voter identities, never individual choices.GET/api/electionsGET/api/elections/{id}GET/api/districtsGET/api/polling-stationsGET/api/resultsGET/api/auditsGET/api/incidentsGET/api/verificationNEVER SERVEDvoter identities · individual choices
Read-only. Never voter identities — never individual choices.
  1. /api/elections
  2. /api/elections/{id}
  3. /api/districts
  4. /api/polling-stations
  5. /api/results
  6. /api/audits
  7. /api/incidents
  8. /api/verification
  9. Never voter identities or individual choices

Technology direction

The stack stays undecided on purpose: security chooses tools, not fashion. The prototype is zero-dependency TypeScript; the backend hardens toward Rust or Go; the edge runs hardened Linux with TPM and secure boot; PostgreSQL plus append-only audit stores sit behind it all.

Open research questions

  • Private inclusion proofs. Verify your ballot counted without proving how you voted.
  • Crypto balance. Which mix of encryption, commitments, and proofs buys security per unit of complexity?
  • Affordable hardware. Strongest protection that stays maintainable and cheap.
  • Offline weeks. Long disconnection without replay or sync attacks.
  • Practical audits. Statistically meaningful sampling that runs in the real world.
  • Equal access. Full accessibility with zero secrecy loss.
  • Key ceremonies. Generate, store, rotate, and recover national keys.
  • Governance. Who controls each component — and what the public can verify without seeing personal data?

Status and license

Independent research — not an official project of the Kingdom, Ministry of Interior, Parliament, or any authority. Personal, educational, non-commercial research use; commercial or governmental deployment requires separate written agreement.

An election system should not ask people to believe the result — it should provide enough evidence to verify why it is correct.