Building the Registration and Login Flow for My Blockchain Voting System

When people hear about a blockchain voting app, they usually think about ballot encryption, digital signatures, vote verification, and blockchain integrity.

Those parts matter, but before any of them can be trusted, the system has to solve a simpler problem first:

How do we make sure only valid users can register and log in?

For my university voting system, I designed the registration and login flow to start with institutional identity verification instead of a normal open signup form.

Why I Didn’t Use a Regular Signup Flow
In a standard web app, users usually enter a name, email, and password and create an account immediately.

That approach is too weak for a voting system.

I wanted registration to be tied to an institutional source of truth, so the process starts with a university-issued ID. The user cannot just type arbitrary profile data and create an account.

Instead, the app verifies the ID against the institution members directory and loads the official record from there.

Registration Flow
The registration process in my app has three steps.

1. Verify institution ID
The user enters their student, teacher, or staff ID.

The backend checks that ID against the institutional directory. If the record exists, the system loads the official member information such as:

• full name
• institutional email
• role
• department

This means identity data comes from the directory, not from free-form user input.

2. Verify institutional email with OTP
After the ID is confirmed, the system sends a 6-digit OTP to the institutional email address linked to that member record.

The OTP flow includes a few controls:

• code expires after 10 minutes
• maximum 3 verification attempts
• 60-second cooldown before requesting another code
• verified OTP is consumed after successful registration

This adds a second proof that the person registering is actually connected to the institutional identity.

3. Set password and create account
Once the OTP is verified, the user sets a password and completes registration.

At that point, the backend creates the user account using the verified institutional data. The registration process also prepares the account for the secure voting flow by associating cryptographic key material with the user.

So registration is doing more than account creation. It is also establishing identity and preparing the user for secure participation in the system.

How I Prevent Duplicate Registration
Preventing duplicate registration was a key part of this design.

In a voting system, duplicate registration is not just a usability issue. It is a trust issue.

I handled it in multiple layers:

• the institution directory tracks whether a member is already registered
• the frontend can identify already-registered members early
• before sending OTP, the backend checks whether the institution ID already exists
• during final registration, the backend checks again by institution ID and email
• after successful registration, the member is marked as a registered voter

I prefer this layered approach because critical checks should not rely on only one screen or one database query.

Login Flow
After registration does the heavy trust-building work, login stays simple.

The user logs in with:

• institution ID
• password

The backend then:

1. checks whether the user exists
2. verifies the password
3. issues a JWT token
4. returns the authenticated user profile

That token is used to access protected features like elections and voting operations.

I intentionally kept login straightforward because the identity validation has already happened during registration.

Why This Matters
One of the biggest lessons from building this part of the project is that secure systems depend heavily on their entry points.

Blockchain and cryptography can protect voting operations, but they do not fix a weak registration process.

If the wrong users can register, or if identity is not validated properly, the trust model starts with a flaw.

That is why I spent time designing registration and login as part of the security architecture, not just the user onboarding flow.

Closing
This registration and login design helped me connect:

• institutional identity verification
• OTP-based email validation
• duplicate-registration prevention
• authenticated access with JWT.

For me, this became a reminder that in systems like digital voting, trust starts long before the first vote is cast.

It starts at registration.