zkBallot: Private decisions.
Public evidence.

An institution should be able to establish that a decision came from its eligible members without turning every member's choice into public data. DNA Protocol's zkBallot explores that separation: private eligibility, encrypted choices, a verifiable aggregate, and a portable record of how the result was produced.

This is not simply voting placed on a blockchain. The reviewed implementation composes anonymous membership proofs, verifiable ElGamal encryption, a distributed trustee ceremony, transactional ballot accounting, and independently inspectable election evidence. XRPL Testnet is an optional commitment layer at the end of that process, not the machine that verifies or counts the votes.

The central claim is deliberately specific: zkBallot can provide cryptographic evidence about an approved credential, an encrypted ballot, and a published tally. Whether the institution enrolled the right people, whether their devices were trustworthy, and whether the decision has legal or organisational force remain separate questions.

1. Five properties, not one security label

A useful private voting system must distinguish eligibility, uniqueness, ballot secrecy, integrity, and availability. These are different properties with different failure modes. A valid zero-knowledge proof does not by itself make an election fair, secret, available, or correctly administered.

End-to-end verifiability is also best decomposed. Cast-as-intended concerns whether the encryption represents the voter's choice. Recorded-as-cast concerns whether the accepted ciphertext appears in the retained record. Tallied-as-recorded concerns whether the published totals follow from that record. zkBallot addresses these through different checks; it should not collapse them into a single green status.

2. A system of separated responsibilities

The institution approves eligibility. The voter holds a private Semaphore identity and prepares a ballot in the browser. Trustees establish an election key without a central dealer retaining the complete secret. A coordinator stores public election material and enforces the state machine. Verifiers recompute the evidence. An optional organiser-triggered Testnet operation commits a digest to XRPL.

DNA Protocol's identity tools offer a related principle: prove a bounded claim rather than disclose an entire identity. But the identity pipeline and zkBallot are distinct implementations. The reviewed voting application does not automatically import Vault credentials, reuse the identity demonstration's circuit, establish genomic identity, or turn an XDNA balance into eligibility. Connecting them would require a specified credential-to-membership bridge and its own security review.

This separation is an architectural advantage when kept explicit. An institution can change its enrolment policy without pretending that a cryptographic primitive understands employment status, cooperative membership, or legal voting rights. Conversely, a verifier can check the mathematics without being asked to trust a screenshot of an administrator's dashboard.

3. Freeze the decision before accepting votes

The election manifest is the root of meaning. It commits to the election identifier, title, options, approved member commitments, Merkle root, proof depth, trustee public key and ceremony, institution authority, closing policy, deadline, protocol version, and preparation policy. Its canonical SHA-256 digest becomes the election hash.

These are not merely labels. If the roster, options, quorum, or deadline changes, the digest changes. Domain-separated proof scopes, ballot hashes, and tally contexts bind later evidence to those exact rules. Verifiers reconstruct the manifest and reject a root or protocol policy that does not match it. The source accepts two to five options and one selected option per ballot; ranked-choice, delegated and token-weighted voting are not implemented by changing the interface text.

Eligibility approval uses an Ed25519 signature over a domain-separated message containing the enrolment hash, roster slot, and identity commitment. The signature authorises that commitment for the frozen roster. It does not prove the truth of the institution's underlying membership decision. The institution must authenticate applicants, prevent multiple credentials for the same entitlement, handle disputes, and agree a correction process before locking the electorate.

The result is privacy relative to a disclosed commitment set, not invisibility. The authority can know who received each credential. The anonymous proof is intended to avoid publishing which approved commitment produced a ballot, subject to the proof system and surrounding metadata assumptions. A tiny electorate or an identifying participation pattern can weaken practical anonymity even when the proof is valid.

4. What the zero-knowledge circuit actually proves

zkBallot uses Semaphore v4, with application dependencies pinned to version 4.14.3. The membership relation establishes possession of the secret behind a commitment in the approved Merkle tree. A scope-specific nullifier allows the application to reject a second accepted vote using the same credential without asking the voter to publish that credential. The message is bound into the proof. These are the three responsibilities described in Semaphore's circuit documentation.

