sei-protocol · monty-sei · Aug 10, 2026
diff --git a/node/index.mdx b/node/index.mdx
@@ -6,7 +6,7 @@
 ---
 
 import { VersionTable } from '/snippets/version-table.jsx';
-import { RandomPeers } from '/snippets/random-peers.jsx';
+import { Seeds } from '/snippets/seeds.jsx';
 
 **Power the Sei Network Infrastructure**
 
@@ -19,13 +19,13 @@
  <Card horizontal title="Archive Nodes" icon="database" />
 </CardGroup>

 ## Network Versions

 <VersionTable />

 _Live binary versions, genesis, and seed peers — see the [technical reference](/node/technical-reference)._

 ## Hardware Requirements

 | Component | Required                                               |
 | --------- | ------------------------------------------------------ |
@@ -34,7 +34,7 @@
 | Storage   | 2 TB NVMe SSD (high IOPS required)                     |
 | Network   | 2 Gbps with low latency                                |

 ## Installation & Setup Steps

 <Steps>

@@ -47,13 +47,13 @@
 sudo apt update && sudo apt upgrade -y
 ```

 ###### 2. Install Essential Packages

 ```bash
 sudo apt install make gcc git jq chrony curl lz4 wget tar build-essential -y
 ```

 ###### 3. Synchronize System Time

 ```bash
 sudo timedatectl set-timezone UTC
@@ -61,11 +61,11 @@
 timedatectl
 ```

 ##### Install Go

 Suggested Version: Go 1.24.x (required for seid v6.3+)

 ###### Installation Steps

 ```bash
 # Check for existing Go installation
