End-to-End Verifiable Voting, Explained Plainly
End-to-end verifiable voting is a specific property: cast as intended, recorded as cast, counted as recorded. Here is what each part means and why it matters.
End-to-end verifiable voting is not a slogan. It is a precise technical property made of three guarantees: your ballot is cast as intended, recorded as cast, and counted as recorded. A system that delivers all three lets every voter and every observer confirm the outcome without trusting the operator. A system that delivers fewer is not end-to-end verifiable, no matter what the marketing says. The phrase gets thrown around loosely, so it is worth pinning down exactly what it demands.
Once you see the three parts, you can test any voting system in about five minutes. Ask which of the three it proves. Most prove none and hope you do not ask.
What does cast as intended mean
Cast as intended means the ballot the system recorded matches the choice you actually made. The failure it guards against is a machine that shows you one thing on screen and stores another.
The mechanism is a challenge. After you mark your ballot but before you finalize it, the system commits to an encrypted version. You can then choose to challenge that commitment, which reveals what the machine was about to record so you can confirm it matches your intent. If it does not, you caught the machine cheating. If it does, you finalize and the commitment stands.
The elegance is that the machine cannot know in advance whether you will challenge, so it cannot safely cheat. To reliably alter votes it would have to alter many, and each one it alters is a coin flip that a challenge exposes it. Cheating at scale becomes cheating that gets caught.
What does recorded as cast mean
Recorded as cast means the ballot stored in the system is the exact one you finalized, unchanged in transit and unchanged in storage. This is the receipt property.
When you finalize, you get a cryptographic token tied to your specific ballot. Later, every recorded ballot is published to a public bulletin board. You find your token there. Its presence proves your ballot was recorded, and the cryptography proves it was not altered after you cast it. Crucially, the token confirms your ballot is included without revealing how you voted, so secrecy holds.
If a voter's token is missing from the board, that is proof of a dropped ballot. If a token is present but the underlying commitment does not match, that is proof of tampering. The record is inspectable by the people affected, which is the only kind of record that survives a dispute. I make the same point about why an internal log is not a real audit trail: if only the operator can check it, it is not proof.
What does counted as recorded mean
Counted as recorded means the published total is a correct count of every ballot on the bulletin board, with nothing added, dropped, or edited. This is where the votes actually become a result.
The count is done on the encrypted ballots using a verifiable tally, so the math can be checked by anyone without decrypting individual votes. The system produces a proof alongside the total. Independent observers run the verification and confirm the total follows from the board. Ten people check, ten people agree, and the number stops being a claim.
This is the step operators most want you to skip, because it removes them from the trust equation entirely. When the raw board is public and the counting proof verifies, a losing candidate's own team can confirm they lost. That is the whole point. Platforms built around this property, like MintVote, treat the public board and the verifiable count as the core, not a compliance layer bolted on at the end.
Why all three have to hold together
Any two without the third leaves a hole big enough to steal an election through.
Cast as intended plus recorded as cast, but no verifiable count, means the operator can still miscount a perfectly recorded set of ballots. Recorded as cast plus counted as recorded, but no cast-as-intended check, means the machine could have altered your vote before it ever hit the record, and the flawless chain afterward just faithfully preserves the fraud. The guarantees only mean something as a set.
That is why verifiability has to be designed into the system from the first line, the way real transparency is engineered, not announced. You cannot add end-to-end verifiability to a black box after the fact. You build the box so that every stage proves itself, and the result is a vote whose integrity does not depend on anyone taking the operator's word.