Private witness: identity secret s, membership path
Public statement: roster root R, scope S, message M, nullifier N

Member(Commit(s), path, R) = true
N = SemaphoreNullifier(s, S)
Proof binds the declared message M

For a cast ballot, the application derives its scope from a fixed voting domain and the immutable election hash. It derives the message from a different domain and the complete encrypted ballot object. The SDK then maps the supplied 256-bit values into circuit inputs using its own Keccak-based field mapping. The application-level SHA-256 digest and the circuit field encoding are therefore two different steps, not interchangeable hash functions.

The reviewed verifier checks the exact envelope shape, configured tree depth, expected root, scope and message, canonical numeric representations, nullifier bounds, and packed proof-point bounds before calling the real Groth16 verifier. The public inputs used by that verifier are the root, nullifier, mapped message, and mapped scope. A proof from another election, another ciphertext, or another roster cannot be accepted merely because it verifies against some other statement.

Crucially, the Semaphore circuit is not the ballot-encryption circuit. It does not prove that an ElGamal ciphertext contains a legal choice or that the trustees decrypted the aggregate correctly. Those statements are established separately and composed by the application verifier. This division reduces the temptation to attribute every security property to the term zero knowledge.

The membership layer uses Groth16 over BN254, while ballot encryption and decryption proofs operate in Ristretto255. These are distinct algebraic domains. The application composes their statements through explicit, domain-separated hashes of canonical election and ballot data; it does not treat points or scalars from the two groups as interchangeable.

Groth16 also brings setup and artifact assumptions. The release includes depth-specific proving artifacts and checks that their exported verification keys agree with the pinned package keys. That is useful consistency evidence, not independent validation of the ceremony, circuit, or complete application composition. The underlying proof construction is described by Groth's 2016 paper; the deployed application needs assurance beyond citing that paper.

5. Prove a legal choice without revealing it

The ballot is a one-hot vector: exactly one option has value one and every other option has value zero. For option j, let G be the Ristretto255 generator, Y the election public key, r_j fresh randomness, and b_j the choice bit. The ciphertext is a pair of group points:

A_j = r_j G
B_j = r_j Y + b_j G

b_j in {0, 1}       and       sum_j b_j = 1

The implementation uses the prime-order Ristretto255 group through noble-curves. RFC 9496 specifies the group abstraction and canonical encoding; it does not certify DNA Protocol's application.

Each option carries a disjunctive Chaum-Pedersen-style proof: either its ciphertext encrypts zero or it encrypts one. The verifier checks the OR relation without learning which branch is real. A separate equality-of-discrete-log proof over the summed ciphertext establishes that the vector contains exactly one selection. Proving only the individual bits would be insufficient because a voter could otherwise select several options or none.

The Fiat-Shamir challenges are derived from domain-separated transcripts that include the election-bound ciphertext context. Canonical point and scalar parsing, rejection of invalid encodings, and explicit option-count checks matter as much as the mathematical equation. A valid proof over ambiguous or differently interpreted bytes would not be a valid application protocol.

The encryption proof, membership proof, and election hash meet at the same exact ballot object. This binding is what prevents a valid eligibility proof from being detached and attached to a substituted ciphertext. Fresh randomness is generated for each preparation; an opened challenge is never treated as a secret vote.

6. Distribute custody; verify the aggregate

The institutional flow supports three to seven trustees and a quorum of at least two. Each trustee contributes to a distributed key-generation ceremony using the pinned noble-curves FROST DKG primitives. The application uses the resulting shares for threshold ElGamal decryption, not a FROST signature as the voting result. It is an application-specific composition, not a claim of ElectionGuard compatibility or certification.

Trustee registration binds signing and transport keys to the ceremony. Ed25519 signatures authenticate ceremony messages; X25519 establishes pairwise shared secrets; HKDF-SHA-256 derives transport keys; AES-GCM encrypts private share packets with transcript-bound authenticated metadata. Every trustee confirms the same public ceremony core before voting opens. Operators must still authenticate the people behind the keys and compare the transcript through an independent channel.

Conceptually, each trustee contributes a polynomial, the public commitments define a joint public key, and trustee i retains a share x_i of the combined secret. The coordinator receives the public commitments, signatures and encrypted peer packets, not an intentionally reconstructed complete decryption key.

