zkBallot:
Decisions That Carry
Their Own Evidence

A vote closes. A result appears. The institution moves forward.

But responsibility for that decision does not end with the announcement.

Months later, a new committee may need to review the record. A participant may ask whether their accepted ballot was included. A governance team may need to explain which rules governed the decision, which records supported the count, and whether the retained evidence still agrees with the published outcome.

A result tells an institution what happened.

A verifiable record gives it something more: a structured basis for checking how that result was produced.

DNA Protocol’s zkBallot is engineered around this distinction. Its output is not limited to a voting screen or a displayed total. The institutional implementation produces an evidence package that connects the decision’s configuration, accepted records, trustee contributions, and event history to a result that can be checked outside the original voting session.

That capability extends zkBallot’s utility beyond the moment of participation.

The vote produces a decision. DNA Protocol gives the institution evidence it can retain, examine, and verify.

Beyond The Dashboard

A dashboard is useful for operating an election. It shows progress, accepted participation, and the eventual result.

An institutional record serves a different purpose.

It must remain useful when the original browser session has ended, when the person who administered the election has moved on, or when a reviewer needs to examine the decision without relying solely on the operator’s presentation.

A screenshot preserves an appearance. A written summary preserves an explanation. Neither, by itself, provides the structured inputs needed to repeat the underlying verification.

zkBallot’s evidence package is designed for that next step.

It retains machine-readable election material and the relationships that make the material meaningful. The package can be supplied to DNA’s verification software, which evaluates the record rather than merely displaying its contents.

This changes what an institution can hand over.

Instead of transferring only a statement that a resolution passed, it can transfer the evidence supporting the recorded decision, together with the information needed to check that evidence.

The result becomes more than an announcement. It becomes a reviewable institutional object.

A Coherent Record

DNA Protocol’s public evidence format brings several categories of material into one defined package:

• The election audit, including its configuration, accepted encrypted records, preparations, receipt commitment, closure state, and tally.
• The enrolment record connecting the institutional setup to the locked election.
• The public trustee-ceremony material.
• The published trustee decryption contributions.
• The ordered election-event history.
• A commitment covering the contents of the package.

The significance is not simply that these items are available for download.

It is that zkBallot verifies their agreement.

A collection of individually plausible records is not necessarily evidence of one coherent decision. A ceremony could belong to a different configuration. An enrolment record could disagree with the locked election. A published contribution could refer to a different accepted-ballot set. An event history could omit something that appears elsewhere in the audit.

DNA’s implementation checks these connections explicitly.

The public-evidence verifier reconstructs the ceremony’s public manifest and compares it with the ceremony bound into the election. It checks that the enrolment and locked election agree. It evaluates the published decryption contributions against the corresponding election and tally context.

This is an important part of DNA Protocol’s engineering contribution: verification across the boundaries between components.

The institution does not need a folder containing unrelated claims. It needs evidence whose parts refer to the same decision.

zkBallot makes that agreement a condition of verification.

Integrity With Meaning

A file hash answers an important question: does this content match a particular commitment?

An institutional evidence verifier must answer a more demanding question: do the contents form a valid and internally consistent decision record?

zkBallot therefore checks more than the outer commitment.

Its public-evidence implementation constructs the events that should exist from the records contained in the package. It then compares that expected history with the supplied event history.

The checks include dependencies between phases and records.

Trustee registration must follow setup. The encrypted trustee exchanges and confirmations must fit the ceremony. Enrolment must connect to that completed setup. Voting must connect to the approved, locked election. Accepted ballot events must correspond to their preparations. Tally publication must connect to the relevant trustee contributions.

The verifier also checks timing constraints. It rejects ceremony activity that continues beyond the applicable expiry, inconsistent phase timestamps, and decryption or closing events that precede the verified close time.

These are not decorative entries in an activity log.

They are relationships the verification software evaluates.

A record that includes an accepted ballot but omits the corresponding acceptance event does not become coherent merely because someone recalculates its hashes. Likewise, a valid-looking event sequence cannot substitute for the cryptographic evidence required by the audit.

DNA Protocol combines content integrity with checks on the record’s meaning.

