> 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/chain/roles-and-admin.md).

# Roles and Admin Controls

This page documents the roles in the voting system, their authorities, and how administration works.

## Roles

### Vote Manager

A designated on-chain address that controls voting round creation and administration. The vote manager:

* Creates voting rounds via `MsgCreateVotingSession`
* Is the **only** role that can publish new rounds
* Can reassign the vote manager role to another address via `MsgSetVoteManager`

**Assignment rules:**

* Must be set in `genesis.json` — there is no on-chain bootstrap path
* Only the current vote manager can reassign the role (via `MsgSetVoteManager`)
* Reassignment atomically transfers the current VM's full token balance to the new address

The vote manager does not need to be a validator — it's just an account address.

### Validator

Validators run consensus nodes and participate in the protocol automatically. They:

* Produce blocks (Tendermint BFT consensus)
* Participate in the ceremony (auto-ACK via `PrepareProposal`)
* Decrypt tallies (auto-submit via `PrepareProposal`)
* Can use the admin UI with their own signing key

**Becoming a validator:**

1. Run `join.sh` to initialize a node
2. Get funded (receive tokens from an account that holds stake)
3. `start.sh` auto-registers via `MsgCreateValidatorWithPallasKey`

### Voter

Any Zcash Orchard note holder at the snapshot height. Voters:

* Delegate their voting weight via ZKP #1 (permissionless, no registration needed)
* Cast votes via ZKP #2
* Have their shares revealed via ZKP #3 (delegated to the helper server)

Voters interact via the wallet app, not the admin UI.

### Helper Server

Embedded into `zallyd` itself (configured via the `[helper]` section in `app.toml`). Receives encrypted vote shares from wallet clients and submits them on-chain with random delays for temporal unlinkability. Fully automated — no admin interaction, no separate process to manage.

## Authority Summary

| Action                  | Who                       | How                                                 |
| ----------------------- | ------------------------- | --------------------------------------------------- |
| Fund new validators     | Anyone with tokens        | Admin UI bank send                                  |
| Create voting rounds    | Vote manager only         | Admin UI → `MsgCreateVotingSession`                 |
| Set/change vote manager | Current vote manager only | Admin UI → `MsgSetVoteManager`                      |
| Register as validator   | Anyone (after funding)    | `create-val-tx` → `MsgCreateValidatorWithPallasKey` |
| Vote                    | Any Zcash holder          | Wallet app (ZKP-authenticated, permissionless)      |

## Admin UI

The admin UI (`shielded_vote_generator_ui/`) is a web interface for chain administration. Any validator can connect their signing key.

### Current Capabilities

* **Connect wallet** — Keplr browser extension or dev key
* **Create/edit voting rounds** — Define proposals, options, end time. Snapshot height is read-only, auto-populated from the PIR server's current height.
* **Publish rounds** — Signs and broadcasts `MsgCreateVotingSession` (requires vote manager key)
* **View ceremony status** — Current phase, registered validators, ACK progress, with collapsible per-round ceremony log
* **View round status** — Rounds show PENDING (orange) while the ceremony auto-completes, then transition to ACTIVE
* **View validator list** — All bonded validators and their Pallas key registration status
* **Set vote manager** — Reassign the vote manager role (`MsgSetVoteManager`). Only usable by the current vote manager.
* **Fund validator** — Send tokens to a new validator address. Signs and broadcasts `cosmos.bank.v1beta1.MsgSend`.
* **View vote results** — Proposals, ballot counts, finalized tallies
* **Snapshot settings** — View PIR server status (phase, height, num\_ranges, chain tip). Trigger a rebuild at a new target height with progress tracking. Height must be ≥ NU5 activation and a multiple of 10.

### Planned Additions

* **Validator overview** — Show funding amounts, stake distribution, ceremony eligibility

## Funding Flow

Funding happens via the admin UI:

1. Connect with a key that holds tokens
2. Enter the new validator's address and amount
3. UI signs and broadcasts a standard `cosmos.bank.v1beta1.MsgSend`

This is a standard Cosmos SDK bank send — no special authorization beyond having the tokens. The UI just provides a convenient interface.

> \[!info] Where do the tokens come from? At genesis, tokens are allocated to both the initial validator (enough for self-delegation) and the vote manager account (which holds the reserve). There's no token minting — the total supply is fixed. The vote manager is the primary funder of new validators. The amount sent determines the validator's consensus voting power (stake). For meaningful decentralization, stake should be distributed roughly evenly across validators.