For each option, ciphertexts add homomorphically. A trustee publishes a partial decryption of the aggregate, accompanied by a proof that it used the same secret share represented by its public verification share. The tally combines a quorum of distinct, valid partial decryptions using Lagrange coefficients.

A*_j = sum_v A_v,j          B*_j = sum_v B_v,j
D_i,j = x_i A*_j

Prove: log_G(Y_i) = log_A*_j(D_i,j)
D_j = sum_i lambda_i D_i,j
B*_j - D_j = tally_j G

0 <= tally_j <= accepted ballot count
sum_j tally_j = accepted ballot count

The implementation recomputes the aggregate, verifies every supplied share, rejects repeated trustee indexes, and recovers each small integer count within the accepted-ballot bound. The tally context also commits to the election, receipt root, ballot count, closure time and preparation history. A decryption share for a different ballot set is not reusable evidence for this one.

There is an essential limitation: threshold custody is not a cryptographic prohibition on individual decryption. Any colluding quorum with access to the public ciphertexts can cooperate to decrypt a particular ballot. The operating model depends on fewer than the quorum colluding, careful trustee selection, and controls over share custody. Unanimous or very small tallies can also reveal choices through inference without any key compromise.

7. Prepare, then cast or challenge

A valid encryption only proves that the ciphertext encodes a legal choice, not necessarily the choice the human intended. zkBallot therefore separates preparation from the decision to cast. The voter first commits an encrypted ballot, then chooses either to cast that exact preparation or to challenge it by revealing its choice and randomness.

A challenged preparation tests whether that committed encryption matches its revealed opening. It is evidence about the challenged ballot, not a guarantee that every unchallenged ballot was honestly produced. Useful cast-as-intended assurance requires unpredictable challenge decisions and a trustworthy verification path; a compromised browser that controls both the vote and its presentation is still a serious threat. ElectionGuard's process documentation is a useful reference for the distinction between casting and spoiling, without implying that zkBallot implements the same protocol.

Version 4 adds an important resource-control layer. Public-key encryption is public: an outsider can produce valid encrypted ballots. Requiring encryption validity alone would therefore let outsiders consume finite preparation storage. zkBallot instead requires a separate anonymous membership proof before accepting a preparation.

Every approved credential has sixteen preparation slots, numbered zero to fifteen. The admission scope includes a dedicated domain, election hash and slot. Its message includes a separate domain, election hash and exact preparation hash. The coordinator verifies the proof and atomically enforces uniqueness of the election, slot and nullifier tuple. An exact replay reconciles to the existing preparation; another ciphertext claiming an occupied slot fails.

Neither casting nor challenging refunds a slot. Admission and voting use different scopes, so a preparation proof is not a substitute for a cast proof. Recovery checks a public, paginated index rather than sending an identity-derived lookup. Used-slot candidate proofs remain on the device. This limits permanent preparation consumption per approved credential; it does not eliminate temporary network floods, proof-verification exhaustion, or an institution issuing fraudulent credentials.

8. Make the record independently inspectable

The coordinator is not trusted merely because it runs a verifier. The application must also bind valid proofs to a single, durable sequence of state transitions. The reviewed persistent store combines proof verification with transactionally enforced uniqueness, ballot status, append-only event commitments, and idempotent handling of repeated requests.

A network timeout is not evidence that a vote failed. The client should reconcile the same ciphertext and receipt rather than create a new identity or silently submit a different operation. Exact retries are intended to return the same record. A cast-versus-challenge race must have exactly one terminal outcome, and a duplicate voting nullifier must never increment the tally twice.

Accepted records are committed through a domain-separated Merkle receipt tree. The tree binds its leaf count as well as its root. Inclusion proofs let a voter check a retained record against that committed set. The broader election export contains frozen rules, public ceremony material, approvals, preparations, challenge openings, cast records, trustee proofs and the ordered event history. Private identity secrets, organiser capabilities and plaintext trustee shares are not part of that public export.

