Real Questions.
Honest Answers.

No — not even the platform administrator can. This isn't a policy promise, it's structural: votes are stored in a way that has no data field connecting a specific vote back to a specific voter, anywhere. There is no query, however privileged, that could reconstruct who voted for whom.

No — same answer, for the same structural reason. There is genuinely nothing to look up, for the company or anyone else.

The platform stops unauthorized people from requesting someone else's token — the WhatsApp self-service flow checks that the phone messaging in matches the phone registered for that matric number. But if a student voluntarily hands over their own token, no software can prevent that — the same way nothing stops you handing someone your ATM PIN. The real protection: tokens are single-use, so if someone else votes with a shared token, the original student permanently loses their own vote — a genuine disincentive against sharing.

No — students are identified only by their unique matric number and token, never by name. Two identically-named students are completely distinct records with no possibility of confusion.

FUTABallot has been through two dedicated rounds of security review, specifically testing the attacks that matter for an election: guessing tokens (852 billion possible combinations, with automatic lockouts after a few failed attempts), stealing a login session, tampering with vote counts, and voting more than once. All of these are actively blocked and logged. On top of that, the live Integrity Dashboard means any tampering with vote counts would visibly stop adding up — in public, immediately, not discovered weeks later. Like any system connected to the internet, no one can promise absolute invulnerability with a straight face — what matters is that realistic attacks are blocked and tampering would be caught, and that's exactly what this platform is built and tested to do.

No. Every vote requires a valid, unguessable token tied to a specific, pre-registered student. A script would need to correctly guess a real student's exact token — attempts beyond a few trigger an automatic lockout. There's no way to submit votes without already knowing real, valid tokens.

Yes — the database has no public access at all. Every table is locked down so nothing can be read or written except through the app's own verified logic. There's no side door that skips the actual voting rules.

This is a real risk with WhatsApp generally, the same way scammers impersonate banks. Your committee will officially announce the one real number through a channel you already trust. Once business verification is complete, the real number shows a green verified badge — check for it, and never share your token with a number you can't confirm is official.

No — this is one of the strongest protections in the system, aimed specifically at insider misuse. Regenerating a token only changes the code used to log in — it does not reset whether you've already voted. Even with a brand new token, an already-voted student is rejected the instant they try to log in again, before the token is even checked. There is no button anywhere that "undoes" a vote to free someone up to vote again.

Technically, someone with direct, raw access to the underlying database — a level of access far beyond the everyday admin panel — could manually alter a record. This is true of almost any real software system; whoever holds root-level infrastructure access always has some theoretical override, the same way a bank's core engineers technically could alter a balance. This isn't reachable through the admin panel the committee actually uses, it would require deliberately bypassing the whole application, and it would leave a clear trail — which is exactly why the audit log and the live Integrity Dashboard both exist: to make tampering detectable, not to pretend it's impossible for literally anyone on Earth.

This is exactly what the timestamped snapshot system exists to catch. Throughout election day, the system automatically records a timestamped copy of every candidate's vote count. If final results were ever altered afterward, they would contradict an earlier snapshot — a concrete, timestamped trail, not just one person's word against another's.

No — each submission either fully succeeds (recorded, confirmed to you, reflected in the live count) or fully fails with a clear error and nothing recorded. There's no in-between state where a vote could be silently lost.

The on-screen confirmation you see only appears once your vote is genuinely recorded — it's not shown speculatively before submission succeeds. From that moment, it's immediately reflected in the live count on the Integrity Dashboard, and the timestamped snapshot system preserves proof of the count going forward. There's no separate "processing" step afterward where a confirmed vote could quietly fail to count.

Nothing is saved until you tap the final "Submit My Vote" button. If you're interrupted before that, your token is still unused — just log back in with the same matric number and token and start again.

No — once submitted, a vote is final and cannot be edited by anyone, including the committee. This is exactly why there's a "Review Your Choices" step before final submission — take it seriously, it's your last chance to fix anything.

If the submission doesn't fully complete, nothing is recorded — it's all-or-nothing by design. Your token stays valid and unused; just try again once you're back online.

Contact your electoral committee immediately. They can regenerate your token — invalidating the one on the lost phone — and send a new one to a number you actually control.

Matric numbers are automatically standardized (capitalized, trimmed of stray spaces) before checking, so small formatting differences don't matter or create loopholes — either it matches a real registered student exactly, or it's rejected.