Source-reviewed components
Ballot cryptography
Exponential ElGamal over Ristretto255, homomorphic addition and threshold-combination code exist. Source presence is not proof of a fully secured election pipeline.
SparkGlim SEVA · Pre-release
An election needs more than a screen.
Explore SEVA’s source-reviewed design for locally hosted, supervised elections. It remains pre-release and is not yet suitable for any election.
Eligibility and check-in
Separate responsibilities. Validate the complete path.
Ballot marking and encryption
Close, reconcile and review
Security depends on the complete implementation, trusted operations and reviewed evidence. No certification or independent audit is claimed.
Formal elections have a different operating model.
Separate responsibilities. Review the connections.
Explore SEVA’s intended Master and Kiosk model, local election services, data separation and incomplete verification boundary.
Explore SEVALooking for public awards voting?
SparkGlim Awards & Digital Voting has its own campaigns, nominees and checkout journey. SEVA is assessed separately for supervised institutional elections.
SparkGlim Awards & Digital VotingA separate purpose
SEVA addresses controlled election operations. Public awards, paid nominee voting and fundraising use other SparkGlim products.
Different responsibilities
The architecture separates configuration, eligibility checks, ballot marking, authority operations and evidence review. Each boundary needs integration testing.
Understand what exists
Core cryptographic components exist in source. Artifact-proof and tally verification remain incomplete; architecture diagrams are not end-to-end assurance.
Begin with a technical conversation
SparkGlim Security and Technical Teams alone authorize operational access. A consultation does not approve deployment or make SEVA election-ready.
Security
Cryptography, with clear boundaries.
Understand SEVA’s implemented ballot-encryption and trustee primitives, and the verification work still required before election use.
Make the record inspectable.
How sealed configuration, hash-linked records, signatures and replay controls support SEVA’s intended integrity model.
Separate identity from the ballot.
Review SEVA’s intended identity and ballot separation, blind eligibility credentials, retention considerations and privacy limitations.
Security includes the room.
Evaluate SEVA’s device, operator, transport and recovery boundaries before planning a supervised election environment.
Process
An election lifecycle, with explicit decision points.
Prepare the election
Agree governance, locations, eligibility and evidence requirements with the authorized teams.
Assign roles and devices
Separate administration, check-in, kiosk, trustee and monitoring responsibilities.
Review the eligible roll
Resolve eligibility, duplicate records and supervised exceptions before participation.
Configure and seal the ballot
Review contests, candidates, ordering and permitted selections with the election authority.
Authorize opening
Opening is a supervised authority decision after readiness review, not a public launch button.
Mark, review, cast or audit
The intended kiosk journey separates a cast ballot from a ballot opened for audit.
Monitor and manage incidents
Review turnout and operational alerts; keep candidate totals outside the polling view.
Close and reconcile
Stop participation and reconcile paper, device and operational evidence under the authority’s procedure.
Review authorized result artifacts
Trustee and tally components support the intended post-close process. Complete independent verification remains unfinished.
Preserve evidence and review
Agree custody, retention, observer access and recovery responsibilities before any proposed deployment.
Pre-release
An honest view of the application.
The kiosk is part of a supervised election design. Current source and screenshots do not establish a released, election-ready application.
Institutions
Start with the election’s responsibilities.
An assessment scenario, not an approved deployment.
Student elections begin with clear eligibility.
Assess student representation elections through roll preparation, ballot review and supervised participation.
A nonprofit election needs accountable governance.
Prepare a requirements discussion for organization elections without mixing them with fundraising or public popularity votes.
Organizational elections need a defined mandate.
Assess controlled internal elections with clear authority, eligibility and evidence responsibilities.
Institutional elections require more than a ballot screen.
Assess education-sector representation elections through authority, controlled operations and accessible review.
Membership is an eligibility decision, not a login.
Assess association and membership-body elections with clear roll ownership and supervised participation.
Different jurisdictions. A controlled local model.
Assess operational and governance needs across locations without implying remote internet voting or regulatory approval.
Current readiness
Evidence and limits
Source review confirms that a component exists. It does not establish independent security assurance, completed deployment tests or approval to run an election.
Source-reviewed components
Proof and trustee primitives
Chaum–Pedersen proofs, primitive selection-sum checks and distributed-key-generation components have source tests. These tests were not executed during this website audit.
Source-reviewed components
Eligibility and credential boundaries
Blind credential issuance and spent-nullifier storage are implemented in source. Complete voter identity, reissue and concurrent check-in assurance still requires integration testing.
Source-reviewed components
Explicit lifecycle rules
The core state machine restricts transitions and disallows egress in Open and Paused. Actual session, ceremony and network enforcement must be validated together.
Source-reviewed components
Separated records and audit chains
Role-scoped database grants and hash-linked audit/ballot components support the intended separation of duties. Host trust, custody, logs and recovery remain part of the threat model.
Integration testing required
Independent result verification
The artifact verifier does not yet complete integrated ballot-proof and tally checks. Do not treat a verifier result as complete election assurance.
Integration testing required
Operator identity and key custody
Authentication adapters, signing and hardware-key modules exist, but their full operational integration is unfinished. No universal FIDO2, non-exportable HSM custody or biometric guarantee is claimed.
Integration testing required
Deployment and evidence rehearsals
Hardware lockdown, printing and custody, recovery, integrated mock elections and external review require acceptance evidence. Runbooks and module names are not certification.
Planned or under development
Master and Kiosk product packaging
The two-installed-application direction is proposed. Current source packaging still contains several surfaces and executables; released two-app deployment is not established.
Planned or under development
Additional ballot technologies
Shuffle-based processing and ranked/write-in scenarios remain deferred. A feature flag or roadmap entry does not establish a supported cryptographic protocol or ballot type.
Request consultation
Scope before commitment
Assessment only. Not yet suitable for any live election. Deployment and operation require authorized SparkGlim Security and Technical Teams.
Country context guides the consultation. It does not establish jurisdictional approval, regulatory compliance or product availability.