Online Campus Voting and Poll System

Student elections and opinion polls on most campuses still run on paper ballots or ad-hoc form tools. Paper voting needs booths, volunteers and manual counting; generic form tools cannot enforce one-student-one-vote, keep ballots secret while publishing turnout, or block duplicate votes. Turnout suffers because voting means queueing between lectures, and organizers face recount disputes with no audit trail. This project builds a purpose-made online voting platform: a verified voter roll, anonymous ballot casting with single-use vote tokens, and a live results dashboard that shows turnout and vote shares without revealing individual votes. The ballot store is deliberately separated from voter identity, so the system can prove that you voted without knowing whom you voted for.

1. The election officer creates an election with candidates, schedule and eligibility rules, then imports the voter roll (name, college email, PRN) via CSV.
2. The system issues a single-use vote token per voter per election and delivers it with a secure voting link.
3. The voter authenticates, views the ballot, selects a candidate (or NOTA) and submits; the token is consumed atomically with the vote.
4. The vote is stored with no link back to the voter; only the voter's "has voted" flag is updated.
5. The results engine aggregates anonymized votes into vote shares and turnout statistics served on the public dashboard.
6. After polls close, results are finalized and the audit page reconciles ballots issued against ballots cast for the organizers' record.

Tech stack:

• Python (Django/Flask) or Node.js backend
• PostgreSQL/MySQL relational database
• HTML5, CSS3, JavaScript (responsive frontend)
• REST APIs for voter auth, ballot casting and results
• CSV voter-roll import
• Email service for token delivery and reminders
• HTTPS deployment
• Charting library for result dashboards

• [One-student-one-vote tokens] Each eligible voter gets a single-use token per election; the token is consumed on submission and reused or forged tokens are rejected before any vote is recorded.
• [Anonymous ballot storage] Cast/not-cast status is stored separately from vote content, so turnout is public and auditable while individual votes stay secret.
• [Live results dashboard] Vote shares, turnout percentages and year-wise turnout breakdowns update as votes arrive, with provisional status until polls close.
• [Multiple concurrent elections] Run council elections, department rep polls and mess-menu opinion polls side by side, each with its own voter roll, candidates and schedule.
• [Audit log] Ballots issued, ballots cast, invalid attempts and blocked duplicates are reconciled on an organizer-only audit page.
• [Scheduled polls and reminders] Elections open and close automatically on schedule; voters get reminders before the deadline.
• [Role-based admin panel] Separate access for voters, election officers (create elections, manage rolls) and read-only result viewers.

• Complete voting web application source code (voter + admin interfaces)
• Database schema and migration scripts
• Voter-roll CSV import templates and token system
• Results dashboard with turnout analytics
• Setup and deployment guide (VPS/shared hosting)
• Load-test script for the buyer to verify capacity claims
• Project report PDF (background, architecture, ballot-secrecy design, methodology)
• PPT presentation for final review
• Viva Q&A preparation document (authentication, anonymity design, concurrency, audit)

• Voter identity relies on the accuracy of the imported roll — the system cannot fix a bad roll.
• Ballot secrecy assumes the deployment uses HTTPS and the server itself is trusted by the institution.
• One vote per election is enforced by token, not by biometric identity — token sharing is a policy matter.
• Capacity figures are design targets; the buyer runs the included load-test script to verify on their hosting.
• The system counts votes; it does not verify candidate eligibility — that stays with the election officer.
• No end-to-end cryptographic verifiability (individual receipts) in the base build — listed as future scope.