> 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/setting-up-a-validator.md).

# Setting Up a Validator

This page covers how to join the vote chain as a validator, from initial setup through ceremony participation.

## Prerequisites

* Linux or macOS (amd64 or arm64)
* `curl` and `jq` installed
* The bootstrap operator must have published `genesis.json` and `network.json` to the distribution endpoint

## Quick Start

Run the join script:

```bash
curl -fsSL https://shielded-vote.nyc3.digitaloceanspaces.com/join.sh | bash
```

This script:

1. Downloads pre-built `zallyd` and `create-val-tx` binaries
2. Downloads `genesis.json` and `network.json` from the distribution endpoint
3. Initializes a node with a fresh validator account
4. Generates cryptographic keys (consensus key, Pallas keypair for ceremony)
5. Configures the node to connect to existing peers
6. Generates a `start.sh` script for syncing and registration

After the script completes, it prints your **validator address** — share this with the bootstrap operator to receive funding.

## Getting Funded

New validators start with zero balance. The bootstrap operator sends tokens from the chain's reserve via the admin UI (or CLI: `zallyd tx bank send`).

The funding amount determines your **consensus voting power** — more stake means more influence in block production and ceremony participation.

Once your account is funded, `start.sh` will detect the balance automatically and proceed to registration.

## Starting Your Node

```bash
~/.zallyd/start.sh
```

This script:

1. Starts `zallyd` in the background
2. Waits for the node to sync with the network
3. Once synced and funded, broadcasts `MsgCreateValidatorWithPallasKey` via `create-val-tx`
4. This atomically registers you as a validator AND publishes your Pallas public key for the ceremony

After registration, your node participates in consensus (block production) and will automatically participate in the ceremony when triggered.

## What Happens During Setup

### Key Generation

During `join.sh`, three keypairs are generated:

| Key                | Purpose                                       | Storage                                      |
| ------------------ | --------------------------------------------- | -------------------------------------------- |
| **Consensus key**  | Tendermint consensus (block signing)          | `~/.zallyd/config/priv_validator_key.json`   |
| **Account key**    | Cosmos SDK transactions (staking, governance) | `~/.zallyd/` keyring                         |
| **Pallas keypair** | ECIES ceremony (receiving encrypted `ea_sk`)  | `~/.zallyd/pallas.sk`, `~/.zallyd/pallas.pk` |

The Pallas key is what connects you to the ceremony — without it, you can't receive the election authority secret key.

### Registration Transaction

`create-val-tx` builds a `MsgCreateValidatorWithPallasKey` containing:

* Your Tendermint consensus public key
* Your self-delegation amount (stake)
* Your Pallas public key
* Commission rates (10% rate, 20% max, 1% max change)

This is a single atomic transaction — your Pallas PK is registered on-chain at the same time as your validator, ensuring you're eligible for the next ceremony.

## Ceremony Participation

Once registered, ceremony participation is **fully automatic**:

1. When a voting round is published and triggers a ceremony, the chain checks if your Pallas PK is registered
2. If you're selected as dealer (next block proposer), your node auto-generates `ea_sk`, encrypts it to all validators, and injects the DealerTx
3. When you see a DealerTx on-chain, your node auto-decrypts your share via `PrepareProposal`, verifies it, and injects an ACK into your next proposed block
4. `ea_sk` is stored to disk at `~/.zallyd/ea.sk` for tally decryption

No manual intervention needed — as long as your node is running and proposing blocks, you participate automatically.

> \[!warning] Consecutive misses lead to jailing If your validator is snapshotted into a round's ceremony but fails to ack (e.g., node offline), a consecutive miss counter is incremented. After **3 consecutive misses**, your validator is jailed. A successful ack in any round resets the counter.

## Tally Participation

Similarly automatic. When a voting round's window closes:

1. The round transitions to TALLYING
2. When it's your turn to propose a block, your node loads `ea_sk`, decrypts the aggregate ciphertexts, and injects `MsgSubmitTally`
3. The tally includes Chaum-Pedersen DLEQ proofs so anyone can verify correctness

## Hardware Requirements

> \[!warning] To be determined Specific hardware requirements will be documented once the system is benchmarked under realistic load. Expected to be modest — the chain is purpose-built for governance and handles low transaction throughput.

## Monitoring

Check your node status:

```bash
zallyd status --home ~/.zallyd
```

Check ceremony state:

```bash
curl -s http://localhost:1318/zally/v1/ceremony | jq .
```

Check if your validator is in the active set:

```bash
zallyd query staking validators --home ~/.zallyd --output json | jq '.validators[] | {moniker: .description.moniker, status: .status}'
```

Follow node logs:

```bash
tail -f ~/.zallyd/node.log
```