sei-protocol · seidroid · Aug 20, 2026 · Aug 20, 2026
diff --git a/node/index.mdx b/node/index.mdx
@@ -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,7 +61,7 @@
 timedatectl
 ```

 ##### Install Go

 You need Go only if you build `seid` from source. The prebuilt binary and Docker
 install paths in the next step do not require it.
@@ -71,7 +71,7 @@
 (e.g. [`v6.6.1`](https://github.com/sei-protocol/sei-chain/blob/v6.6.1/go.mod)) for its
 exact requirement.

 ###### Installation Steps

 ```bash
 # Check for existing Go installations — more than one entry means another copy
@@ -206,7 +206,7 @@
  </Tab>
 </Tabs>

 ##### 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>

@@ -222,19 +222,26 @@
 
 ```bash
 # Initialize node (default mode is full: RPC/P2P bind to all interfaces)
+# --chain-id is required, e.g. pacific-1 or atlantic-2
 # 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.
 
-# Configure peers in config.toml.
+# For known public networks (pacific-1, atlantic-2), seid init also pre-populates
+# bootstrap-peers in config.toml with the built-in Sei Labs seed nodes, so peer
+# discovery works with no manual configuration. Devnets (arctic-1) and
+# unknown/private chains get none, and any bootstrap-peers value you already set
+# is never overwritten.
+
+# Optionally configure additional persistent peers in config.toml.
 PEERS="<comma-separated-peer-list>"
 
 #Set persistent peers in config.toml
 sed -i 's/persistent-peers = .*/persistent-peers = "'$PEERS'"/' ~/.sei/config/config.toml
 ```

 ##### Configure App Settings

 ```bash
 # Set minimum gas price (recommended; helps prevent spam transactions)
@@ -264,7 +271,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".

@@ -278,7 +285,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.

@@ -372,7 +379,7 @@
 sudo systemctl start seid
 ```

 ##### Monitoring & Troubleshooting

 Check your node's status with these commands:

