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

# Delegation Setup

Delegation allows a voter to transfer their voting authority to another party. The delegate receives a Vote Authority Note and can vote or further delegate on the voter's behalf.

## How it works

Delegation uses the same note-spend model as voting:

1. The delegator's VAN is consumed (its nullifier is published)
2. Two new VANs are produced:
   * One for the delegate (with their hotkey and the delegated amount)
   * One for the delegator (with the remaining amount)
3. Both new VANs are inserted into the vote commitment tree

The ZKP proves the amounts sum correctly and the `allowed_proposals` bitmask is preserved.

## What the delegate receives

The delegate gets a VAN with:

* Their own voting hotkey as the authorized key
* The delegated amount as `total_note_value`
* The same `allowed_proposals` bitmask as the delegator

From here, the delegate can vote or further delegate, following the exact same protocol as a direct voter.

## Privacy

* The delegation amount is hidden inside the vote commitment tree
* The delegator's identity is hidden (the VAN is consumed via nullifier, and the new VANs are unlinkable to the old one without the witness)
* The delegate's identity is hidden (their hotkey is committed inside the VAN, not published)

## Current status

> Delegation is specified as an optional extension (§6.0 in Gov Steps V1). The core protocol prioritizes direct voting first.