For an institutional reviewer, that distinction matters. The question is not only whether a document has changed. It is whether the retained material agrees about the process and result it describes.

One Consistent Revision

Evidence must also be collected correctly.

An election record can span multiple responses: accepted records, ballot preparations, and events. If those responses are collected while the election changes, a client could otherwise assemble material from different moments.

The resulting package might contain individually reasonable pages without representing one consistent revision.

zkBallot addresses this during evidence retrieval.

Its collection process begins with an evidence header containing the relevant counts and a checkpoint. Subsequent page requests are pinned to that checkpoint’s revision.

The client checks the election identifier, checkpoint, total count, offset, expected page length, and continuation information for each response. On the service side, a request pinned to a revision that has changed is rejected rather than silently returning a different revision.

The client must discard the partial collection and start again from the new checkpoint.

This is a practical example of the engineering behind portable evidence. Correctness is not confined to a final cryptographic operation. It also depends on how the material reaches the verifier.

The collection checks establish consistency during retrieval. The assembled package must still pass the full evidence verification.

Together, these layers give institutions a stronger basis for review: a consistently collected record, followed by checks on its cryptographic contents and internal relationships.

Verification In Practice

To examine this capability concretely, a retained zkBallot institutional protocol-test package was checked using the standalone verifier while preparing this article.

The sample contained:

• Three accepted ballots across three options.
• Four ballot preparations, including one challenged preparation.
• Three registered trustees.
• Two published decryption contributions.
• Thirty-three election events.
• A closed election with a published tally.

Verification against the retained checkpoint returned:

{
  "valid": true,
  "ballots": 3,
  "tallyVerified": true,
  "evidenceVerified": true,
  "retainedCheckpointMatched": true
}

These results identify separate aspects of the review.

tallyVerified indicates that the supplied tally passed the applicable verification. evidenceVerified indicates that the broader public-evidence package passed its checks. retainedCheckpointMatched records that the supplied history agreed with the separately provided checkpoint.

This distinction prevents an ongoing, internally valid record from being confused with a verified final tally.

Three controlled changes were then tested in memory, without altering the retained source files:

The second case illustrates the value of DNA’s cross-record verification particularly clearly.

Recalculating hashes did not supply the missing event or make the remaining history agree with the unchanged audit. The verifier evaluated the relationship between the records, not just the mathematical consistency of their new hashes.

These are local protocol-test results, not customer-election or hosted-capacity claims. Their purpose is precise: to demonstrate the difference between checking an exported file and verifying a coherent election-evidence package.

Evidence Across Time

Portability becomes more valuable when evidence can be compared with something retained earlier.

A checkpoint provides such a reference. In zkBallot, it identifies an election, an event-sequence position, and the hash at that position.

When a later package is checked against a genuinely retained checkpoint, the verifier checks that the supplied history still contains the previously observed commitment at the expected point.

This gives the institution a connection between observations made at different times.

The distinction between “retained earlier” and “supplied now” is important. A checkpoint received only alongside a new export is not an independent historical reference to that export. Its additional value comes from separate custody and retention.

DNA’s history-witness implementation reflects this principle. It checks a newly observed history against the previously stored checkpoint before advancing the retained reference. An unreadable, invalid, or mismatched checkpoint is not silently replaced.

For an institution, that behaviour supports continuity.

A later review does not have to begin entirely from the operator’s latest presentation. It can begin from a record the reviewer or another designated observer already held.

Continuity Between People

The strongest institutional utility of this evidence model appears when responsibility changes hands.

Consider an illustrative member association conducting a confidential resolution.

The organiser completes the voting process and makes the result available. The association retains the evidence package. A designated observer separately retains a checkpoint. Participants keep their relevant receipts.

Later, a new governance officer takes responsibility for the association’s records.

That officer should not have to rely exclusively on a screenshot, an inaccessible former administrator’s account, or someone’s recollection of the election.

With the retained materials and the appropriate verification software, the officer can examine the decision record outside the original voting session.

Different institutional questions can then be addressed through different pieces of evidence.

Which decision does this record describe?
The reviewer can inspect the election configuration and verify its agreement with the associated setup and enrolment material.

Does the supplied result follow from the recorded ballot set?
The audit and tally checks evaluate that relationship.

