> For the complete documentation index, see [llms.txt](https://valargroup.gitbook.io/shielded-vote-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://valargroup.gitbook.io/shielded-vote-docs/overview/overall-flow.md).

# Overall Flow

The protocol proceeds in five phases.

## Phase 0 — Setup

A governance round is configured with:

* Snapshot height and blockhash for note balances (the admin sets the snapshot height via the Snapshot Settings page, which triggers a PIR server rebuild; the round editor then auto-populates this height)
* Proposal list and voting end time
* Nullifier IMT root (for non-membership proofs, fetched from the PIR server at the snapshot height)
* Note commitment tree root at the snapshot height
* Election authority keypair `(ea_sk, ea_pk)` for homomorphic encryption
* Verification keys for all three ZKP circuits

These are combined into a `vote_round_id` that scopes all signatures and nullifiers to this round.

## Phase 1 — Delegation (ZKP #1)

The user authorizes delegation of their voting rights to a locally-generated hotkey. For Keystone users, this is a hardware-signed dummy transaction (0-value PCZT). For software wallet users, the app signs directly with the wallet's spending key.

Then they create a ZKP, which at a high level proves:

* The user owns up to 5 valid, unspent notes at snapshot height
* The governance commitment correctly binds the hotkey, total weight, and round
* Governance nullifiers prevent double-delegation

See [here](https://github.com/z-cale/shielded-vote-book/blob/main/zkps/zkp1-delegation-proof/README.md) for details.

The result is a Vote Authority Note (VAN) inserted into the vote commitment tree on the vote chain.

## Phase 2 — Voting (ZKP #2)

The hotkey casts a vote by consuming the VAN and producing:

* A new VAN with decremented proposal authority
* A Vote Commitment containing 16 encrypted shares (El Gamal under `ea_pk`)
  * This will substantially increase after we're happy with ZKP security.

ZKP 2 proves correct ownership of the old VAN, the new VAN is constructed correctly, and the Vote Commitment is constructed correctly. See [here](https://github.com/z-cale/shielded-vote-book/blob/main/zkps/zkp2-vote-proof/README.md) for details.

## Phase 3 — Share Submission

Each encrypted share is sent as an independent payload to the submission server.

## Phase 4 — Share Reveal (ZKP #3)

The server constructs ZKP #3 (proving the share came from a valid vote commitment) and submits it to the vote chain at a randomized delay. The chain accumulates El Gamal ciphertexts homomorphically.

See [here](https://github.com/z-cale/shielded-vote-book/blob/main/zkps/zkp3-vote-reveal-proof/README.md) for details.

## Tally

After the voting window closes, all full nodes on-chain sum the encryption ciphertexts. The election authority decrypts the aggregate and publishes the result with a proof of correct decryption.

This happens automatically. See [here](https://github.com/z-cale/shielded-vote-book/blob/main/appendices/tally/README.md) for tally details.