Building the Institution Members Module for My Blockchain Voting App

One of the less flashy but most important parts of my blockchain voting application is the Institution Members module.

When people hear "blockchain voting system", they usually think about encrypted ballots, signatures, audit logs, and blockchain-based integrity. Those parts matter, but before any of that works, the system has to solve a more basic problem:

How do we make sure only valid institution members can register?

That question is why I built this module.

Why I Needed This Feature
A voting application cannot use a normal open signup flow.

If anyone can register with arbitrary identity data, the trust model becomes weak from the start. In this project, I wanted registration to begin from a controlled institutional directory instead of trusting user-entered details.

So I created an Institution Members feature that acts as the eligibility source for account creation.

It stores records like:

• institution ID
• full name
• institutional email
• role
• department
• year level
• voter registration status

This means registration is tied to known institutional data rather than self-declared identity.

How It Works in the Registration Flow
The module is directly connected to the registration process.

The flow looks like this:

1. A user enters their institution ID.
2. The backend looks up that ID in the institution directory.
3. If the record exists, the system loads the official member data.
4. If the member is already registered, the process stops and the user is asked to log in.
5. If the member is eligible, the system sends an OTP to the official institutional email.
6. After OTP verification, the user sets a password and completes registration.
7. The backend creates the voter account using the verified directory data.
8. The member is marked as a registered voter in the directory.

This design avoids trusting identity fields typed manually by the user.

Why OTP Verification Matters
A valid institution ID alone should not be enough to register.

Someone might know another person’s ID, so I added OTP verification to the institutional email address associated with that record. That gives the system a second proof that the registrant is actually linked to the institutional identity.

It is a simple mechanism, but it makes the registration boundary much stronger.

How I Prevent Duplicate Registration
Duplicate registration was one of the key problems I wanted to solve.

In this module, I handle it in multiple layers:

• the institution directory tracks whether a member is already registered using a voter status flag
• the frontend shows registered members as unavailable
• the backend checks whether the institution ID already exists before sending OTP
• the backend checks again during final registration using both institution ID and email
• the institution directory enforces unique institution IDs and emails
• after successful registration, the member is marked as a voter to block future attempts

I prefer this layered approach because registration integrity should not depend on a single UI check or one database lookup.

What I Learned
This module reminded me that secure systems are often shaped by the parts that seem ordinary.

A directory lookup, a status flag, an OTP check, and a uniqueness constraint may not sound as interesting as blockchain logic, but these controls define who is allowed into the system at all.

And in a voting app, that matters a lot.

For me, this was a useful reminder that trust starts before vote casting. It starts at registration.

Closing
The Institution Members module became one of the core trust layers in my blockchain voting project. It helped me connect institutional eligibility, email verification, and duplicate prevention into a registration flow that is much harder to abuse.

I’ll be sharing more modules from the system next, including how registration connects to the actual voting flow.