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

# Design Principles

This page describes the core design principles behind Shielded Vote.

## Keystone compatibility

Everything is keystone compatible. The first transaction snapshots your on-chain balance and moves it to governance with one keystone tx for up to 5 notes. The transaction is a dummy 1-zatoshi transfer from a note that doesn't really exist, so there is no risk of your funds being stolen.

## Only one user session to vote

We aim to just make *one* active user session in order to do a full vote. This means its ok for users to do several clicks or ZKP's with some latency. However they should be fully done with voting, aside from decision making in a minute or two.

This rules out doing two phase voting approaches, like "commitment" and "reveal". We also face a problem that the mobile computing environment does not easily enable background computation. Hence our desire to prevent timing leakage requires "helper servers" of some form to submit a final ZKP on your behalf. We aim to minimize the data leakage to these server.

## Best-effort total balance privacy

We aim to keep your total holdings private, despite voting seeking to enable doing public results off your holding amounts. We solve this via three tricks:

* **Homomorphic encryption** — Vote amounts are encrypted under the election authority's key. Individual amounts are never revealed on-chain.
* **Private delegation** — You can partially delegate your votes to third parties. No one but the delegation recipient can see the delegation amount.
* **Vote splitting** — Your vote is chunked into many "shares" and delegated to a server for staggered on-chain submission. This prevents timing correlation and makes it infeasible to reconstruct your total balance.

The reason we have vote splitting send shares to another server, vs doing locally, is due to the difficulties in getting reliable background CPU time in the mobile environment. The alternative would be to require the user to keep returning to the app, but this seems infeasible.

Servers who receive delegations can fully delay the votes themselves.

## Unlinkable voting keys

All transactions after the snapshot proof are done from a different key, unlinked to your main one. We aim for just one keystone signature per voting round.

## Auditable tallying

The election authority decrypts only the aggregate vote total per (proposal, decision), and must publish a Chaum-Pedersen proof of correct decryption. Anyone can verify the tally against on-chain data.

## Lightweight client proofs via PIR

We avoid the client needing to download all Orchard nullifiers (\~2GB) to get the exclusion proof. Instead, the client uses Private Information Retrieval (PIR) to query a server without revealing which nullifier it is checking.