> 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/readme.md).

# Introduction

Shielded Vote is a private governance voting protocol for ZCash. It lets ZEC holders vote on proposals using their shielded balances, without revealing individual vote amounts or linking votes to identities.

## Key properties

* **Users only need to come online once to vote** No registration periods, or two phase "commit/reveal" to vote. Voting will take multiple actions from the wallet though.
* **One keystone signature** snapshots your on-chain balance and delegates voting rights to a hotkey. Signed message is clear, no risk to your funds
* **No information about your nullifier is leaked** The snapshot ZKP does not reveal it. You query for your nullifier exclusion proofs via PIR, keeping bandwidth light.
* **Vote amounts are encrypted** using homomorphic El Gamal, with an election authority running the decryption. Individual vote amounts are never revealed. Only the aggregate Yes/No per proposal is revealed, with this step being auditable.
* **Votes are split into several uncorrelated smaller votes** so that even if the election authority is malicious, you get anonymity for your total balance.
* **These vote splits are sent to distinct "vote relayers" to hide timing metadata**. Vote relayers do not learn vote amounts, but they can correlate different vote splits from the same party. Once vote splits are published, assuming an honest vote server, they are unlinkable.
* **Delegation (TODO)** lets you assign voting rights (fully or partially) to third parties

## The voting design

The vote is setup with a series of questions with a given mainnet snapshot height. Each token held on mainnet at the snapshot height, is available to use for voting, up to requiring a minimum of 0.125 ZEC per vote. 1 token at snapshot = 1 vote.

## How it works (at a glance)

1. **Setup** — There is a Cosmos SDK chain running, to orchestrate governance rounds. A governance round is configured with snapshot height, proposals, and an election authority El-Gamal key. Validators verify relevant fields of this.
2. **Delegation** — You prove ownership of your notes via a keystone tx authorizing your own hotkey to vote. A Vote Authority Note (VAN) is created + ZKP is submitted to the vote chain
3. **Voting** — Your hotkey casts votes by consuming the VAN, making a new VAN and producing a Vote Commitment containing multiple encrypted vote shares
4. **Reveal** — You delegate revealing your individual encrypted vote shares to different servers, who randomly delay the txs, individually ZKP them at the then-latest block height, and submit them to the blockchain
5. **Tally** — Everyone sums the encrypted shares publicly; the election authority decrypts and publishes the result with a correctness proof

See [Design Principles](https://github.com/z-cale/shielded-vote-book/blob/main/shielded_vote_book/overview/design-principles.md) for the full motivation, [comparison to today](https://github.com/z-cale/shielded-vote-book/blob/main/shielded_vote_book/overview/comparison-to-today.md), or [Overall Flow](https://github.com/z-cale/shielded-vote-book/blob/main/shielded_vote_book/overview/overall-flow.md) for a detailed walkthrough.