@@ -129,35 +129,51 @@
  For more information see [here](https://pkg.go.dev/cmd/go#hdr-GOPATH_environment_variable).
 </Info>

 ##### Initialize Chain Files
 
 <Info>Default init mode is **full** (RPC/P2P bind to all interfaces). For **validator** or **seed** nodes, use `--mode validator` or `--mode seed` so RPC and P2P bind to localhost only. See the [Validator Operations Guide](/node/validators) for the full validator init example.</Info>
 
-Peers can be found here -
-
-- mainnet (pacific-1):
-
-<RandomPeers network="mainnet" format="bash" />
-
-- testnet (atlantic-2):
-
-<RandomPeers network="testnet" format="bash" />
-
 ```bash
 # Initialize node (default mode is full: RPC/P2P bind to all interfaces)
 # For validator nodes, use: seid init <your-moniker> --chain-id <chain-id> --mode validator
 seid init <your-moniker> --chain-id <chain-id>
 
 # Genesis is written automatically for known networks (mainnet and testnets); no download needed.
+# bootstrap-peers is also populated automatically with the Sei Labs seeds — no
+# manual peer list needed. See "Peer discovery" below.
+```
+
+##### Peer discovery
+
+`seid init` writes the Sei Labs seed nodes into `bootstrap-peers` for you, so a
+fresh node finds peers with no further configuration. The seeds run in three
+regions per network, and they gossip the rest of the network to you over PEX —
+you do not need to maintain a peer list.
 
-# Configure peers in config.toml.
-PEERS="<comma-separated-peer-list>"
+<Info>
+  Seeds belong in `bootstrap-peers`, not `persistent-peers`. Bootstrap peers seed
+  your address book and may then be dropped once you have real peers;
+  `persistent-peers` holds connections open indefinitely, which is only
+  appropriate for nodes you operate yourself.
+</Info>
+
+If you need to set them by hand — an existing node initialised before seeds
+shipped, or a home you did not create with `seid init` — the values are:
+
+- mainnet (pacific-1):
 
-#Set persistent peers in config.toml
-sed -i 's/persistent-peers = .*/persistent-peers = "'$PEERS'"/' ~/.sei/config/config.toml
+<Seeds network="mainnet" format="toml" />
+
+- testnet (atlantic-2):
+
+<Seeds network="testnet" format="toml" />
+
+```bash
+# Only needed if bootstrap-peers is empty (e.g. a node initialised before seeds shipped)
+sed -i 's/bootstrap-peers = .*/bootstrap-peers = "<comma-separated-seed-list>"/' ~/.sei/config/config.toml
 ```
 
 ##### Configure App Settings

 ```bash
 # Set minimum gas price (recommended; helps prevent spam transactions)
@@ -187,7 +203,7 @@

 <Accordion title="Advanced Configuration">

 #### Archive Node Setup

 An archive node maintains the complete historical record of the chain. This requires disabling state sync and starting with a pre-existing database using a "snapshot".

@@ -201,7 +217,7 @@

 **2. Configure Archive Node Peers** — To sync from the height your snapshot was created at, you need peers retaining a large amount of historical blocks. The node will require specific peers during initial sync, which can be changed at a later time.

 #### Mempool Configuration

 For optimal transaction handling and resource management, it is recommended to update the mempool settings in your `config.toml` file.

@@ -289,7 +305,7 @@
 sudo systemctl start seid
 ```

 ##### Monitoring & Troubleshooting

 Check your node's status with these commands:

@@ -325,9 +341,9 @@

 [View Complete Node Setup Guide](/node/node-operators)

 ## Node Resources

 ### Node Setup

 <CardGroup cols={3}>
  <Card horizontal title="Node Operations Guide" icon="server" href="/node/node-operators">
@@ -341,7 +357,7 @@
  </Card>
 </CardGroup>

 ### Advanced Operations

 <CardGroup cols={3}>
  <Card horizontal title="Configuration & Monitoring" icon="gauge-simple-high" href="/node/advanced-config-monitoring">

diff --git a/node/technical-reference.mdx b/node/technical-reference.mdx
@@ -9,13 +9,13 @@
 troubleshooting procedures. For API documentation, please refer to our API
 Documentation section.

 ## Command Line Interface Reference

 The `seid` binary provides extensive functionality for managing your Sei node.
 Understanding these commands is essential for effective node operation and
 troubleshooting.

 ### Node Management Commands

 These commands help you control and monitor your node's operation:

@@ -37,7 +37,7 @@
 seid query node info
 ```

 ### Key Management

 Proper key management is crucial for security. These commands help you manage
 your keys effectively:
@@ -62,7 +62,7 @@
 seid keys show <name> -a
 ```

 ### Transaction Commands

 These commands allow you to interact with the blockchain:

@@ -80,12 +80,12 @@
 seid tx staking edit-validator [flags] --from <validator-key>
 ```

 ## Configuration Parameters

 Understanding configuration parameters is essential for optimizing your node's
 performance and security.

 ### App.toml Parameters

 The app.toml file controls application-specific settings:

@@ -132,15 +132,19 @@
 [p2p]
 laddr = "tcp://0.0.0.0:26656"
 external-address = ""
-seeds = ""
-persistent_peers = ""
+# Populated automatically by `seid init` on known networks with the Sei Labs seeds.
+bootstrap-peers = ""
+persistent-peers = ""
+blocksync-peers = ""
 upnp = false
-max_num_inbound_peers = 40
-max_num_outbound_peers = 10
-allowed_pools = ""
-max_packet_msg_payload_size = 10240
-handshake_timeout = "20s"
-dial_timeout = "3s"
+max-connections = 64
+max-incoming-connection-attempts = 100
+pex = true
+private-peer-ids = ""
+allow-duplicate-ip = false
+max-packet-msg-payload-size = 1400
+handshake-timeout = "20s"
+dial-timeout = "3s"
 
 # RPC Configuration
 [rpc]
@@ -166,11 +170,11 @@

 </Accordion>

 ## Network Parameters

 Understanding network parameters helps you operate your node effectively.

 ### Chain Parameters

 These parameters define the network's behavior:

@@ -193,7 +197,7 @@
  These values reflect the current on-chain parameters. Query them directly with `seid query staking params` and `seid query slashing params` for the source of truth. Per-validator settings (e.g. commission rate, commission max change rate) are configured per validator and are not chain-level parameters.
 </Info>

 ## File Locations

 Understanding the purpose and location of important files helps with maintenance
 and troubleshooting:

diff --git a/node/troubleshooting.mdx b/node/troubleshooting.mdx
@@ -4,16 +4,16 @@
 keywords: ['sei node', 'blockchain node', 'node configuration', 'bug', 'troubleshooting']
 ---
 
-import { RandomPeers } from '/snippets/random-peers.jsx';
+import { Seeds } from '/snippets/seeds.jsx';
 
 Understanding common errors and their solutions helps maintain a healthy node
 operation.

 ## Common Error Codes

 Here are the most frequent errors you might encounter and their solutions:

 ### Consensus Errors

 When you encounter consensus errors, quick and appropriate action is essential:

@@ -35,7 +35,7 @@
 Action: Check validator operation on other machines
 ```

 ### Network Errors

 Network errors can prevent your node from participating in consensus:

@@ -55,7 +55,7 @@
 - curl localhost:26657/net_info
 ```

 ### Database Errors

 Database corruption can require immediate attention:

@@ -67,7 +67,7 @@
  - cp -r backup/data $HOME/.sei/
 ```

 ### Diagnostic Commands

 These commands help you investigate issues and monitor your node:

@@ -85,7 +85,7 @@
 top -p $(pgrep seid)
 ```

 ## AppHash Mismatch Errors

 If you encounter an AppHash mismatch, you'll need to capture the state for comparison with a known good version:

@@ -104,7 +104,7 @@

 Always include the app hash, commit hash, and block height from your logs when reporting issues.

 ### Identifying AppHash Errors

 AppHash errors typically appear in logs as:

@@ -132,7 +132,7 @@

 4. **Restart the node and monitor logs for continued errors**

 ### Peer Connection Issues as AppHash Red Herrings

 **Important Note:** Peer connection failures are often symptoms of underlying AppHash errors, not the root cause.

@@ -168,7 +168,7 @@

 This approach can save hours of debugging time by addressing the root cause rather than symptoms.

 ### Peer Connection and Handshake Issues

 **Identifying Peer Issues:**

@@ -189,9 +189,15 @@
 
 **Resolution Steps:**
 
-1. **Update peer configurations** with current node IDs:
+1. **Point the node at the Sei Labs seeds.** They hold stable identities behind
+   stable DNS, so unlike a hand-maintained peer list they do not go stale:
 
-   <RandomPeers network="mainnet" format="toml" />
+   <Seeds network="mainnet" format="toml" />
+
+   The first error above — `expected to connect with peer X, got Y` — means the
+   node ID paired with that address is wrong. The handshake pins the ID, so a
+   mismatched pair is rejected outright rather than degraded. Replace the entry
+   rather than retrying it.
 
 2. **Verify network connectivity:**
 
@@ -209,7 +215,7 @@
   curl http://localhost:26657/lag_status | jq .
   ```

 ### Sync Performance Issues

 **Identifying Sync Problems:**

@@ -253,7 +259,7 @@
 - Repeated timeout errors in logs
 - Mempool size consistently reaching limits

 ## Crash and Panic Debugging

 For crashes, panics, or nil pointer exceptions:

@@ -261,7 +267,7 @@
 - Or collect 15 minutes of log data, whichever provides more context
 - Include the full stack trace if available

 ### Logging Configuration

 Proper logging configuration is essential for debugging and monitoring:

@@ -341,7 +347,7 @@
     rm -rf $HOME/.sei/data/snapshots/*
     ```

 ## Node Rollback

 To rollback a node from an AppHashed state, you need to stop the node first.
 Do this in your preferred way.

diff --git a/node/validators.mdx b/node/validators.mdx
@@ -6,7 +6,7 @@
 ---
 This document covers the complete lifecycle of a validator node, from initial setup through ongoing operations and maintenance. Understanding these concepts is crucial for maintaining a reliable and secure validator operation.

 ## Understanding Validator Responsibilities

 A validator in the Sei network serves several critical functions. As a validator, you are responsible for:

@@ -15,7 +15,7 @@
 - Managing delegator relationships and maintaining transparent operations
 - Participating in governance and network upgrades

 ## Initial Setup

 ### Initialize node

@@ -27,7 +27,7 @@

 The default init mode is **full**, which binds RPC and P2P to all interfaces (`0.0.0.0`). For validator (and seed) nodes, use `--mode validator` or `--mode seed` so that RPC and P2P listen on localhost only. Genesis is written automatically for known networks; no separate download is required.

 ### Key Management

 The security of your validator begins with proper key management. Your validator requires several distinct keys:

@@ -41,7 +41,7 @@

 These keys serve different purposes and should be managed with appropriate security measures. The consensus key, stored in `priv_validator_key.json`, is particularly critical as it's used to sign blocks and could result in slashing if compromised or mishandled.

 ### Hardware Security Module (HSM) Integration

 For production validators, using an HSM is strongly recommended to protect your consensus key. Here's how to configure an HSM with your validator:

@@ -53,7 +53,7 @@
 # Configure YubiHSM2
 yubihsm-connector -d

 # Generate key in HSM
 yubihsm-shell

 # Configure seid to use HSM
@@ -98,13 +98,13 @@
 - `commission-max-rate`: An upper limit that can never be exceeded, setting a permanent cap on your commission
 - `commission-max-change-rate`: Maximum daily commission change, limiting how quickly you can adjust rates

 ## Monitoring and Alerting

 **Please refer to the [Advanced Operations](/node/advanced-config-monitoring) section for details around monitoring + alerting for your validator, price feeder and other nodes.**

 ## Security Practices

 ### Network Security

 Validators may choose to implement a sentry node architecture to protect the block signing node (the validator). This setup helps prevent DDoS attacks on your validator node by creating a layer of defensive proxies:

@@ -112,21 +112,19 @@
 # Validator node config.toml
 [p2p]
 pex = false
-persistent_peers = "sentry_node_id@sentry_node_ip:26656"
-private_peer_ids = ""
-addr_book_strict = false
+persistent-peers = "sentry_node_id@sentry_node_ip:26656"
+private-peer-ids = ""
 
 # Sentry node config.toml
 [p2p]
 pex = true
-persistent_peers = "validator_node_id@ip:port"
-private_peer_ids = "validator_node_id"
-addr_book_strict = true
+persistent-peers = "validator_node_id@ip:port"
+private-peer-ids = "validator_node_id"
 #optional
-unconditional_peer_ids = "validator_node_id"
+unconditional-peer-ids = "validator_node_id"
 ```
 
 ### Key Management Practices

 Implement secure key backup procedures. Remember to choose the storage media carefully! Mechanical / flash based storage can fail unexpectedly, and cloud storage should **never** be used.

@@ -151,7 +149,7 @@
    gpg --symmetric --cipher-algo AES256 \
    -o $BACKUP_DIR/keyring_$DATE.tar.gz.gpg

 # Create SHA256 checksums
 sha256sum $BACKUP_DIR/*.gpg > $BACKUP_DIR/checksums_$DATE.txt
 ```

@@ -183,13 +181,13 @@
 sudo systemctl start seid
 ```

 ### Emergency Procedures

 Create and maintain an emergency response plan for various scenarios:

 #### Consult with your fellow validators or a member of the Sei Labs or Foundation team directly for advice

 ## Governance Participation

 As a validator, active participation in governance is required. Governance is the primary tool with which adjustments to various chain parameters are made.
 Another critical role for validators is to review, and ultimately approve or reject proposed software upgrades to the network.
@@ -210,9 +208,9 @@
    --gas-prices 0.02usei
 ```

 ## Recovery Procedures

 ### Critical Warning: Double-Signing Prevention

 <Danger>Double-signing is a severe violation that results in permanent validator tombstoning (irreversible jailing).</Danger>

@@ -228,7 +226,7 @@
 2. If the original validator cannot be recovered, verify it is offline and powered down
 3. Only then proceed with key migration to a new machine

 ### Validator Recovery

 When you need to recover your validator on a new machine, follow these steps carefully:


diff --git a/snippets/random-peers.jsx b/snippets/random-peers.jsx