CS488 Senior Capstone · Earlham College · 2025–26

A Secure Ethereum
Voting Platform for
Campus Elections.

A complete capstone system: authenticated campus eligibility off-chain, commit-reveal ballots on a permissioned Ethereum chain, admin finalization, and a public audit trail anyone can verify.

Read the brief Watch demo

Nour Al-Sheikh· Earlham College· CS488

⟵ drag to rotate ⟶

Project Brief

Trust alone is not enough.

Campus elections need results students can inspect without exposing who voted. This system keeps eligibility off-chain, records sealed ballots on a permissioned Ethereum chain, and publishes final events through a public audit view.

01 The Problem

Manual recounts and audit gaps erode trust.

Voters should not have to accept a result without a clear record of how it was produced.

02 The Approach

Permissioned Ethereum, commit-reveal ballots.

The codebase supports configurable 1 to 4 node Clique/geth deployment around the ElectionManager contract. Wallets register through signed eligibility proofs, and no PII is stored on-chain.

03 Evaluation

IRB-exempt mock-election usability study.

IRB exemption approved for the usability/mock-election study. The study focuses on task completion, usability, and perceived trust across the voter, admin, and audit workflow.

04 Deliverables

Complete system, demonstrated locally.

The complete one-node laptop deployment covers authentication, wallet registration, commit, reveal, admin finalization, and public audit. A configurable 1 to 4 node deployment path is documented.

Voter Lifecycle

One auditable flow,
four trust zones.

The workflow moves through four stages: identity, sealed ballot, reveal and tally, then public audit. Each stage has a clear boundary.

01 · Identity

Campus email link.

Auth service issues a signed eligibility proof tied to the student's Earlham email. No campus identity ever lands on-chain.

Identity stays off-chain

02 · Sealed Vote

Commit phase.

The wallet signs a salted vote hash. The ballot is locked on-chain but unreadable, even to validators, until the reveal phase opens.

Receipt issued

03 · Reveal & Tally

Reveal phase.

After voting closes, voters reveal the salt. The contract verifies each reveal against the stored hash. Clique validators seal blocks.

Tally is contract-enforced

04 · Public Record

Audit phase.

Admin finalizes the election. The audit view exposes contract events, tallies, and receipt checks without revealing campus identity.

Verify anytime

Graphical abstract: campus email link, sealed vote, reveal and tally, public record — **Fig. 01** / Graphical abstract Click to expand

System Architecture

Four trust zones,
one auditable flow.

Identity, voter interface, smart contract state, and public audit stay separate. Validators seal blocks; the contract enforces registration, commit, reveal, finalization, and tally reads.

System architecture: identity, voter interface, smart contract chain, validators, public audit — **Fig. 02** / System architecture, four trust zones Click to expand

Zone 01

Identity & Eligibility

Off-chain only. The auth service binds Earlham email to wallet through a signed eligibility proof. No campus identity crosses the chain boundary.

Zone 02

Voter Interface

React DApp + MetaMask. Signs registration, commit, and reveal transactions. Browser-side only.

Zone 03

Chain & Validators

Configurable 1 to 4 node Clique/geth deployment. ElectionManager handles register, commit, reveal, and finalize. Validators only seal.

Zone 04

Public Audit

A read-only audit API indexes contract events. Dashboards verify on-chain state without touching the vote pathway.

Implementation

Software stack.

The implementation combines Solidity, Hardhat, React, MetaMask, Node/JWT services, a read-only audit API, and configurable geth/Clique deployment support.

contractSolidity 0.8 buildHardhat typesTypeChain consensusGeth · Clique PoA primitivesOpenZeppelin cryptoEIP-712 frontendReact DApp walletMetaMask authNode.js · JWT monitorPrometheus + Grafana auditRead-only event API validationTests + builds

Threat Posture

What the system
protects against.

Mitigations are split between the protocol, the contract, and the deployment: commit-reveal ballots, one-commit-per-address rules, role-gated finalization, Clique consensus, and monitoring.

Threat	Mitigation	Severity	Status
Double-voting	One-commit-per-address constraint enforced in `ElectionManager`; on-chain reverts on retry.	High	● Implemented
Identity spoofing	Signed eligibility proof tied to campus email; expiry; domain restriction; one-time use.	High	● Implemented
Vote coercion / selling	Commit-reveal: the ballot is unreadable on-chain until the voter reveals; no proof-of-vote is exposed during voting.	Medium	● Protocol-level
Premature result disclosure	Reveals only accepted after voting window closes; enforced by contract state machine.	Medium	● Implemented
Reentrancy / overflow	OpenZeppelin patterns; Solidity 0.8 checked arithmetic; focused tests cover role, timing, registration, commit, reveal, and finalization paths.	High	● Tested locally
Rogue validator	Validators in Clique PoA only seal blocks. They do not tally. Tallying is a contract function gated by reveal-phase state.	Medium	● Consensus
Client-side key compromise	MetaMask custody; the DApp never sees raw key material; transaction-level signing only.	Medium	● Architecture
Full STRIDE / formal review	Future review scope.	Planned	◌ Future work