docs: v6.6.3 catch-up

node/node-types.mdx

@@ -13,7 +13,7 @@
 
 - Validator Nodes provide security to the chain by proposing and signing blocks. To enable this type of node, set `mode=validator` in `config.toml`. Note that because Sei is proof-of-stake, you must have enough delegation to join the active set.
 
 ## Commonly Used Ports
 
 Seid uses the following TCP ports. Toggle their settings to match your environment.
 
@@ -24,10 +24,11 @@
 - `8545`: The default port for EVM HTTP RPC. This port is used for Ethereum JSON-RPC calls and must be open if you want to interact with EVM-compatible applications.
 - `8546`: The default port for EVM WebSocket RPC. This port provides real-time communication for EVM applications that require WebSocket connections.
 - `26660`: The default port for interacting with the Prometheus database, which can be used to monitor the environment. In the default configuration, this port is not open.
+- `8545`: Also the default listen address (`127.0.0.1:8545`) for the `frozen-rpc-router` binary, which proxies EVM JSON-RPC requests to a live node and one or more freeze-height-frozen nodes based on block number. It shares the standard EVM JSON-RPC port convention with the live node.
 
 These ports are all customizable in `$HOME/.sei/config/config.toml` and `$HOME/.sei/config/app.toml`.
 
 ## Systemd File Template
 
 ```toml
 [Unit]

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,81 @@
 seid query node info
 ```
 
+
+#### Freeze Mode (`--freeze-height`)
+
+The `--freeze-height` start flag (and the corresponding `freeze-height` field in `app.toml`) puts a full node into read-only freeze mode at a specified block height. Query RPC remains available so the node can continue serving reads, but write and network paths are disabled from startup:
+
+- Transaction and evidence submission is rejected. The `BroadcastTx`, `BroadcastTxAsync`, `BroadcastTxSync`, `BroadcastTxCommit`, and `BroadcastEvidence` RPC calls all return `ErrReadOnly` (`RPC writes are disabled in freeze mode`).
+- Mempool gossip is disabled — the mempool reactor is not started and the mempool p2p channel is not advertised to peers.
+- State sync is disabled.
+
+Block sync and consensus stop before executing the configured height and will not advance beyond it.
+
+```bash
+# Start a full node in read-only freeze mode at a given block height
+seid start --freeze-height <height>
+```
+
+The same behavior can be configured persistently via the `freeze-height` field. `freeze-height` is the first block height a full node must not execute; a value of `0` disables freeze mode.
+
+```toml
+# The first block height a full node must not execute. Query RPC remains available,
+# while transaction and evidence submission, mempool gossip, and state sync are
+# disabled from startup. Set to 0 to disable freeze mode.
+freeze-height = 0
+```
+
+<Warning>
+  Freeze mode is only supported for full nodes. Setting a non-zero `freeze-height` in validator or seed mode is rejected at startup with an error (`freeze height is not supported in <mode> mode`).
+</Warning>
+
+
+
+### Frozen RPC Router
+
+The `frozen-rpc-router` binary is a companion to freeze mode. It exposes a single HTTP EVM JSON-RPC endpoint that transparently proxies requests to a live node and one or more freeze-height-frozen nodes, routing each request to the correct backend based on the block height it references. This lets a set of archival nodes — each frozen before a different height — collectively serve historical state through one endpoint.
+
+Because a freeze height is an exclusive boundary, a node started with `--freeze-height 100` serves blocks through height 99. The router therefore sends height 99 to that node and height 100 to the next configured interval (or to the live node when no frozen interval covers it).
+
+```bash
+# Route between a live node and two frozen nodes
+go run ./cmd/frozen-rpc-router \
+  --listen-address 0.0.0.0:8545 \
+  --live-node localhost:9545 \
+  --frozen-node 1000000=localhost:9546 \
+  --frozen-node 2000000=10.0.0.12:8545
+```
+
+The binary accepts the following flags:
+
+- `--listen-address` — address on which the router listens (default `127.0.0.1:8545`).
+- `--live-node` — HTTP RPC address of the live node (required).
+- `--frozen-node` — a `freeze-height=ip:port` pair; repeat once per frozen node. Bare `ip:port`, `http://`, and `https://` URLs are all accepted. Frozen nodes may be listed in any order, but freeze heights must be unique.
+- `--max-request-body-bytes` — maximum JSON-RPC request body size (default 5MiB); larger requests are rejected with HTTP `413`.
+- `--max-block-reference-depth` — maximum nested block reference depth (default `16`); bounds how deeply nested `blockNumber` object references are parsed when resolving a request's block parameter. Must be positive.
+- `--batch-request-limit` — maximum number of calls in a JSON-RPC batch (default `1000`). Must be positive. A batch exceeding this limit is rejected with JSON-RPC error `-32600` (`batch too large`).
+- `--write-timeout` — maximum duration for writing an HTTP response (default `30s`). Must be positive.
+- `--shutdown-timeout` — graceful shutdown timeout (default `10s`).
+
+#### Routing Rules
+
+- Methods with an explicit numeric block parameter (for example `eth_getBlockByNumber`, `eth_getBalance`, `eth_call`, `eth_getStorageAt`, `debug_traceBlockByNumber`) are routed to the interval that contains that height. The `earliest` tag resolves to height 0.
+- `eth_getLogs` and `eth_feeHistory` are routed only when their entire explicit block range falls within a single interval. A range that crosses an interval boundary is rejected with JSON-RPC error `-32000` (`block ranges spanning multiple frozen-node intervals are not supported`).
+- Latest-style block tags (`latest`, `pending`, `safe`, `finalized`), requests referencing a block by hash, methods without a block parameter, stateful filter methods, subscriptions, and WebSocket connections are all forwarded to the live node.
+- Batch requests are split so each call reaches its correct backend, then reassembled into a single response.
+
+#### Route Header
+
+Every HTTP response carries a `Sei-RPC-Route` header identifying which backend served it: `frozen:<height>` for a request served by the frozen node at that freeze height, `live` for the live node, and `mixed` for a batch split across multiple backends.
+
+
+
 ### 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 +137,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 +177,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 +208,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 +226,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 +245,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 +270,7 @@
 seid keys show <name> -a
 ```
 
 ### Transaction Commands
 
 These commands allow you to interact with the blockchain:
 
@@ -218,12 +288,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:
 
@@ -321,11 +391,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 +423,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: