Penumbra Validator Kit

Penumbra's own guidance is 2 to 4 vCPU, 8 GB RAM and ~200 GB of disk growing 20 GB a week. With the pruned snapshot and a pruned pd, the disk figure drops to about 100 GB growing roughly 2 GB a week. Disk latency matters more than CPU: the state store is RocksDB and a virtualized cloud SSD will make you fall behind.

These are the live chain parameters for penumbra-1, read from state at height 12,562,477 on 2026-09-06. Amounts are in UM; the chain counts in upenumbra, one millionth of a UM.

Budget for the stake itself, a small amount for transaction fees, and one funding-stream decision: Penumbra has no flat commission. Your validator definition declares one or more streams, each a recipient address and a rate in basis points, and the rest flows to delegators.

Releases come from penumbrafi/penumbra, built by GitHub Actions from the release tag; the checksum is in SHA256SUMS on the release page.

# pd 2.0.9, prebuilt for x86_64 Linux (arm64: build from the v2.0.9 tag)
curl -fsSL -o pd.tar.gz https://github.com/penumbrafi/penumbra/releases/download/v2.0.9/pd-recovery-2.0.9-x86_64-linux-gnu.tar.gz
tar xzf pd.tar.gz && sudo install -m 0755 pd-recovery-2.0.9-x86_64-linux-gnu/pd /usr/local/bin/pd
sha256sum /usr/local/bin/pd   # 3692343987fcc22987ade5a70ad80ffd9da8677e1ce103dd65052179f4976eb9
pd --version                   # pd 2.0.9

# CometBFT 0.37.18 (the binary prints 0.37.16; that is a known upstream bug)
curl -LO https://github.com/cometbft/cometbft/releases/download/v0.37.18/cometbft_0.37.18_linux_amd64.tar.gz
tar -xzf cometbft_0.37.18_linux_amd64.tar.gz cometbft
sudo install -m 0755 cometbft /usr/local/bin/cometbft

Do not run anything older than 0.37.18. It carries the fix for the critical January 2026 CometBFT advisory.

This generates the node directory under ~/.penumbra/network_data/node0, including your node key and consensus key, and fetches genesis and peers from an existing node.

pd network join \
  --moniker "your-validator-name" \
  --external-address "YOUR.PUBLIC.IP:26656" \
  https://penumbra.rotko.net

Then create the two systemd units. The file limit line is not optional.

# /etc/systemd/system/penumbra.service
[Unit]
Description=Penumbra daemon
After=network-online.target
[Service]
User=penumbra
ExecStart=/usr/local/bin/pd start --home /home/penumbra/.penumbra/network_data/node0/pd
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/cometbft.service
[Unit]
Description=CometBFT
After=penumbra.service
Requires=penumbra.service
[Service]
User=penumbra
ExecStart=/usr/local/bin/cometbft start --home /home/penumbra/.penumbra/network_data/node0/cometbft
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

Do not start them yet. Restore the snapshot first, or you will replay the chain from the last upgrade height, which takes days.

The snapshot is a pd state store already pruned to a single version plus CometBFT's block history since the last upgrade. It contains no keys and no node identity. Your own priv_validator_state.json must survive the restore, so it is moved aside and back.

Preferred: torrent. The torrent is seeded continuously by Rotko and by everyone who restored before you, and it carries our HTTPS host as a web seed, so it never has fewer sources than the plain download. Any client works; the commands use aria2c because it is non-interactive.

cd ~/.penumbra/network_data/node0
curl -LO https://snapshot.rotko.net/penumbra-1/latest/manifest.json
curl -LO "https://snapshot.rotko.net/penumbra-1/latest/$(jq -r .torrent manifest.json)"
aria2c --seed-time=0 --dir=. "$(jq -r .torrent manifest.json)"
# the torrent's piece hashes verify the download; the sha256 below is a second, independent check
sha256sum -c <(jq -r '"\(.sha256)  \(.file)"' manifest.json)

Or plain HTTPS, resumable with curl -C -:

curl -C - -LO "https://snapshot.rotko.net/penumbra-1/latest/$(jq -r .file manifest.json)"
sha256sum -c <(jq -r '"\(.sha256)  \(.file)"' manifest.json)

Then swap it in, keeping your own signing state:

mv cometbft/data/priv_validator_state.json /tmp/pvs.json
rm -rf pd/rocksdb cometbft/data
lz4 -dc "$(jq -r .file manifest.json)" | tar -xf -
mkdir -p cometbft/data && mv /tmp/pvs.json cometbft/data/

Leave your torrent client seeding afterwards if you can. That is how the next validator gets it quickly.

H=$(jq -r .height manifest.json)
curl -s "https://penumbra.rotko.net/block?height=$((H+1))" | jq -r .result.block.header.app_hash
jq -r .root_hash manifest.json
# the two lines must be identical (case-insensitive)

sudo chown -R penumbra:penumbra ~penumbra/.penumbra
sudo systemctl enable --now penumbra
sudo systemctl enable --now cometbft
journalctl -fu cometbft

The first CometBFT lines should read ABCI Handshake App Info height=H hash=<root hash> followed by Completed ABCI Handshake. Blocks then arrive from peers at a few hundred per minute until you reach the tip.

curl -s localhost:26657/status | jq '.result.sync_info | {latest_block_height, catching_up}'

You are synced when catching_up is false. Nothing you do in the next step matters until then.

The wallet that owns the validator can live on a different machine from the node, and for a production validator it should. The identity key derived from that wallet is permanent; you cannot rotate it later. Choose custody accordingly.

