Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Crypto-Project-ENSTA/front-end/llms.txt

Use this file to discover all available pages before exploring further.

Evoting is designed around a principle of distributed trust: no single party has enough information or control to alter an election result or trace a ballot back to a voter. This is achieved by dividing election responsibilities across four independent entities, each with a limited and non-overlapping role.

The four independent entities

Voter

The voter is the participant casting a ballot. Their interaction with the system is limited to three actions:
  1. Register — submit an email address during the registration phase to receive N1 and N2 codes.
  2. Authenticate (N1) — present the N1 code at the /vote page to prove eligibility. N1 is consumed on use and cannot be reused.
  3. Submit an encrypted ballot (N2) — select a candidate, sign the ballot with N2, and submit. The ballot is encrypted before it leaves the browser.
The voter never transmits their identity alongside their vote content. The separation of N1 (identity-linked) and N2 (ballot-linked) is the mechanism that makes this possible.

Administrator

The administrator manages election configuration and phase transitions. Their responsibilities are:
  • Configuring the election (vote_theme, num_voters, choices[]) before registration opens.
  • Verifying voter eligibility by querying the commissioner when a voter requests a signed ballot.
  • Issuing blind-signed ballots — the administrator signs each ballot using a blind signature scheme, meaning they confirm a ballot is legitimate without seeing its content.
  • Starting and ending the vote, which advances the election through its phases.
The administrator can see how many voters have registered and how many have voted, but cannot read any ballot contents.

Commissioner

The commissioner is the eligibility authority. They:
  • Hold the complete list of valid N1 codes for the current election.
  • Validate voter eligibility when queried by the administrator during the voting step.
  • Store hashed N2 codes so that post-election verification can confirm a ballot was included without exposing the original N2 value.
The commissioner knows which voters are eligible but does not see ballot content or final vote choices.

Counter

The counter is the decryption authority. They:
  • Hold the private decryption key corresponding to the public key used to encrypt all ballots.
  • Decrypt and tally all submitted ballots only after the administrator ends the vote.
  • Publish the final results, including the (N2, vote) pairs that allow individual ballot verification.
The counter can decrypt votes but has no information about which voter submitted which ballot.

N1 and N2 codes

The VotingStatus type in the system has three possible values: "register" | "vote_started" | "vote_ended". These correspond directly to the three phases below and control which actions are available on each page.
The two-code system is central to Evoting’s privacy model:
CodePurposeWho stores itWhen it is used
N1Authentication token — proves voter eligibilityCommissioner (hashed list)Consumed once when the voter authenticates at /vote
N2Verification token — links a ballot to its voter for self-verificationCommissioner (hashed), voter (plaintext)Submitted with the ballot; used post-election at /results/verify-vote
By keeping N1 and N2 separate, the system ensures that a voter’s identity (linked to N1) is never combined with their ballot content (linked to N2) in a single record held by any one entity.

Three voting lifecycle phases

1

Registration (status: register)

The election opens for voter sign-up. Voters navigate to /register and submit their email address. The system generates and distributes N1 and N2 codes.The administrator configures the election during this phase — setting vote_theme, num_voters, and choices[]. No votes can be cast while the status is "register".
2

Voting (status: vote_started)

The administrator advances the election to the voting phase. The /vote page becomes active.Voters authenticate with N1, select a candidate, and submit their encrypted ballot signed with N2. Ballots are blind-signed by the administrator before being stored. The administrator can monitor live participation counts but cannot read ballot contents.
3

Results (status: vote_ended)

The administrator closes the election. The counter decrypts all ballots using their private key and tallies the results.Results are published along with all (N2, vote) pairs. Voters can navigate to /results/verify-vote and enter their N2 code to confirm their ballot was included in the final tally.

Blind signatures

How the administrator signs ballots without seeing their content.

Vote flow

End-to-end walkthrough of how a ballot moves through the system from submission to tally.

Security overview

Full cryptographic protocol reference for Evoting.

Voter guide

Step-by-step voter instructions for each phase of the election.

Build docs developers (and LLMs) love