Events carry a sequence number, predecessor hash, timestamp, kind and payload commitment. A separately retained checkpoint can detect a later fork or truncation relative to a history that the participant already witnessed. But an event hash chain is not a coordinator signature, and a first-time reader cannot rule out a completely rewritten, internally consistent history simply by receiving a checkpoint from that same coordinator. Independent copies and external witnesses matter.

The offline verifier and browser verification path provide separate ways to inspect evidence, but they reuse application verification logic. They are not two independently implemented cryptographic verifiers. A shared bug can survive both. Operational independence, implementation diversity, and independent review are different assurance properties.

Recovery files use authenticated encryption with a password-derived key. The reviewed configuration uses scrypt with N = 32,768, r = 8 and p = 3, then AES-256-GCM. A random salt, nonce, participant role, election identifier and binding are incorporated into the envelope. Wrong passwords, altered ciphertext and foreign-election bindings are rejected. This protects the stored recovery artifact; it does not protect a weak passphrase from offline guessing or a live secret from malware on the device.

9. XRPL anchors evidence; it does not certify the election

After closure and tally verification, zkBallot can construct an audit commitment containing the election hash, ballot root, accepted count, audit hash and tally hash. The Testnet path places that commitment in an AccountSet memo. It does not put plaintext choices or voter identity secrets on the ledger.

The current organiser flow can generate a temporary Testnet signer in the organiser's browser, request faucet funding, validate the network and prepared transaction, sign in memory, and submit. The coordinator is not the intended holder of that signing secret. A lower-level helper also exposes an unsigned transaction envelope; reading that helper alone would miss the browser signing flow.

The receipt checker requires the expected network ID, account, transaction type, hash, exact memo, validated status and tesSUCCESS. A returned hash alone is insufficient. Once a signed hash has been retained, uncertain outcomes are reconciled by looking up that attempt rather than automatically issuing a replacement transaction.

XRPL validators establish ledger execution and inclusion. They do not execute Semaphore, inspect institutional approvals, or check threshold ballot decryption. The anchor makes a particular evidence commitment publicly observable; it does not establish that the electorate was legitimate or that the off-ledger audit was correct. Because XRPL Testnet can be reset, the institution must preserve evidence independently of that network.

Network transaction costs are paid in XRP, as specified by the XRPL transaction-cost documentation. XDNA is not the native fee asset, a consensus security requirement, or an implemented prerequisite for casting a zkBallot vote. A future commercial service cannot use faucet-funded Testnet activity as its unit-economics model.

10. What has been demonstrated, and at what scale?

The reviewed release includes a documented synthetic, loopback-HTTP rehearsal with 256 approved credentials, three trustees and a two-trustee quorum. Its published evidence records 258 admission proofs, 256 accepted voting proofs, one excluded challenge, a 128/128 result, all three quorum combinations, a midpoint restart, and reconciliation of all 256 receipts after local restore.

The complete recorded run took about 988 seconds, including setup, proving, throttling, retries, verification, backup and restoration. That number is not a hosted throughput result, a per-vote latency promise, or evidence from 256 independent physical devices. This article reviews the retained rehearsal rather than claiming to have rerun that full 256-voter lifecycle.

The current application rejects new preparations for legacy elections whose immutable rules lack the version-4 admission policy, while retaining historical verification paths. That is a compatibility boundary, not an invisible upgrade. Operators must plan continuity before changing a service used by an active election.

Before any institution relies on an outcome, the acceptance package should include independent review of the composition, authenticated trustee ceremonies, a documented eligibility process, realistic devices and accessibility checks, deployed load and recovery exercises, retention and incident procedures, and an explicit go/no-go decision. Public political elections pose additional coercion, device and adversarial risks. The National Academies' 2018 election-security report cautioned against internet return of marked ballots; zkBallot should not be presented as resolving those concerns merely by adding proofs.

11. The practical opportunity: verifiable organisational decisions

The strongest near-term evaluation setting is a bounded group with a known membership authority, an explicit trustee quorum and a clear need for confidential choices. Cooperatives, professional associations, research consortia and governance committees can assess whether an auditable encrypted ballot improves their existing process. Suitability still depends on the institution's rules, technical capacity and consequences of failure; these are proposed use cases, not claims of existing customers.