# wallet for the validator identity (soft-kms is fine for testing; use threshold custody in production)
pcli init soft-kms generate
pcli view address 0
# fund this address with at least 100 UM plus a little for fees
pcli view balance

# build the definition from the node's consensus key
pcli validator definition template \
  --tendermint-validator-keyfile ~/.penumbra/network_data/node0/cometbft/config/priv_validator_key.json \
  --file validator.toml

Edit validator.toml: set enabled = true, fill name, website and description, and decide your funding streams. If pcli runs elsewhere, paste the value from the node's priv_validator_key.json into [consensus_key]. Then upload, find your identity, and self-delegate.

pcli validator definition upload --file validator.toml
pcli validator identity
pcli tx delegate 100penumbra --to penumbravalid1...
pcli query validator list --show-inactive

Your validator appears as inactive immediately and becomes active at the next epoch boundary if it ranks inside the top 100 by voting power. Every later change to the definition is the same upload with sequence_number incremented.

Pruning your own node later

A node restored from this snapshot starts pruned: the snapshot’s state store is about 24 GB instead of the roughly 320 GB an unpruned node carries. To prune a node you already run, use pd migrate prune from pd v2.0.11; the binary is a drop-in for 2.0.9 and 2.0.10, with no migration and no coordination. Do not run v2.0.10’s pd migrate prune on post-restart state. It finished with the root hash unchanged but produced a node that read one of the validators disabled by the restart migration as still active, and panicked on its first block: the restart migration left three keys whose merkle leaf and value store disagree, and the 2.0.10 pruner replayed the tree over them. v2.0.11 detects those keys, preserves the value a node reads, and fingerprints every column family it did not rebuild in both databases before swapping anything in. Stop both cometbft and pd, run it as the pd user with ulimit -n 1048576, budget 1–4 hours and about 5 GB of RAM, then start pd before cometbft; the unpruned store is kept at rocksdb_old until you delete it. One validator at a time, and archive, RPC, indexer and snapshot-provider nodes stay unpruned.

Upgrades

Consensus upgrades are announced on the repository. Point releases in the same series are drop-in binary swaps with no coordination. The one exception is the coordinated restart release, pd 2.0.9, which every node must run through pd migrate-restart exactly as described in its runbook. A release with a new APP_VERSION halts the chain at a governance-set height and every node runs pd migrate; that migration deletes CometBFT block history by design, which is why the archive is kept separately.

Monitoring

Watch two numbers: your node's latest_block_height against a public RPC, and the missed-blocks counter for your identity in pcli query validator uptime. Alert well before 9,500.

Help

Issues and questions go to github.com/penumbrafi/penumbra. The public RPC is https://penumbra.rotko.net, which stays unpruned as the network's archive and relayer endpoint.

Restart peer: a Rotko node already migrated to the restarted chain (pd 2.0.9, genesis at 12,598,602) accepts inbound p2p at 99e470d0ed8fd29f4a596731e3f077c7c3b5fc17@penumbra-peer.rotko.net:26656. Put it in persistent_peers when you restart; also served as plain text at penumbra-1/peers.txt. Restart instructions: RESTART-STEPS.md, release pd v2.0.9.

Restart done: penumbra-1 halted after height 12,598,600 on 2026-09-02 and was restarted by the validator community on 2026-09-07 at 05:33 UTC from a checkpoint genesis at 12,598,602 (pd v2.0.9). Noble’s IBC client was refreshed the same minute, so the USDC bridge stayed open. Live status: snapshot.rotko.net/restart. Validators not yet migrated: restore the 12598602 snapshot below over your own keys (no migrate step) and start pd 2.0.9.

Taken weekly from Rotko's archive node with a ZFS freeze, pruned on a clone, verified by starting a node on the result and syncing it live before publishing. Every snapshot is published as a torrent with the HTTPS file as a web seed, and Rotko seeds it permanently; seeding health is on status.rotko.net. Restore with the commands in step 4.

Event index archives

For running your own explorer or pindexer without reindexing from genesis. Three PostgreSQL databases, each shared as its own archive so you only fetch the layer you need. Block coverage is stated per database; "genesis" means block 1.

The per-database archives are pg_dump custom-format files (zstd-compressed) restorable into PostgreSQL 16 or newer: createdb pindexer && pg_restore -d pindexer --no-owner penumbra-1-pindexer-12598600.pgdump (same for explorer_backend), then point pindexer or the explorer backend at a live node's raw event database and let them follow the tip. All three end at 12,598,600, the last CometBFT block before the restart; 12,598,601 is the synthetic empty migration block executed by pd migrate (no CometBFT block, no events; the raw events database carries an empty blocks row for it so gap checks pass) and the chain resumes at 12,598,602. The raw events dump replaces the interim tarball once regeneration of 10,600,589 → 12,598,600 completes; the interim tarball is a PostgreSQL 18 data directory (top-level path postgresql/18/main). Details in penumbra-1/index/manifest.json.

Each snapshot lives at https://snapshot.rotko.net/penumbra-1/<height>/ with its manifest.json and .sha256 beside it, and penumbra-1/latest/ always points at the newest one, so the restore commands above never need editing. snapshots.rotko.net is an alias of the same host.

History archive

The complete penumbra-1 history, so anyone can rebuild a full node, the raw event index, pindexer or an explorer from genesis without depending on any live node. Penumbra's checkpoint upgrades (and the 2026-09 restart) delete the previous CometBFT block store: per boundary you need the block archive of the ending era, the state at the boundary and the next genesis. Read history/README.md for the era model and the exact penumbra-reindexer commands (penumbrafi/reindexer); machine-readable list in history/manifest.json. Height 12,598,601 is the synthetic migration block (no CometBFT block).