diff --git a/packages/docs/pages/operators.mdx b/packages/docs/pages/operators.mdx
index 1c376b1c..24556cad 100644
--- a/packages/docs/pages/operators.mdx
+++ b/packages/docs/pages/operators.mdx
@@ -1,7 +1,7 @@
 # Operators Guide
 
-This guide is intended for operators of Namada full nodes. This includes both full nodes as well as validator nodes.
-The guide assumes that you have already installed the node and are familiar with the basics of running a node.
+This section of the guide is intended for operators of Namada full nodes and validator nodes.
+It assumes you have already completed the steps to [install Namada](./introduction/install.mdx).
 
 ## Table of Contents
 
diff --git a/packages/docs/pages/operators/ledger.mdx b/packages/docs/pages/operators/ledger.mdx
index 7d39464f..c919632a 100644
--- a/packages/docs/pages/operators/ledger.mdx
+++ b/packages/docs/pages/operators/ledger.mdx
@@ -1,41 +1,36 @@
 import { Callout } from 'nextra-theme-docs'
 
-# The Namada Ledger
+# Running a Full Node
+This section of the guide covers running a full (non-consensus) node. For information on running a validator node, see [Validator setup](./validators/validator-setup.mdx).  
 
-In order to make any interactions with the Namada blockchain through the Namada *client* `namadac`, the ledger must be running. 
+A step-by-step guide to setting up and running a full node can be found [here](./ledger/running-a-full-node.mdx).
 
-To start a local Namada ledger node, one can run:
+## The Namada ledger
+
+By starting the ledger process, your node will attempt to connect with network peers and sync to the latest block:
 
 ```shell copy
-namada ledger
+namada node ledger run
 ```
 
 <Callout>
 **Note**: You must have [joined a network](../networks.mdx) before you start the ledger. It throws an error if no network has been configured.
-
-The node will attempt to connect to the persistent validator nodes and other peers in the network, and synchronize to the latest block.
-
-By default, the ledger will store its configuration and state in your [base directory](./ledger/base-directory.mdx). 
-You can use the `--base-dir` CLI global argument or `BASE_DIR` environment variable to change it.
-
-Assuming you do not have a custom base_dir, you can export the BASE_DIR environment variable as follows:
-
-```shell copy
-export BASE_DIR=$(namadac utils default-base-dir)
-```
 </Callout>
 
-When the ledger is run for the first time, the MASP-parameters will be downloaded. This is essential for producing the zero knowledge proofs required to make shielded transactions.
+### MASP parameters
+When the ledger is run for the first time, the MASP-parameters will be downloaded. This is essential for producing the zero knowledge proofs required to make shielded transactions.  
+
+The default location of the MASP params is `$HOME/.masp-params`.
 
 ### The ledger wasm files
-The ledger will also download the genesis block, which contains the initial state of the blockchain.
+When running the `join-network` command, the ledger will also download the genesis files, which contain the initial state of the blockchain.
 The ledger also needs access to the built WASM files that are used in the genesis block. 
 These files are included in release and shouldn't be modified, otherwise your node will fail with a consensus error on the genesis block. 
 By default, these are expected to be in the `wasm` directory inside the chain directory that's in the base directory, i.e `$BASE_DIR/$CHAIN_ID/wasm`.
 The wasm directory can also be set with the `--wasm-dir` CLI global argument, `NAMADA_WASM_DIR` [environment variable](./ledger/env-vars.mdx) or the configuration file.
 
 ### Ledger configuration
