> 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/delegation/server-delegated-shares.md).

# Server-Delegated Share Submission

After constructing a vote commitment (Phase 3), the client delegates share submission to one or more untrusted servers. This is critical for both reliability and privacy.

## Why delegate to servers

* **Reliability** — A phone computing ZKPs in the background is unreliable. The app may be killed, connectivity may drop. Servers are always-on.
* **Temporal unlinkability** — If the client submitted all shares itself, an observer could link them by timing. Servers stagger submissions across the voting window, mixing shares from many voters.

## What the client sends

A `delegated_voting_share_payload` per share, containing:

* Vote commitment data: `(shares_hash, proposal_id, vote_decision)`
* Position in the vote commitment tree
* One encrypted share: `enc_share_i = (C1_i, C2_i)` and `share_index`
* All 16 encrypted shares (needed to recompute `shares_hash` in ZKP #3)
* All 16 blind factors `(blind_0, ..., blind_15)` — needed for blinded share commitment recomputation in ZKP #3

## What the server does

1. Randomly delays the submission (staggering across the voting window)
2. Collects the current vote commitment tree Merkle path
3. Derives the share nullifier
4. Constructs ZKP #3 (Vote Reveal Proof)
5. Submits to the vote chain

## What the server learns

* The encrypted share (but **not** the plaintext amount — it's El Gamal encrypted)
* The proposal and vote decision
* That this share came from *some* vote commitment (but not which one — ZKP #3 hides this)

## What the server cannot do

* Decrypt the share amount (requires `ea_sk`)
* Link the share to a specific voter (the vote commitment is hidden)
* Modify the vote (the share is committed in the shares hash)
* Reuse the share (the nullifier prevents double-counting)

## Trust requirement

The server's primary trust requirement is **not leaking timing metadata**. If a server reveals when it received shares from the same client, temporal unlinkability is weakened. Using multiple independent servers mitigates this.