For a cooperative, the interesting separation is membership versus choice. For a committee, it is collective oversight versus a single administrator seeing every ballot. For a consortium, it is an exportable decision record that participants can retain independently of the service provider. For a DAO with an approved member roster, it is confidential one-credential-one-vote participation, not automatically token-weighted governance.

Corporate proxy voting is an adjacent, longer-term integration domain, not a drop-in current capability. Share-weighted entitlements, intermediaries, record dates, vote changes, delegated authority and regulated meeting processes introduce requirements absent from the current single-choice, one-credential model. A successful cryptographic tally would not remove those workflow and governance obligations.

The impact hypothesis is that organisations can reduce unnecessary disclosure while making the result easier to examine and contest. That benefit should be measured, not presumed: completion rates, verification participation, support requests, rejected malformed submissions, reconciliation time, recovery outcomes and total operating cost are useful pilot metrics. Lower cost, higher turnout and institutional adoption have not been established by the present evidence.

XDNA: service utility must follow a delivered service

The existing XDNA utility whitepaper treats application utility as a proposal. zkBallot provides a concrete potential application for that thesis, but the reviewed voting code does not implement XDNA billing, token-gated participation, staking, slashing, rewards, fee burning or an automatic revenue-sharing right.

Potential service units include an institution's election workspace, a defined verification-capacity allowance, evidence-retention service, developer integration support, or an explicitly commissioned trustee-operations service. Each would need implementation, published prices and entitlements, refund and failure handling, payment verification, and a separation between billing records and anonymous ballots. Charging the institution rather than each voter is a design option worth evaluating because a payment account linked to a ballot can undermine privacy.

Service accounting must not become a hidden voting rule. An XDNA balance should not silently replace institutional eligibility, and proof validity must not depend on a marketing promise about token value. The proposed utility creates neither a guaranteed purchase requirement nor a price forecast. Any change to supply, allocation, sale terms, or economic rights belongs in a separately authorised economic document.

12. Size the opportunity without inventing a market

There is no authoritative, independently measured revenue category for DNA Protocol's specific combination of anonymous membership, threshold-encrypted voting and XRPL evidence. A defensible analysis therefore separates observed adjacent-market activity from a transparent bottom-up scenario. Neither is a forecast of DNA Protocol revenue or XDNA value.

Observed anchors, not interchangeable TAM figures

Broadridge reported approximately US$5.561 billion of Investor Communication Solutions revenue for its fiscal year ended 30 June 2026, including about US$2.962 billion of recurring revenue. This is a substantial adjacent industry, but it includes communications, data, disclosure and distribution activities well beyond voting. It is one company's broad segment revenue, not zkBallot's total addressable market. Broadridge FY2026 results, 4 August 2026.

For scale rather than dollars, Broadridge's 2025 proxy-season report records 544 billion shares processed and 1,931 virtual shareholder meetings. Shares are not voters, meetings are not customers, and neither measure can be multiplied by an arbitrary per-person voting fee. These observations demonstrate an established digital-governance workflow, not a measured market share available to zkBallot. 2025 proxy-season statistics.

The International Cooperative Alliance reports approximately three million cooperatives worldwide. This provides a broad organisational population for a single-segment scenario. It is not a list of digitally reachable buyers, and it does not establish election frequency, willingness to pay, or fit with zkBallot's current capacity. ICA facts and figures, accessed 24 October 2026.

A reproducible cooperative-only scenario

Use one organisation as the billing unit and an assumed annual service fee P. Do not multiply member counts again or add associations, DAOs and corporate voting to this population. Doing so could count the same buyer or budget more than once.

Population N = 3,000,000 cooperatives       [external observation]
Illustrative annual fee P                  [assumption]
Technical / commercial fit fraction f      [assumption]

Population-wide ceiling = N x P
Illustrative serviceable pool = N x f x P
Adoption scenario = contracted organisations x P

The US$750 million to US$6 billion population-wide ceiling is only a TAM-style arithmetic envelope under complete adoption at assumed prices. The US$3.75 million to US$300 million serviceable range is a SAM-style scenario, not an estimate backed by a qualified buyer survey. The fit fractions jointly represent size, jurisdiction, digital access, purchasing capacity, workflow suitability and the ability to support trustees. None has yet been measured for zkBallot, and these ranges are not confidence intervals.