Does a participant’s receipt agree with the retained audit?
The receipt verifier checks the corresponding election, acceptance record, and inclusion evidence. It also supports receipts associated with an earlier accepted-record snapshot, checking that snapshot against the corresponding prefix of the verified audit.

Does this later history agree with the checkpoint we retained?
The history check compares the supplied record with that earlier reference.

The benefit is not that cryptography answers every governance question.

It is that important technical questions have explicit evidence and a defined verification path. Human review can then concentrate on the institution’s responsibilities, policies, and decisions rather than reconstructing basic record consistency from scattered materials.

Privacy Preserved

Making a decision reviewable should not require turning an institutional archive into a collection of participant secrets.

zkBallot’s public evidence is structured around the material needed for verification. It is not a repository for private identity secrets or plaintext trustee key shares.

Accepted choices remain represented through encrypted ballot records and their associated proofs. Deliberately challenged preparations include their disclosed openings, allowing those test preparations to be checked and distinguished from accepted votes.

This gives the evidence package a specific role.

It supports examination of the decision record without requiring the reviewer to collect the private material used by voters and trustees to participate.

For institutions, this separation is valuable. Evidence retention and secret custody are different responsibilities, and they should not be collapsed into the same archive simply because both relate to an election.

The institution still needs appropriate policies for access, metadata, retention, and small-group privacy. But the verification workflow does not inherently require every reviewer to become a custodian of participant secrets.

Retain The Verifier

A durable evidence strategy should preserve more than the export.

The software and verification artifacts needed to interpret that export also matter.

For institutional retention, a practical review package should therefore include the evidence file, applicable separately retained checkpoints, relevant receipts, and a record of the verification software and dependency versions used.

This is an operational recommendation, not a claim that an export automatically guarantees indefinite compatibility with future software.

The value of the approach is reproducibility.

A later reviewer should be able to establish what was checked, with which implementation, against which retained materials. That makes verification a repeatable procedure rather than a one-time screen state.

DNA’s standalone verifier supports this model by accepting saved evidence, an optional checkpoint, and an optional receipt as explicit inputs.

The same verification work can be performed outside the original interface. That is independent execution of the application’s verification logic, not a separate cryptographic implementation or an independent security audit.

Keeping that distinction clear makes the result more useful: institutions can reproduce application-level checks while treating external assurance as a separate responsibility.

The DNA Advantage

The institutional value of zkBallot is not captured by naming a cryptographic primitive.

It appears in the way DNA Protocol connects the entire evidence lifecycle:

Collect a consistent record. Verify its contents. Check the relationships between its parts. Compare it with retained observations. Preserve it for the next reviewer.

Each step addresses a practical requirement.

Governance teams need records that survive changes in personnel. Participants need a way to reconcile receipts with the retained decision. Reviewers need explicit verification outcomes. Institutions need a technical record that can be handed over without handing over private participant secrets.

zkBallot provides concrete mechanisms around those needs.

This also gives institutions a focused way to evaluate its utility. An assessment can ask whether the organisation can successfully export the record, verify it outside the original session, reconcile a participant receipt, and reproduce the review during a handover.

Those are observable capabilities, not abstract claims about trust.

They connect DNA Protocol’s engineering to the work institutions actually perform after a decision: review, explanation, retention, and continuity.

The Decision Endures

A confidential vote should not leave an institution with a permanent choice between exposing participants and asking everyone to trust a displayed number.

DNA Protocol’s zkBallot gives it another path.

The institution can retain a structured record whose contents and relationships are checkable. Participants can retain evidence relevant to their accepted records. Observers can preserve checkpoints. Later reviewers can examine the package beyond the original voting interface.

The result is not merely stored. It remains connected to evidence that can be inspected.

That is the lasting utility DNA Protocol is building into zkBallot: decisions that carry their own evidence, so institutional accountability can continue after voting ends.

Explore zkBallot by DNA Protocol.

Implementation note: This article examines DNA Protocol’s institutional Testnet implementation and a retained local protocol-test package verified on 28 October 2026. The current service status identifies an XRPL Testnet candidate that is not independently audited. The verification exercise demonstrates specific implemented checks; it is not a production-security certification.