The "Blockchain-based E-Voting System with Off-Chain Verification" addresses the fundamental challenges of security, transparency, and user privacy in electronic voting. This project introduces a hybrid architecture that leverages the immutability of blockchain for vote casting while maintaining a robust, institutional-led off-chain verification system for identity management. By utilizing SHA-256 Aadhaar fingerprinting and a delegated trust model (Faculty-led verification), the system ensures that only eligible voters can participate without storing sensitive personal identifiable information (PII) on the public ledger. The backend is powered by Django REST Framework, providing a secure API and administrative controls, while the frontend is built with React for a dynamic and responsive user experience. The integration of a custom Hybrid Blockchain ensures that balloting remains decentralized and tamper-evident, providing a scalable and secure solution for academic and small-scale institutional elections.
In the digital age, electronic voting (e-voting) has emerged as a promising alternative to traditional paper-based methods, offering potential improvements in efficiency, accessibility, and speed of tallying. However, e-voting systems are often plagued by concerns over security, voter anonymity, and the potential for centralized tampering. Blockchain technology, with its decentralized and immutable nature, provides a compelling framework for addressing these issues.
This project implements a comprehensive e-voting solution designed for academic environments. It bridges the gap between institutional identity verification and decentralized balloting. The system allows educational institutions to maintain control over voter eligibility through a hierarchical verification process involving faculty and department heads, while the actual voting process is secured on a blockchain to ensure that results are transparent and unalterable.
Existing electronic voting systems often suffer from several critical vulnerabilities:
- Centralized Vulnerability: Data stored in centralized databases is susceptible to single-point-of-failure attacks and internal tampering by administrators.
- Sybil Attacks: In decentralized systems, it is difficult to verify real-world identity without compromising user privacy, leading to potential duplicate voting or unauthorized participation.
- Privacy Concerns: Storing sensitive identity data on a public ledger violates privacy regulations (like GDPR) and exposes voters to identity theft.
- Lack of Transparency: Voters often have no way to verify that their vote was recorded accurately without relying on the integrity of the system administrator.
The primary objectives of the Off-Chain Verification & E-Voting System are:
- To ensure vote integrity and immutability: Utilizing blockchain technology to record votes in a way that cannot be altered or deleted.
- To implement a robust identity verification protocol: Developing a multi-level (Faculty/HOD) verification workflow that ensures only eligible students can vote.
- To prioritize voter privacy: Using SHA-256 hashing for identity fingerprinting and implementing an "ephemeral data lifecycle" where sensitive document uploads are deleted immediately after verification.
- To provide a transparent auditing system: Maintaining an immutable audit trail of administrative and verification actions to ensure accountability.
- To create a scalable and user-friendly platform: Designing role-based dashboards that cater to the specific needs of students, faculty, and administrators.
The project is scoped to provide a complete end-to-end e-voting solution for academic institutions (colleges and universities). The system handles:
- User Management: Registration and role-based access control for Students, Teachers, HODs, and Super Admins.
- Institutional Hierarchy: Modeling of Departments, Classes, and Faculty assignments.
- Election Lifecycle: From nomination and candidate approval to vote casting and block mining.
- Identity Assurance: Off-chain verification of institutional IDs and Aadhaar hashes.
- Decentralized Ledger: Recording of anonymized votes on a custom hybrid blockchain.
- Administrative Oversight: Global monitoring, department archival, and system auditing.
The system is designed for local or private network deployment within an institution, with the capability to interface with public blockchain testnets for enhanced decentralized trust.
Electronic voting research has evolved from centralized database models to decentralized blockchain-based solutions. Key areas of background for this project include:
Hybrid systems combine the registration strengths of traditional Web 2.0 architectures with the transactional transparency of Web 3.0. By separating identity management (Off-Chain) from ballot recording (On-Chain), systems can comply with privacy regulations while ensuring that the vote tally is mathematically verifiable.
In e-voting, an "Oracle" is a trusted entity that provides external data (such as voter eligibility) to a smart contract. This project implements a Centralized Oracle Pattern, where the institutional backend (Django) signs "Voting Tokens" for verified students. This ensures that the blockchain does not need to store sensitive identity data to enforce access control.
To prevent Sybil attacks without storing raw government IDs (like Aadhaar), researchers recommend using salted hashes (SHA-256). This project adopts this approach by storing only a 64-character hash of the voter's identity, effectively creating a "digital fingerprint" that is unique but irreversible.
The Blockchain-based E-Voting System is a distributed application that bridges three primary layers:
- User Interface Layer: Developed in React 18, providing role-specific dashboards for Students, Faculty (Teachers/HODs), and Super Admins.
- Logic & Verification Layer: Powered by Django REST Framework (DRF), this layer manages user roles, verification workflows, institutional metadata, and the Oracle signing service.
- Persistence & Consensus Layer: Utilizes a dual-database approach. Institutional data is stored in a relational database (MySQL/SQLite), while the anonymized ballot is stored in a custom Hybrid Blockchain.
The architecture follows a modular, service-oriented design.
- Django Backend: Acts as the central orchestrator. It handles authentication (JWT), manages the state machine for student verification, and interfaces with the blockchain service.
- React Frontend: Communicates with the backend via RESTful APIs. It manages the local state for voting flows and provides real-time feedback on verification status.
- Hybrid Blockchain: A specialized module that manages a private mempool for pending votes and a public ledger for mined blocks. It ensures the immutability of the final tally.
- Trusted Zone (Institutional): Includes the Django server and the primary SQL database. This zone is responsible for the integrity of voter identity.
- Decentralized Zone (Public Ledger): The blockchain component where the results are stored. Once a block is mined, even the institution cannot alter the votes.
The system mirrors a real-world academic structure:
University (Super Admin) > Department (HOD) > Class (Teacher) > Student. Each layer has specific permissions enforced by Role-Based Access Control (RBAC).
The project utilizes a modern, robust technology stack chosen for security and performance:
- Backend Framework: Django 5.1 & Django REST Framework (DRF)
- Frontend Framework: React 18 (Vite) with Tailwind CSS
- Primary Database: MySQL (Production) / SQLite (Development)
- Authentication: SimpleJWT (JSON Web Tokens)
- Blockchain Engine: Custom Python-based Hybrid Blockchain (via
election_blockchainpackage) - Cryptography: SHA-256 (Hashing), Elliptic Curve Cryptography (Signing)
- Environment: Python 3.10+, Node.js 16+
The authentication module implements a stateless JWT-based system.
- Role-Based Access Control (RBAC): Users are assigned roles (Student, Teacher, HOD, Super Admin) which dictate their permissions across the application.
- HOD Invitation Workflow: Super Admins can invite Faculty members to become HODs via a secure, token-hashed email invitation. This ensures that administrative power is delegated securely.
Admins can create and configure elections with specific parameters:
- Scoping: Elections can be global (university-wide) or scoped to specific departments and classes.
- Timeline: Defined start and end dates for both nomination and voting phases.
- Nomination: Students can nominate themselves for active elections.
- Approval: Nominations must be reviewed and approved by the respective HOD or Admin before the candidate appears on the ballot.
The voting process is gated by the verification status.
- Eligibility Check: The system verifies that the student is approved for the specific election and has a linked, verified wallet.
- Oracle Signing: Upon verification, the backend issues a signed cryptographic token that authorizes the frontend to submit a vote to the blockchain.
The system uses a Hybrid Blockchain approach:
- Mempool: Votes are initially collected in a private mempool (stored in MySQL) to manage transaction volume.
- Mining: Admins trigger the mining process, which flushes the mempool into immutable blocks on the public ledger.
This is the core identity assurance module:
- Aadhaar Hashing: Uses SHA-256 with a server-side salt to store a unique hash of the voter's Aadhaar number, preventing duplicate registrations.
- Dual-Approval Access: Faculty members (Class Teachers) must request permission from HODs to view sensitive student documents for verification.
- Toxic Data Lifecycle: Sensitive ID images are deleted from the disk immediately upon approval to minimize data risk.
- Immutable Logs: Critical actions (verification decisions, admin changes) are recorded in an audit table that prevents updates or deletions.
- Accountability: Every action is linked to a specific user and timestamp, providing a clear trail for compliance and dispute resolution.
Provides real-time feedback to users via:
- In-App Status Badges: (Pending, Verified, Rejected, Re-upload Required).
- Email Notifications: For account approvals, HOD invitations, and election milestones.
A centralized hub for:
- Global Statistics: Real-time voter turnout and verification progress.
- Institutional Setup: Management of Departments, Classes, and Faculty assignments.
The system uses a relational schema to manage complex institutional relationships and verification states.
- User (accounts.User): Custom user model extending
AbstractBaseUser. Stores role, department, and verification status. - StudentProfile (verification.StudentProfile): Stores non-sensitive metadata, including the
aadhaar_hashandroll_number. - Election (elections.Election): Defines the metadata and scoping (ManyToManyField to
DepartmentandClass). - Candidate (elections.Candidate): Links a student to an election with an approval status.
- VerificationRequest (verification.VerificationRequest): Manages the state machine for a student's verification for a specific election.
- VoteRecord (elections.VoteRecord): Tracks that a student has voted in an election (preventing double voting) without storing the candidate choice.
- AuditLog (audit.AuditLog): Immutable record of system actions.
- WalletLink (blockchain.WalletLink): Connects a student's institutional identity to an Ethereum wallet address using a nonce-based challenge.
The Department is the primary organizational unit. HODs manage Departments. Teachers manage Classes within Departments. Students belong to Classes. Elections are scoped to Departments or Classes. VerificationRequests bridge Students and Elections.
The system exposes a RESTful API designed for role-based consumption.
POST /api/accounts/login/: Obtain JWT access and refresh tokens.POST /api/accounts/register/student/: Submit student registration with ID uploads.POST /api/accounts/register/faculty/: Submit faculty registration (HOD/Teacher).
GET /api/verification/queue/: (Teacher) List pending student verification requests.POST /api/verification/action/<pk>/: (Teacher) Approve or Reject a specific request.GET /api/verification/status/: (Student) View the status of their verification requests.POST /api/verification/access-request/: (Teacher) Request permission to view sensitive documents.
GET /api/elections/: List active elections available to the user.POST /api/blockchain/connect-wallet/init/: Initiate wallet linking process (get nonce).POST /api/blockchain/connect-wallet/verify/: Finalize linking with a signed nonce.GET /api/blockchain/whitelist-token/: Obtain the signed Oracle token for voting.
The system implements a controlled hybrid blockchain flow to ensure scalability and integrity.
- Vote Submission (Private Mempool): When a student casts a vote, the
blockchain_service.record_votefunction is called. The vote is anonymized and stored in a temporary MySQL-based mempool. - Oracle Validation: Before accepting a vote into the mempool, the server validates the Oracle signature provided by the frontend.
- Block Mining (Public Ledger): At intervals or when triggered by an Admin, the
mine_pending_votesfunction collects all votes from the mempools of authorized nodes and aggregates them into a new block. - Consensus and Chaining: Each new block contains the hash of the previous block, creating an immutable chain. The
verify_chain_integrityfunction can be used to validate the entire ledger at any time.
Security is integrated at every layer of the application.
- SHA-256 Aadhaar Hashing: Ensures one-voter-one-vote without storing PII.
- Elliptic Curve Digital Signature Algorithm (ECDSA): Used for Oracle signatures to prevent unauthorized vote submissions.
- Strict permission checks at the API level ensure that users can only access data relevant to their role and department.
- Faculty hierarchy ensures distributed verification, reducing the risk of a single point of administrative failure.
- Ephemeral Storage: Sensitive images are deleted immediately after their purpose (verification) is served.
- Immutable Audit Logs: Tracks every major state change, ensuring that even administrators can be audited for their actions.
- JWT Rotation: Access tokens have short lifespans (60 mins), and refresh tokens are rotated upon use to mitigate session hijacking risks.
The data flow follows a strictly gated lifecycle from registration to the immutable ledger.
- Voter Onboarding: Student submits PII (Roll No, Aadhaar Hash, ID images) ->
verification.StudentProfile. - Institutional Approval: Faculty reviews IDs -> If approved, Status becomes
VERIFIEDandgov_id_cardis deleted. - Election Scoping:
elections.Electionmodel filters eligible voters based on Class and Department. - Wallet Authorization:
blockchain.WalletLinkchallenges the user to sign a nonce with their Ethereum wallet. - Vote Authorization: The backend acts as an Oracle, providing a signed
whitelist_tokenfor valid, verified students. - Immutable Recording: The vote + token are submitted to the Hybrid Blockchain mempool and eventually mined into a block.
A student’s journey through the voting process involves the following technical steps:
- Login: Authenticate via JWT and enter the Student Dashboard.
- Profile Status: Check verification badge (Must be Green/Verified).
- Wallet Connection: Connect MetaMask, receive a Nonce, sign it, and verify the link on the server.
- Election Selection: Select an active election from the list (Gated by department/class logic).
- Eligibility Verification: The system checks
VerificationRequestandVoteRecord(to prevent double voting). - Ballot Casting: Select candidate -> Request Whitelist Token -> Submit Vote to Blockchain.
- Confirmation: Receive transaction hash and observe the vote appearing in the "Pending Votes" (mempool).
The TeacherActionView is the critical decision point. It enforces that teachers can only approve students in their assigned classes:
if v_request.reviewer and v_request.reviewer != user:
return Response({"error": "This request is locked..."}, status=403)
if not user.is_super_admin:
student_class = v_request.student.user.class_info
if not user.classes_managed.filter(name=student_class).exists():
return Response({"error": "You do not teach this student's class."}, status=403)The service handles the interface with the private blockchain engine:
def record_vote(voter_id: str, candidate: str, election_id: int):
chain = _get_chain()
vote_payload = f"{candidate}|election:{election_id}"
chain.submit_vote(voter_id, vote_payload)The voter_id is typically an opaque hash to maintain ballot anonymity.
Privacy enforcement is hardcoded into the verification flow:
if action == 'VERIFY':
# ... update user status ...
if hasattr(student_user, 'student_profile'):
profile = student_user.student_profile
if profile.gov_id_card:
profile.gov_id_card.delete(save=False)
profile.gov_id_card = None
profile.save()This ensures the system adheres to the "Toxic Data Lifecycle" principle.
- Decentralized Integrity: By using blockchain for the ballot box, the institution cannot alter results after the fact.
- Privacy-First Identity: SHA-256 Aadhaar hashing prevents Sybil attacks while keeping the institution's hands clean of raw PII.
- Institutional Trust Model: Leverages the existing faculty-student relationship for identity assurance, making it more reliable than purely digital-only verification.
- Immutable Accountability: Audit logs ensure that every administrative action is recorded and cannot be erased.
- Role-Specific Efficiency: High-throughput verification queues for faculty and intuitive voting interfaces for students.
- Centralized Oracle: The issuance of whitelist tokens still relies on a centralized Django server. If the server is compromised, malicious tokens could be issued.
- Scalability Constraints: The current hybrid blockchain is optimized for private or testnet deployment; scaling to millions of users on a mainnet would require Layer-2 integration.
- Gas Costs: On a public blockchain, voting would incur gas fees, which might be prohibitive for academic elections.
- Consensus Oracles: Move from a single institutional oracle to a decentralized committee (e.g., signatures required from Admin + Student Union + Faculty Head).
- ZK-SNARKs Integration: Implement Zero-Knowledge Proofs so that the server can verify a student is eligible without knowing WHICH student they are, providing true anonymity.
- Layer-2 Scalability: Deploy on Polygon or Arbitrum to support high transaction volumes with negligible fees.
- Decentralized Identifiers (DID): Allow students to own their verification credentials (VCs) in a self-sovereign identity wallet.
The Blockchain-based E-Voting System with Off-Chain Verification demonstrates a successful hybridization of traditional institutional oversight and modern decentralized technology. It effectively addresses the "E-voting Trilemma" by ensuring high security through blockchain, maintaining sybil resistance through faculty-led verification, and protecting voter privacy through cryptographic hashing and ephemeral data management. This system provides a ready-to-pilot framework for academic institutions seeking a transparent and tamper-proof voting solution.
- Django REST Framework Documentation: https://www.django-rest-framework.org/
- React 18 Documentation: https://react.dev/
- SimpleJWT Documentation: https://django-rest-framework-simplejwt.readthedocs.io/
- Ethereum Developer Resources: https://ethereum.org/en/developers/
- Aadhaar Privacy Guidelines (UIDAI): https://uidai.gov.in/
- Web3.py Documentation: https://web3py.readthedocs.io/
- Hybrid Blockchain Implementation: Election-Hybrid-Blockchain-pkg