Using the reference case, 100, 500 and 2,000 paying organisations would produce US$100,000, US$500,000 and US$2 million respectively in annual gross service fees. Those counts are approximately 0.17%, 0.83% and 3.33% of the assumed 60,000-organisation serviceable pool. They are arithmetic adoption illustrations with no timeline or probability, not a sales pipeline, target, valuation or revenue forecast.

Gross fees are not profit or token demand. Independent audits, integrations, support, hosting, evidence retention, trustee onboarding, incident response, compliance work and customer acquisition may dominate costs. Public verification may also be free to users even when institutional operation is paid. A credible business case needs actual quotes, a defined service package, pilot conversion and retention data, and measured cost per supported election.

The next economic research step is therefore practical: interview a deduplicated cohort of suitable institutions, measure current election budgets and pain points, validate the need for ballot secrecy and audit exports, and test willingness to pay for a clearly bounded service. Only then should the assumed fit fraction and fee be replaced with evidence. The adjacent Broadridge figures, cooperative population and service-fee scenarios are deliberately not added together.

13. Turn a cryptographic workflow into an accountable service

zkBallot's contribution is the composition: approved but anonymously exercised eligibility, encrypted legal choices, distributed tally custody, transactionally consistent acceptance, and evidence that can leave the hosting platform. Its value is not that a ledger makes trust disappear. Its value is making specific assumptions and transitions visible enough to inspect.

The engineering roadmap should follow that premise. First, obtain independent review of the proof composition and recovery model. Second, run a bounded institutional pilot with real operators, separate trustee devices, accessibility testing and realistic failure conditions. Third, measure hosted capacity and recovery before raising voter limits. Fourth, validate an economic service unit before attaching XDNA payment mechanics to it.

These steps can support a meaningful privacy-preserving governance product. They also keep the claims testable: an institution should be able to explain who authorised the electorate, what each proof establishes, how the tally was reconstructed, where evidence is retained, and what happens when the service fails. That is a stronger foundation than either a generic blockchain-voting promise or an unsupported market-size headline.

Implementation note and primary references

The implementation-specific descriptions are based on the reviewed DNA Protocol release modules: protocol.mjs, semaphore-proof.mjs, crypto.mjs, threshold-ceremony.mjs, threshold-tally.mjs, preparation-admission.mjs, institutional-policy.mjs, institutional-store.mjs, event-chain.mjs, history-witness.mjs, recovery.mjs, browser-testnet.mjs and their tests. The article's authoring evidence includes source fingerprints, public-asset checks and local regression results. These are internal engineering records, not a public independent audit report.

The configured maximum of 4,096 and the 256-voter rehearsal must be read as different facts. The published service's health response and matching frontend bytes do not independently authenticate every deployed backend input. Public availability does not remove the release's institutional acceptance gates.

1. DNA Protocol: zkBallot Testnet application. Implementation under review; no endorsement or certification implied.
2. Semaphore: circuits and version 4.14.3 circuit source. Membership, nullifier and message binding.
3. Jens Groth: On the Size of Pairing-based Non-interactive Arguments, 2016. Underlying proof construction.
4. RFC 9496: The ristretto255 and decaf448 Groups, December 2023. Group definition.
5. ElectionGuard: Structures and Processes. Comparative reference for encryption, casting, spoiling and verifiable tallying; not a compatibility claim.
6. XRPL: Parallel Networks and Transaction Cost. Testnet and native-fee boundaries.
7. National Academies: Securing the Vote, 6 September 2018. Public-election security context.
8. Broadridge: Fiscal Year 2026 Results, 4 August 2026, and 2025 Proxy Season Statistics. Adjacent-industry observations, not zkBallot market sizing.
9. International Cooperative Alliance: Facts and Figures. Population input; accessed 24 October 2026.
10. DNA Protocol: XDNA web whitepapers. Existing application-utility proposal; supply and sale terms remain separate.

Research and implementation review, 24 October 2026. Market scenarios are illustrative, all prices are assumed, and no investment return, token value, adoption, legal suitability or security certification is promised.