-The ledger configuration is stored in `$BASE_DIR/$CHAIN_ID/config.toml` (with
+The [ledger configuration](./ledger/env-vars.mdx) is stored in `$BASE_DIR/$CHAIN_ID/config.toml` (with
 default `--base-dir`). It is created when you join the network. You can modify
 that file to change the configuration of your node. All values can also be set
 via [environment variables](./ledger/env-vars.mdx). 
diff --git a/packages/docs/pages/operators/ledger/_meta.json b/packages/docs/pages/operators/ledger/_meta.json
index 85388e4a..6f561925 100644
--- a/packages/docs/pages/operators/ledger/_meta.json
+++ b/packages/docs/pages/operators/ledger/_meta.json
@@ -1,6 +1,6 @@
 {
-    "env-vars": "Environment variables",
-    "running-a-full-node": "Setting up the full node",
+    "env-vars": "Node Configuration",
+    "running-a-full-node": "Full node step-by-step",
     "logging-config": "Logging configurations",
     "base-directory": "Base directory"
 }
\ No newline at end of file
diff --git a/packages/docs/pages/operators/ledger/base-directory.mdx b/packages/docs/pages/operators/ledger/base-directory.mdx
index 17696190..29097e5a 100644
--- a/packages/docs/pages/operators/ledger/base-directory.mdx
+++ b/packages/docs/pages/operators/ledger/base-directory.mdx
@@ -37,8 +37,21 @@ $HOME/Library/Application\ Support/Namada
 Within these folders, you should see the following files and folders:
 
 ```bash copy
-global-config.toml
-<some-chain-id>/
-<some-chain-id>.toml
-pre-genesis # If you are a pre-genesis validator
+.
+└── $BASE_DIR/
+    ├── global-config.toml
+    └── $CHAIN_ID/
+        ├── balances.toml
+        ├── chain.toml
+        ├── cometbft/
+        ├── config.toml
+        ├── db/
+        ├── parameters.toml
+        ├── tokens.toml
+        ├── transactions.toml
+        ├── tx_wasm_cache/
+        ├── validity_predicates.toml
+        ├── vp_wasm_cache/
+        ├── wallet.toml
+        └── wasm/
 ```
diff --git a/packages/docs/pages/operators/ledger/env-vars.mdx b/packages/docs/pages/operators/ledger/env-vars.mdx
index c781791d..74ff5a2f 100644
--- a/packages/docs/pages/operators/ledger/env-vars.mdx
+++ b/packages/docs/pages/operators/ledger/env-vars.mdx
@@ -1,9 +1,9 @@
 import { Callout } from 'nextra-theme-docs'
 import Expandable from "../../../components/Expandable";
 
-# Environment variables
+# Node Configuration
 
-By default, whenever the namada ledger is started, it will apply the confirguration found in the ledger configuration file.
+By default, whenever the namada ledger is started, it will apply the confirguration found in the ledger configuration file `$BASE_DIR/$CHAIN_ID/config.toml`.
 
 An example of a ledger configuration file is displayed below.
 
@@ -12,11 +12,11 @@ An example of a ledger configuration file is displayed below.
 wasm_dir = "wasm"
 
 [ledger]
-genesis_time = "2023-06-29T17:00:00+00:00"
-chain_id = "<namada-mainnet>"
+genesis_time = "2024-06-03T17:32:06+00:00"
+chain_id = "<chain-id>"
 
 [ledger.shell]
-base_dir = "/Users/fraccaman/Library/Application Support/Namada"
+base_dir = "/root/.local/share/namada/<chain-id>"
 storage_read_past_height_limit = 3600
 db_dir = "db"
 cometbft_dir = "cometbft"
@@ -24,24 +24,27 @@ tendermint_mode = "Full"
 
 [ledger.cometbft]
 proxy_app = "tcp://127.0.0.1:26658"
-moniker = "1337-leet-1337"
+moniker = "technodrome"
+fast_sync = true
 db_backend = "goleveldb"
 db_dir = "data"
 log_level = "info"
 log_format = "plain"
 genesis_file = "config/genesis.json"
-node_key_file = "config/node_key.json"
-abci = "socket"
-filter_peers = false
 priv_validator_key_file = "config/priv_validator_key.json"
 priv_validator_state_file = "data/priv_validator_state.json"
 priv_validator_laddr = ""
+node_key_file = "config/node_key.json"
+abci = "socket"
+filter_peers = false
 
 [ledger.cometbft.rpc]
 laddr = "tcp://127.0.0.1:26657"
 cors_allowed_origins = []
 cors_allowed_methods = ["HEAD", "GET", "POST"]
 cors_allowed_headers = ["Origin", "Accept", "Content-Type", "X-Requested-With", "X-Server-Time"]
+grpc_laddr = ""
+grpc_max_open_connections = 900
 unsafe = false
 max_open_connections = 900
 max_subscription_clients = 100
@@ -89,11 +92,6 @@ max_batch_bytes = 0
 
 [ledger.cometbft.consensus]
 wal_file = "data/cs.wal/wal"
-double_sign_check_height = 0
-create_empty_blocks = true
-create_empty_blocks_interval = "0ms"
-peer_gossip_sleep_duration = "100ms"
-peer_query_maj23_sleep_duration = "2000ms"
 timeout_propose = "3000ms"
 timeout_propose_delta = "500ms"
 timeout_prevote = "1000ms"
@@ -101,15 +99,24 @@ timeout_prevote_delta = "500ms"
 timeout_precommit = "1000ms"
 timeout_precommit_delta = "500ms"
 timeout_commit = "10000ms"
+double_sign_check_height = 0
+skip_timeout_commit = false
+create_empty_blocks = true
+create_empty_blocks_interval = "0ms"
+peer_gossip_sleep_duration = "100ms"
+peer_query_maj23_sleep_duration = "2000ms"
+
+[ledger.cometbft.storage]
+discard_abci_responses = false
 
 [ledger.cometbft.tx_index]
 indexer = "null"
 
 [ledger.cometbft.instrumentation]
-prometheus = false
+prometheus = true
 prometheus_listen_addr = ":26660"
 max_open_connections = 3
-namespace = "namada_tm"
+namespace = "tendermint"
 
 [ledger.cometbft.statesync]
 enable = false
@@ -119,13 +126,25 @@ trust_hash = ""
 trust_period = "168h0m0s"
 discovery_time = "15000ms"
 temp_dir = ""
+
+[ledger.cometbft.fastsync]
+version = "v0"
+
+[ledger.ethereum_bridge]
+mode = "RemoteEndpoint"
+oracle_rpc_endpoint = "http://127.0.0.1:8545"
+channel_buffer_size = 1000
 ```
 </Expandable>
 
-However, it is possible to override the configuration by setting environment variables.
-Any variable found in the config can be accessed through environment variables that are constructed in the below manner.
+<Callout>
+CometBFT has its own `config.toml` located inside the `cometbft` directory, however it should not be edited directly.
+</Callout>
 
 ### Constructing environment variables
+It is possible to override the configuration by setting environment variables; these will take precedence over any existing settings in `config.toml`.
+Any variable found in the config can be accessed through environment variables that are constructed in the below manner.  
+
 Names of the recognized environment variables are derived from the configuration keys by:
 
 1. Prepend `NAMADA_` to the key
diff --git a/packages/docs/pages/operators/ledger/running-a-full-node.mdx b/packages/docs/pages/operators/ledger/running-a-full-node.mdx
index c691d360..fc75480e 100644
--- a/packages/docs/pages/operators/ledger/running-a-full-node.mdx
+++ b/packages/docs/pages/operators/ledger/running-a-full-node.mdx
@@ -1,16 +1,41 @@
 import { Callout } from 'nextra-theme-docs'
+import { Steps } from 'nextra-theme-docs'
 
 # Full Node Setup
-Before starting a full node, the unique identifier of the `chain-id` will be needed, which will be released as soon as the genesis file is ready. 
+This section details the setup procedure for a full node. If you intend to run a validator node, please see the [Validator setup](../validators/validator-setup.mdx) guide instead.
 
+### Prerequisites
+- A machine that meets the [requirements](../hardware.mdx) for a full node
+- An associated public IPv4 address with port 26656 reachable from anywhere for P2P connections 
+- You have already [installed](../../introduction/install.mdx) Namada and its prerequisites
+- You know the unique `chain-id` identifier of the network you wish to join. The chain-id is publicly released once the genesis files have been prepared
+
+<Steps>
 ### Join the network
-Once the `chain-id` has been distributed, it is possible to join the network with the `CHAIN_ID`:
+Once the `chain-id` has been distributed, it is possible to [join the network](../networks.mdx) with the `CHAIN_ID`. This step will download the `.tar.gz` archive 
+containing the genesis files for the chain and initialize the node store in your [`BASE_DIR`](../ledger/base-directory.mdx).
 ```bash copy
   export CHAIN_ID="namada-mainnet" ## (replace with the actual chain-id)
-  NAMADA_NETWORK_CONFIGS_SERVER="https://github.com/anoma/namada-shielded-expedition/releases/download/shielded-expedition.88f17d1d14" namada client utils join-network --chain-id $CHAIN_ID
-  ```
+  namada client utils join-network --chain-id $CHAIN_ID --add-persistent-peers
+```
+<Callout>
+You can specify the location from which to download the genesis `.tar.gz` by exporting the environment variable `NAMADA_NETWORK_CONFIGS_SERVER` prior to running the `join-network` command. 
+This is useful for joining a community-run or local testnet.  
+
+By default, `join-network` will attempt to download the genesis files from `https://github.com/heliaxdev/anoma-network-config/releases/download/$CHAIN_ID`.
+</Callout>
+
+
+### Check/Update persistent peers
+To sync block data, your node will need to connect with existing peers on the network. Peer addresses can be provided in the node's [configuration](./env-vars.mdx) in 
+the field `persistent_peers`.  
+
+Your `persistent_peers` entry will need to contain at least one peer which is active and accepting incoming connections (the more, the better). If you used the 
+`--add-persistent-peers` flag during the join-network step, your persistent peers will be pre-populated with the addresses of the genesis validators. However, if you're [having trouble](../troubleshooting.mdx) 
+syncing, you may wish to check the Discord server for an updated list.
 
 ### Start your node and sync
+This command will start syncing your node with the network (an environment variable is being used here to set the [logging configuration](./logging-config.mdx)):
 ```bash copy
   CMT_LOG_LEVEL=p2p:none,pex:error namada node ledger run
 ```
@@ -25,18 +50,39 @@ NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namada n
 tail -f -n 20 logs-${TIMESTAMP}.txt ## (in another shell)
 ```
 
-### Running namada as a systemd service
+### Done!
+You should soon see messages similar to the following in your logs to indicate that your node has begun syncing blocks:
+```bash copy
+INFO namada_node::shell: Committed block hash: 0c56ebc5ae17ef503c675ad8a9b255e69258e7e4915f91e161f98d3b0040a0c1, height: 2650
+committed state                              module=state height=2650 num_txs=0 app_hash=0C56EBC5AE17EF503C675AD8A9B255E69258E7E4915F91E161F98D3B0040A0C1
+indexed block exents                         module=txindex height=2650
+```
+
+You can also easily check your node's last committed block with the following command:
+```
+# namadac block
+Last committed block height: 8612, time: 2024-06-04T18:17:06.136117438+00:00
+```
+By comparing it with the current height of the chain from a public source (such as a block explorer), you can monitor how your node is progressing.  
+
+If your node does not show indications of syncing, proceed to the [troubleshooting](../troubleshooting.mdx) section.
+</Steps>
+## Running the `namada ledger` as a systemd service
 <Callout type="info">
 The below script is a community contribution by Encipher88, and currently only works on Ubuntu machines.
 It has served useful for many validators.
 </Callout>
+
+For operators using Ubuntu, it is common to use the `systemd` service manager to run the ledger process in the background. Advantages of this method 
+include automatic restart upon crash and integrated logging.  
+
 The below assumes you have installed namada from source, with `make install`. It at least assumes the respective binaries are in `/usr/local/bin/`.
 
 ```bash copy
 which namada ## (should return /usr/local/bin/namada)
 ```
 
-The below makes a service file for systemd, which will run namada as a service. This is useful for running a node in the background, and also for auto-restarting the node if it crashes.
+We define a new process as a systemd service by creating a `unit file` in `/etc/systemd/system/`:
 ```bash copy
 sudo tee /etc/systemd/system/namadad.service > /dev/null <<EOF
 [Unit]
@@ -57,7 +103,7 @@ LimitNOFILE=65535
 WantedBy=multi-user.target
 EOF
 ```
-Enable the service with the below commands:
+Enable the service with the below commands. This sets the service to start automatically on system reboot.
 ```bash copy
 sudo systemctl daemon-reload
 sudo systemctl enable namadad
@@ -79,6 +125,4 @@ sudo systemctl restart namadad
 - Show node logs
 ```bash copy
 sudo journalctl -u namadad -f -o cat
-```
-
-
+```
\ No newline at end of file
diff --git a/packages/docs/pages/operators/validators.mdx b/packages/docs/pages/operators/validators.mdx
index 2e125c06..45d59562 100644
--- a/packages/docs/pages/operators/validators.mdx
+++ b/packages/docs/pages/operators/validators.mdx
@@ -1,19 +1,36 @@
 # Validators on Namada
 
-Namada is a proof-of-stake blockchain, which means that the validators are the ones who are responsible for both voting on state-transitions and proposing new blocks.
+Namada is a proof-of-stake blockchain, which means that the validators are the ones who are responsible for both voting on state-transitions and proposing new blocks.  
 
-### What is a genesis validator? How does it differ from a post-genesis Validator?
+Validating on Namada is permissionless; the only requirement is that a validator has sufficient [stake](./validators/staking.mdx) bonded to qualify for the active 
+consensus set.  
 
-A (pre-)genesis validator is a validator who is proposed to be a validator in the genesis block of the blockchain. If the genesis file is accepted by the network, then the (pre-)genesis validators are able to conduct validating activities on the blockchain, with the stake specified in the genesis file. These validators are setup with the correct consensus keys, which must match those specified in the genesis file.
+Active validators not meeting a liveness threshold (by signing a specified percentage of recent blocks) are subject to [jailing](./validators/jailing.mdx) for 
+inactivity. Validators who double-sign are subject to [cubic slashing](./validators/cubic-pos.mdx).
 
-A post-genesis validator, on the other hand, is a validating account which was created sometime after the genesis block. These accounts are initiated by the `init-validator` command.
+### Pre-genesis vs Post-genesis validators
+The procedure for initializing a validator differs on whether it's done before or after the genesis block of the network.
+- A pre-genesis validator is a validator who is proposed to be a validator in the genesis block of the blockchain. If the genesis file is accepted by the network, 
+then the pre-genesis validators are able to conduct validating activities on the blockchain, with the stake specified in the genesis file, 
+from the very first block. These validators are setup with the correct consensus keys, which must match those specified in the genesis file. The procedure for a 
+pre-genesis is slightly more involved because it involves generating and signing a pre-genesis transaction and coordinating offchain with the community for inclusion in the 
+proposed genesis block.
+
+- A post-genesis validator, on the other hand, is a validating account which was created sometime after the genesis block. The procedure for initializing a 
+post-genesis validator is to begin by [syncing a full node](./ledger/running-a-full-node.mdx) and then instantiate a validator account with the 
+`init-validator` command.
 
 ### How do I become a validator?
 
-#### Pre-requisites
-Validators require stake in the form of NAM in order to participate in the consensus process. The amount of stake required is specified in the genesis file. In order to become a validator, you must have at least the minimum amount of stake required.
+#### Hardware requirements
+A validator node must meet the [minimum hardware requirements](./hardware.mdx), which may be higher than those of a full node.
 
-In addition, the validator node must meet the [minimum hardware requirements](./hardware.mdx).
+#### Stake requirements
+Validators require stake in the form of NAM in order to participate in the consensus process. There are two stake thresholds to keep in mind: 
+- There are a limited number of validating slots in the active consensus set, as specified by the genesis file parameter `max_validator_slots`. For example, if
+`max_validator_slots = 100`, then you must rank within the top 100 active validators by stake to participate in consensus.
+- Additionally, a minimum stake amount is specified by the genesis file parameter `validator_stake_threshold`. You must have at least this amount of stake to 
+participate in consensus, regardless of whether the active set is full.
 
 #### Steps
 
@@ -22,9 +39,10 @@ See these steps for [setting up a genesis validator](./networks/genesis-flow/par
 See these steps for [setting up a post-genesis validator](./validators/validator-setup.mdx).
 
 
-## Outline
+## Contents
 The validator docs describe the process and actions available to validators on the Namada blockchain. The following is a list of the topics covered in the validator docs:
 - [Validator setup](./validators/validator-setup.mdx)
 - [Staking](./validators/staking.mdx)
 - [Validator actions](./validators/validator-actions.mdx)
-- [Jailing](./validators/jailing.mdx)
\ No newline at end of file
+- [Jailing](./validators/jailing.mdx)
+- [Cubic proof of stake](./validators/cubic-pos.mdx)
\ No newline at end of file
diff --git a/packages/docs/pages/operators/validators/_meta.json b/packages/docs/pages/operators/validators/_meta.json
index 789f0634..4763b468 100644
--- a/packages/docs/pages/operators/validators/_meta.json
+++ b/packages/docs/pages/operators/validators/_meta.json
@@ -1,7 +1,7 @@
 {
   "proof-of-stake": "Cubic proof of stake",
   "validator-setup": "Validator setup",
-  "staking": "Staking",
   "validator-actions": "Validator actions",
+  "staking": "Staking",
   "jailing": "Jailing"
 }
\ No newline at end of file
diff --git a/packages/docs/pages/operators/validators/proof-of-stake.mdx b/packages/docs/pages/operators/validators/proof-of-stake.mdx
new file mode 100644
index 00000000..edaa45a0
--- /dev/null
+++ b/packages/docs/pages/operators/validators/proof-of-stake.mdx
@@ -0,0 +1,3 @@
+# Proof-of-Stake
+
+A more technical overview of Namada's proof-of-stake design can be found in the [specs](https://specs.namada.net/modules/proof-of-stake).
\ No newline at end of file
diff --git a/packages/docs/pages/operators/validators/staking.mdx b/packages/docs/pages/operators/validators/staking.mdx
index 1c12f2f8..7b38857e 100644
--- a/packages/docs/pages/operators/validators/staking.mdx
+++ b/packages/docs/pages/operators/validators/staking.mdx
@@ -1,8 +1,14 @@
 import { Callout } from "nextra-theme-docs";
 
-# Bonding (Staking)
+# Staking (Bonding)
 
-We discuss two types of bonding: 
+For further details on how to bond, unbond and claim rewards, see the [Bonding and Proof-of-stake](../../users/delegators.mdx) 
+page in the Users section.  
+
+A validator typically has some combination of self-bonded stake and stake delegated to it by other token holders. The validator and delegators share the reward and 
+risk of slashing impact with each other.
+
+We discuss two types of bonding here: 
 1. [Non-self bonding](#non-self-bonding-delegating) (referred to as delegating in many other ecosystems, but not to be confused with governance delegation on Namada)
 2. [Self-bonding](#self-bonding)
 
@@ -110,6 +116,16 @@ namada client withdraw \
 
 Upon success, the withdrawn tokens will be credited back `aliace`'s account and debited from the PoS system.
 
+## Staking rewards
+
+Validators who are participating in the active consensus set generate staking rewards for proposing blocks and voting on finalizing blocks. Rewards are funded through 
+the continuous minting of new tokens (inflation). The amount of rewards paid out to validators is proportional to their 'voting power' (percentage of total bonded tokens staked with them) 
+and the chain's maximum annual inflation rate.  
+
+Validators pay out rewards to their delegators, minus the validator's commission rate.  
+
+The rewards mechanism provides economic incentive for both validators and delegators in securing the chain.
+
 ### Claiming rewards
 
 Validators and delegators that have bonded tokens accrue protocol rewards (for not misbehaving) and transaction fees. These rewards need to be claimed.
diff --git a/packages/docs/pages/operators/validators/validator-actions.mdx b/packages/docs/pages/operators/validators/validator-actions.mdx
index 223b4bf1..f5036b44 100644
--- a/packages/docs/pages/operators/validators/validator-actions.mdx
+++ b/packages/docs/pages/operators/validators/validator-actions.mdx
@@ -1,63 +1,87 @@
 import { Callout } from 'nextra-theme-docs'
 
-# Validator actions
+# Validator Actions
 
-## Commission-rate changes
+This section details commands that are commonly useful to validator operators.
 
-A validator can change their commission rate through the `change-commission` command:
+### Commission-rate changes
+
+A validator can change their commission rate through the `change-commission-rate` command:
 
 ```bash copy
 namadac change-commission-rate --validator <validator> --commission-rate <commission-rate>
 ```
 
-The `max-commission-rate-change` is unique to each validator and cannot be changed.
+<Callout>
+The maximum allowed change in commision rate per epoch is specified by the validator's `max-commission-rate-change` parameter.  
+
+The `max-commission-rate-change` can only be set on validator initialization; it cannot be changed later.
+</Callout>
+
+
+### Metadata changes
 
-## Metadata changes
+Each validator account has associated on-chain metadata; in addition to the (required) security email address, several optional fields (such as name, avatar, etc.) 
+can be provided. These are commonly displayed in applications such as block explorers or wallets to visually distinguish validators from one another.  
 
-A validator can change their metadata through the `change-metadata` command:
+A validator can update their metadata at any time with the `change-metadata` command:
 
 ```bash copy
-namadac change-metadata --validator <validator> --description <description> --email <email> --discord-handle <discord-handle> --website <website> --avatar <avatar>
+namadac change-metadata \
+  --validator <validator> \
+  --description <description> \
+  --email <email> \
+  --discord-handle <discord-handle> \
+  --website <website> \
+  --avatar <avatar>
 ```
-Apart from `--validator`, not all of the fields are required, but at least one of them is.
+Apart from `--validator`, not all of the fields are required (but at least one of them is).
 
-## Deactivation and reactivation
+### Deactivation and reactivation
 
-A validator can deactivate their validator (stop validating) through the `deactivate` command:
+You can deactivate your validator with the `deactivate` command:
 
 ```bash copy
 namadac deactivate-validator --validator <validator-address>
 ```
-This means that the validator will no longer participate in the consensus protocol. This becomes active at the end of the current epoch + `pipeline_length`. All bonds and delegations associated with the validator remain in tact. Delegators can still delegate to the validator, but the validator will not be able to participate in consensus until it is reactivated.
+Once deactivated, the validator will no longer participate in the consensus protocol. 
+This will take effect at the end of the current epoch + `pipeline_length`. All bonds and delegations associated with the validator remain intact. 
+Delegators can still delegate to the validator, but as the validator is inactive, it will not generate staking rewards until it is reactivated.
 
-To reactivate a validator, use the `reactivate` command:
+To reactivate your validator, use the `reactivate` command:
 
 ```bash copy
 namadac reactivate-validator --validator <validator-address>
 ```
 This will reactivate the validator at the end of the current epoch + `pipeline_length`.
 
-## Consensus Key Management
-
-The consensus key is crucial for validators as it is used to sign blocks and participate in the CometBFT consensus protocol. This key ensures that only authorized validators can propose and vote on blocks, contributing to the network's overall security.
-
 ### Changing the Consensus Key
-Validators are able to change their consensus key, allowing for enhanced security and key rotation practices. This process is essential for maintaining the security of the validator's operations and protecting against potential compromise.
+A validator's consensus key is used to sign blocks and participate in the CometBFT consensus protocol. 
+This key ensures that only authorized validators can propose and vote on blocks, contributing to the network's overall security. 
+It is crucial that all validators keep their consensus keys secret and secure.  
+
+Validators are able to change their consensus key, allowing for enhanced security and key rotation practices. 
+This process is essential for maintaining the security of the validator's operations and protecting against potential compromise.
 
-To change the consensus key, validators can use the following command:
+To change their consensus key, validators can use the following command:
 
 ```bash
 VALIDATOR_ADDRESS="<your-validator-address>"
 SIGNING_KEYS="<your-signing-key>"
-namada client change-consensus-key --validator $VALIDATOR_ADDRESS --signing-keys $SIGNING_KEYS
+namadac change-consensus-key --validator $VALIDATOR_ADDRESS --signing-keys $SIGNING_KEYS
 ```
 
 <Callout type="info" emoji="🔑">
-The new consensus key will be recorded in the `wallet.toml` file and is scheduled to become active 2 blocks before the pipeline offset from the epoch at the moment of activation. This timing ensures a smooth transition. It is essential for validators to plan the key rotation accordingly to ensure continuous participation in block validation without interruption.
+The new consensus key will be recorded in the `wallet.toml` file and is scheduled to become active 2 blocks before the pipeline offset from the epoch at the moment of 
+activation. This timing ensures a smooth transition.  
+
+After the transition period, validators must replace the current `priv_validator_key.json` with the newly generated key. 
+This step is crucial for activating the new consensus key for block signing.  
+
+It is essential for validators to plan the key rotation accordingly to ensure continuous participation in block validation with minimal interruption.
 </Callout>
 
 ### Generating a New Consensus Key
-After the transition period, validators must replace the current `priv_validator_key.json` with the newly generated key. This step is crucial for activating the new consensus key for block signing.
 
 To generate a new consensus key, use the following command:
 
@@ -65,10 +89,35 @@ To generate a new consensus key, use the following command:
 namadaw convert --alias <new-consensus-key>
 ```
 
-This command will create a new consensus key, which validators should securely store and use to replace the existing `priv_validator_key.json` file. It is critical for validators to perform this step correctly.
+This command will create a new consensus key, which validators should securely store and use to replace the existing `priv_validator_key.json` file. 
+It is critical for validators to perform this step correctly.
 
-After updating the consensus key, validators can find out their new validator address with the following command:
+After updating the consensus key, validators can find their new validator address with the following command:
 
 ```bash
 namadaw find --alias <new-consensus-key>
 ```
+
+### Withdrawing rewards
+When a delegator bonds tokens to an active validator, [staking rewards](./staking.mdx) accrue in the form of the native token. These rewards need to be claimed 
+before they are credited to the delegator's account. The same holds true for when the validator has self-bonded. Rewards can be withdrawn with the command:
+
+```bash
+namadac claim-rewards --validator <validator>
+```
+
+### Submitting an unjail transaction
+See the section on [jailing](./jailing.mdx) for further info.
+
+### Voting on governance
+An important function of validators is active participation in governance. It is particularly important for validators to vote on governance proposals because 
+they vote on behalf of not only their self-bonded stake, but any delegated stake which has not submitted a vote of their own.  
+
+In other words, a validator's vote determines the 'default' vote for all its delegators. A delegator wishing to vote differently can override this by submitting a 
+vote transaction of their own, which they may do at any time before the end of the voting period (including after the validator has voted).
+
+<Callout type='warning'>
+Validators have a shortened voting window -- they can only cast votes during the first two-thirds of a proposal's voting period.  
+
+This is to allow delegators time to check how their delegatee validator has voted, in case they wish to vote differently.
+</Callout>
\ No newline at end of file
diff --git a/packages/docs/pages/operators/validators/validator-setup.mdx b/packages/docs/pages/operators/validators/validator-setup.mdx
index 37a801b4..7f6b2f72 100644
--- a/packages/docs/pages/operators/validators/validator-setup.mdx
+++ b/packages/docs/pages/operators/validators/validator-setup.mdx
@@ -1,15 +1,23 @@
 import { Callout } from 'nextra-theme-docs'
+import { Steps } from 'nextra-theme-docs'
 
-# Setting up a validator account
+# Setting up a Validator Node
 
-## Genesis validators
-
-A genesis validator is one which is a validator right from the first block of the chain, i.e., at genesis. The details of genesis validators are hardcoded into the genesis file that is distributed to all users who want to interact with a chain.
+This section details how to set up and run a validator node. It is divided into two sections -- pre-genesis validators and post-genesis validators.
 
 ### Prerequisites
 
-- a machine that meets the [requirements](../hardware.mdx) for running a validator node
-- an associated public IPv4 address with ports 26656 reachable from anywhere for P2P connections
+- A machine that meets the [requirements](../hardware.mdx) for running a validator node
+- An associated public static IPv4 address with ports 26656 reachable from anywhere for P2P connections
+- You have [installed](../../introduction/install.mdx) Namada and its dependencies
+
+
+## Pre-genesis validators
+
+A pre-genesis validator is one which begins validating right from the first block of the chain, i.e., at genesis. 
+The details of genesis validators are hardcoded into the genesis files that is distributed to all users who want to interact with a chain. Becoming a pre-genesis 
+validator involves generating and signing a genesis transaction for inclusion in the genesis files; upon network launch, the validator can participate in 
+consensus assuming they possess the expected consensus keys.
 
 ### Method
 
@@ -18,106 +26,61 @@ The method for setting up a genesis validator is described under the [pre-genesi
 
 ## Post-genesis validators
 
-Post-genesis validators are validators that become initialized after the genesis block. This is the most common way of becoming a validator, and is the method described in this section.
+Post-genesis validators are validators that become initialized after the genesis block; this is the most common way of becoming a validator.
 
-<Callout type="info" emoji="🤡">
-Note the use  of the placeholder `aliace` for the alias parameter. This is a completely configurable parameter, and should just refer to the alias of the key/address generated.
+### Method
+<Steps>
+### Sync a full node
+Before initializing your validator account, you must first [set up a full node](../ledger/running-a-full-node.mdx) and sync it with 
+the head of the chain.
+
+### Initialize a new validator account
+A validator account can be initialized from an [established account](../../users/transparent-accounts/established-accounts.mdx) by submitting an on-chain transaction. 
+`namadac init-validator` will create a new established account and convert it to a validator account in a single command.
+<Callout>
+You can also use the command `namadac become-validator` to convert an existing established account into a validator account, instead of creating a new one.
 </Callout>
 
-### Initialising a new validator account
-
-The user must first generate a key pair for their validator account.
-
-```bash copy
-KEY_ALIAS="aliace"
-namada wallet gen --alias $KEY_ALIAS
-```
-
-Now choose a name for your validator:
-
-```bash copy
-export VALIDATOR_ALIAS="<your-validator-name>"
-export EMAIL="<your-validator-email-for-communication>"
-```
-
-A validator account requires additional keys compared to a user account, so start by initialising a validator account:
-
-```bash copy
-namada client init-validator \
-  --alias $VALIDATOR_ALIAS \
-  --account-keys $KEY_ALIAS \
-  --signing-keys $KEY_ALIAS \
-  --commission-rate <enter-your-commission-rate> \
-  --max-commission-rate-change <enter-decimal-rate> \
-  --email $EMAIL
-```
-
-It is also possible to convert an established account to a validator account:
-
+The required arguments to initialize a validator are:
 ```bash copy
-namada client become-validator \
-  --address $ESTABLISHED_ACCOUNT_ADDRESS \
-  --signing-keys $KEY_ALIAS \
-  --commission-rate <enter-your-commission-rate> \
-  --max-commission-rate-change <enter-decimal-rate> \
-  --email $EMAIL
+namadac init-validator \
+  --commission-rate 0.05 \
+  --max-commission-rate-change 0.01 \
+  --email <your-security-email> \
+  --alias <account-wallet-alias>
 ```
+__Note:__
+- `commission-rate` is the percentage of staking rewards kept by the validator for all tokens bonded to it. A validator can change its commission rate 
+by no more than `max-commission-rate-change` per epoch. The `max-commission-rate-change` parameter cannot be changed after validator initialization.
+Typical values are `0.05` (5%) and `0.01` (1%) respectively but validator are free to choose otherwise.
+- `email` should be set to a dedicated infra/security email account that you monitor regularly. It may be used to notify validators of urgent security issues, patches 
+or chain upgrades.
+- `alias` is used to reference your account by name in your wallet; it does not appear on-chain.
 
-<Callout type="info">
-A validator’s commission rate is the percentage of the rewards that the validator keeps from its delegators. A validator can change its commission rate with a transaction. The `max-commission-rate-change` is the maximum allowable change in a validator’s commission rate from one epoch to the next. This parameter is set uniquely for a given validator upon their creation and cannot be changed once the validator is initialized.
-</Callout>
-
-The validator account will now have the same alias as the established account.
-
-When initialising a validator account, it is also mandatory to specify both the `commission-rate` charged by the validator for delegation rewards (in decimal format) as well as the `maximum-commission-rate-change` per epoch in the `commission-rate`. Both are expressed as a decimal between 0 and 1. The standard for mainnet will be set by social consensus, but for testnets, the standard has been `0.01` and `0.05`, respectively. 
-
-This command will generate the keys required for running a validator:
-
-- Consensus key, which is used in [signing blocks in CometBFT](https://docs.cometbft.com/v0.37/core/validators#validator-keys).
-- Validator account key for signing transactions on the validator account, such as token self-bonding, unbonding and withdrawal, validator keys, validity predicate, state and metadata updates.
+You can optionally provide any of the following additional information to identify your validator on-chain (frequently displayed in block explorers):
+- `name`: An on-chain display name (similar to 'moniker' in Cosmos SDK chains)
+- `avatar`: A url to your validator logo
+- `discord-handle`: Your Discord handle
+- `website`: A url to your validator website
+- `description`: A 1-2 sentence description, tagline or slogan
 
-Then, it submits a transaction to the ledger that generates the new validator account with established address, which can be used to receive new delegations.
+### Restart your node
+You must restart your node after initializing your validator; your node will be unable to sign any future blocks until you do so.
 
-The keys and the alias of the address will be saved in your wallet. 
+### Bond stake
+A validator will only participate in consensus if the amount of tokens bonded meets both requirements:  
+- Greater than the chain's `validator_stake_threshold` parameter, and  
+- Enough to rank it among the top `X` active validators as defined by the `max_validator_slots` parameter. For example, if `max_validator_slots = 100`, then you must rank within the top 100 active validators by stake to participate in consensus.
 
-### Start validating
+Validators can bond tokens to themselves (self-bond) and solicit bonds from other parties (delegation); see the section on [staking](./staking.mdx). 
+Note that the balance of NAM tokens that is in your validator account does not count towards your validator's stake and voting power.
 
-<Callout type="warning" emoji="🛎️">
-**IMPORTANT**
+### Await the `pipeline_length`
+The chain's `pipeline_length` parameter defines the number of epochs that must pass before actions such as bonding, unbonding, or unjailing take effect. Therefore, 
+after bonding sufficient stake to place in the active consensus set, you must wait an additional `pipeline_length` number of epochs before your validator is included in the consensus set.
 
-The local ledger node will also be setup to run this validator, you just have to shut it down with e.g. `Ctrl + C`, then start it again with the same command as before.
-</Callout>
-
-```shell copy
-namadan ledger run
-# or for more verbose output:
-# NAMADA_LOG=info CMT_LOG_LEVEL=p2p:none,pex:error NAMADA_CMT_STDOUT=true namadan ledger run
-```
 
-The ledger will then use the validator consensus key to sign blocks, should your validator account acquire enough voting power to be included in the active validator set. The size of the active validator set is limited to `128` (the limit is set by the PoS `max_validator_slots` parameter).
+</Steps>
 
-Note that the balance of NAM tokens that is in your validator account does not count towards your validator's stake and voting power:
-
-```shell copy
-namada client balance --owner my-validator --token NAM
-```
+## Validator account keys
 
-That is, the balance of your account's address is a regular liquid balance that you can transfer using your validator account key, depending on the rules of the validator account's validity predicate. The default validity predicate allows you to transfer it with a signed transaction and/or stake it in the PoS system. Therefore, in order to increase the voting power of your validator, you need to accrue [some stake](./staking.mdx).
-
-The final thing that needs to be done is to bond some stake to the validator account. This can be done using the `bond` command:
-
-```shell copy
-namadac bond --amount <amount> --validator <validator-alias>
-```
-
-### Querying a validator's tendermint address
-
-If the validator account has been set up correctly and has bonded stake, it will be possible to query it using the `find-validator` command:
-
-```shell copy
-namada client find-validator --validator <validator-address>
-```
-
-<Callout type="info">
-It is important to note that the validator **address** is required, not the alias. The address can be found using the wallet command `namadaw list --addr | grep "your-validator-alias".`
-</Callout>