@@ -408,9 +415,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">
@@ -424,7 +431,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,11 +37,11 @@
 seid query node info
 ```

 ### seidb Tooling Commands

 The `seidb` binary provides low-level tooling for inspecting and maintaining a node's on-disk state.

 #### Reporting FlatKV EVM Migration Status

 The `migrate-evm-status` subcommand reads the on-disk FlatKV EVM migration state from a FlatKV data directory and prints a JSON summary. It is primarily intended for integration and operator tooling that polls each validator to determine whether the FlatKV EVM migration has completed, without needing a custom RPC handler or having to grep through node logs.

@@ -67,7 +67,7 @@
 - `boundary_hex` — hex-encoded migration boundary cursor, included only when a boundary is present.
 - `version_raw_hex` — hex-encoded raw migration-version bytes, included only when a migration version is present.

 #### Comparing EVM State Across Backends

 The `evm-logical-digest` subcommand computes a backend-independent digest of the EVM logical state (the account, code, and storage buckets) so that a memIAVL node and a FlatKV node can be compared at the same chain height. Because a freshly migrated FlatKV node stamps a per-key `blockHeight` into each value that differs from the memIAVL leaf versions, a raw byte-for-byte digest would diverge even when the underlying EVM state is identical. This command strips the serialization-version and `blockHeight` header on both sides and digests only the height-independent logical payload (storage word, bytecode, or balance+nonce+codehash), producing a comparable `FINAL_DIGEST` per backend.

@@ -107,7 +107,7 @@
 - `--details` — inspect list mode: include backend-specific version metadata.
 - `--find-hash` — optional 32-byte hex per-entry hash to hunt for. When two `bucket_digest` values differ by exactly one entry, their XOR is that entry's hash; this prints every matching entry so a single diverging row can be located.

 ### Autobahn (GigaRouter) Config Generation

 When running with the Autobahn (GigaRouter) networking layer, you can generate the Autobahn JSON config from a set of node directories. Each directory must contain `validator_pubkey.txt`, `node_pubkey.txt`, `autobahn_address.txt`, and `evmrpc_url.txt`. Unlike the key files, `evmrpc_url.txt` is not written automatically — operators must create it by hand with the node's EVM RPC URL, and the command fails with an error if it is missing. The `mempool_size` field is no longer part of `autobahn.json`; remove it from existing config files.

@@ -138,7 +138,7 @@

 The generated `autobahn.json` file describes the validator set along with transaction limits, block interval, view timeout, and dial interval; gas limits are not part of this file and come from the genesis block parameters instead. To have a node consume it, reference the file from `config.toml` using the `autobahn-config-file` key.

 #### Giga Mode Behavior and Per-Block Limits

 When a node is started in Giga mode — that is, when `autobahn-config-file` is set in `config.toml` — the block production and networking behavior differs significantly from standard Tendermint consensus:

@@ -156,7 +156,7 @@

 When filling a block the producer seals the current block and starts a new one as soon as adding the next transaction would exceed any of the transaction-count, byte, wanted-gas, or estimated-gas limits.

 #### Autobahn Committee and Network Message Limits

 Beyond the per-block payload limits, Giga mode enforces structural limits on the validator committee and on incoming consensus network messages:

@@ -175,7 +175,7 @@
  Because Giga replaces the CometBFT mempool, the `unsafe_flush_mempool` RPC endpoint is not supported under Giga and returns `unsafe_flush_mempool is not supported with autobahn mempool`.
 </Note>

 ### Key Management

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

 ### Transaction Commands

 These commands allow you to interact with the blockchain:

@@ -218,12 +218,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:

@@ -264,6 +264,13 @@
 [p2p]
 laddr = "tcp://0.0.0.0:26656"
 external-address = ""
+# bootstrap-peers holds seed/peer addresses (NodeID@host:port, comma-separated)
+# dialled to populate the address book via PEX. As of v6.6.2 (#), `seid init`
+# auto-populates this field with the built-in Sei Labs seed nodes for
+# well-known public networks (pacific-1, atlantic-2). Devnets (arctic-1) and
+# unknown/private chains get none, and an existing bootstrap-peers value is
+# never overwritten. The example below reflects a fresh init on an
+# unrecognised chain.
 bootstrap-peers = ""
 persistent-peers = ""
 upnp = false
@@ -272,6 +279,13 @@
 max-packet-msg-payload-size = 10240
 handshake-timeout = "20s"
 dial-timeout = "3s"
+# How often the node accepts a new inbound connection. The default is "10ms"
+# (a sustained accept rate of ~100 connections/s), raised so the accept loop
+# drains the kernel listen backlog fast enough; an interval too large lets
+# arriving peers wait past handshake-timeout, silently stopping the node from
+# acquiring inbound peers. A value of 0 disables the limiter. Negative values
+# are rejected during config validation.
+accept-interval = "10ms"
 
 # RPC Configuration
 [rpc]
@@ -321,11 +335,11 @@
  - The `proxy-app` and `abci` fields in `config.toml` are **deprecated and ignored**, and are no longer written to newly generated `config.toml` files. Node operators upgrading should delete these lines from their `config.toml` if present.
 </Warning>

 ## Network Parameters

 Understanding network parameters helps you operate your node effectively.

 ### Chain Parameters

 These parameters define the network's behavior:

@@ -353,7 +367,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/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,13 @@
 
 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.
 
+<Note>
+`--chain-id` is required — pass a value such as `pacific-1` or `atlantic-2`.
+
+For recognized public networks (`pacific-1`, `atlantic-2`), `seid init` automatically writes the Sei Labs seed nodes into the `bootstrap-peers` field of `config.toml`, so a freshly initialized node bootstraps peer discovery with no additional configuration. Devnets (`arctic-1`) and unknown or private chains receive no seeds, and any pre-existing `bootstrap-peers` value is never overwritten.
+</Note>
+
 ### Key Management
 
 The security of your validator begins with proper key management. Your validator requires several distinct keys:

@@ -41,7 +47,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 +59,7 @@
 # Configure YubiHSM2
 yubihsm-connector -d

 # Generate key in HSM
 yubihsm-shell

 # Configure seid to use HSM
@@ -98,13 +104,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:

@@ -124,7 +130,7 @@
 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.

@@ -149,7 +155,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
 ```

@@ -181,13 +187,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.
@@ -208,9 +214,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>

@@ -226,7 +232,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: