Encrypted ballots. Independently checkable evidence. A BSV Script state machine. INTEGYRS is developing the boundaries that connect these components without publishing an individual voter’s selection.
The proposed system separates election configuration and eligibility from encrypted ballot handling, public evidence and tally verification. These are distinct responsibilities, not interchangeable guarantees.
The design moves beyond telephone-based registration and verification. Candidate approaches include internet identity checks, cryptographic credentials and remote video-assisted eligibility checks.
Assess credential issuance, authentication and, where appropriate, a remote identity proctor. Identity checks must have explicit consent, accessible alternatives, minimal retention and a documented fraud and recovery policy. No provider integration or biometric assurance is claimed.
A proctor may help check identity or eligibility, not watch the voter select or cast a ballot. Identity records, video sessions and device metadata must not be joined to the private ballot. Credential unlinkability and this separation remain design and validation requirements.
The pilot uses ElGamal encryption and Chaum–Pedersen-style zero-knowledge proofs for a synthetic single-choice election. Offline proof verification can check that a ballot encodes an allowed choice without decrypting that individual ballot.
This establishes a particular mathematical statement. It does not establish anonymous eligibility, a trustworthy voter device, or that the ciphertext matches the voter’s intent.
The application services separate ballot intake, proof verification, a durable SQLite evidence board, public tally auditing and a chain boundary. Receipts support checking inclusion in the accepted evidence set.
Homomorphic aggregation and tally proofs target independently reproducible counting without releasing individual plaintext ballots. Trustee key custody, deployment independence and production hardening remain separate work.
The chain design uses spendable BSV outputs and locking/unlocking scripts to constrain permitted election-state transitions. The intended mechanism is executable spending conditions, rather than an OP_RETURN record presented as enforcement.
Offline zero-knowledge verification and Script enforcement have different jobs. The design must specify exactly which predicates run in Script and which rely on an external verifier. Candidate scripts and local fixtures do not establish acceptance by a BSV node or live-chain finality.
The desired verification experience lets voters check their participation without giving a third party transferable proof of their selection. That is an additional security requirement, not an automatic property of encryption.
This is a research and engineering pilot, not an election service. No binding election, deployment certification or end-to-end election security is claimed.
Local encryption, proof verification, evidence handling and independent tally checks for synthetic single-choice fixtures. Service separation is an implementation boundary, not proof of independent operation.
Proper Script-based state transitions require node execution tests, negative witness tests, transaction-policy checks and explicit chain observation rules before a chain-enforcement claim.
A voter who retains encryption randomness can demonstrate a choice to another person in the current construction. Receipt-freeness and coercion resistance are not achieved.
Pseudonymous test credentials are not anonymous eligibility. Metadata linkage, compromised devices, duplicate credentials, trustee collusion and retained secrets all require a complete threat model.
Specify the Script/offline-verifier boundary; execute the spending path against a BSV node; test recovery and concurrent submissions; define anonymous eligibility and non-transferable verification; commission independent cryptographic and operational review.
