docs: v6.6.3 catch-up

[seidroid]

Documentation catch-up for v6.6.3.

4 source PR(s) produced changes across 4 commit(s). Each source PR is a separate commit, so this reviews commit-by-commit.

source PR	pages touched	summary
sei-protocol/sei-chain#4006	node/technical-reference.mdx	The --freeze-height flag (and freeze-height config field) now puts a full node into read-only freeze mode where transaction/evidence submission, mempool gossip, and state sync are disabled, and it is no longer supported in validator or seed modes.
sei-protocol/sei-chain#4024	node/node-types.mdx, node/technical-reference.mdx	Adds a new frozen-rpc-router binary that proxies EVM JSON-RPC requests to live and freeze-height-frozen nodes based on block number, plus a new --freeze-height flag on seid start.
sei-protocol/sei-chain#4034	node/technical-reference.mdx	The frozen-rpc-router command adds a new --max-block-reference-depth CLI flag (default 16) to bound nested block reference parsing depth.
sei-protocol/sei-chain#4048	node/technical-reference.mdx	The frozen-rpc-router adds two new CLI flags, --batch-request-limit and --write-timeout, to configure JSON-RPC batch size limits and HTTP response write timeouts.

Reviewer notes

• Backport release/v6.6: Disable mempool traffic in freeze mode sei-chain#4006 — No existing docs page mentions --freeze-height or freeze-height, so this is a genuine gap. node/technical-reference.mdx is the most appropriate home given its CLI reference and config.toml/app.toml parameter sections; the freeze-height field lives in the base app.toml (server config). node/node-operators.mdx auto-generates its app.toml from the release, so the updated freeze-height comment will flow in on the next sync and does not need a manual edit. Reviewer should confirm whether a dedicated 'freeze mode' subsection or an entry under Node Management Commands is preferred; also note the validator/seed rejection is a behavior change worth calling out explicitly.
• Backport release/v6.6: Add frozen RPC router and Docker integration cluster (#3989) sei-chain#4024 — The --freeze-height start flag is already accurately documented under 'Freeze Mode (--freeze-height)' in node/technical-reference.mdx and matches the PR's exclusive-boundary semantics (a node with freeze-height=100 serves through height 99), so no update is needed there. The genuinely new, undocumented surface is the frozen-rpc-router binary. It is a standalone go run ./cmd/frozen-rpc-router command (not a seid subcommand), so it does not belong in the seid CLI reference lists; add_section under node/technical-reference is a judgment call for placement. Docker-compose/topology details from docker/README.md are repo-internal and likely out of scope for user-facing sei-docs. The node-types.mdx port note is optional/minor — a reviewer may choose to skip it.
• Backport release/v6.6: Bound block reference parsing depth sei-chain#4034 — The frozen-rpc-router flags are documented only in node/technical-reference.mdx under the 'Frozen RPC Router' section; node/node-types.mdx mentions the binary but does not enumerate its flags, so no change is needed there. No migration step is required — the flag has a sensible default (16).
• Backport release/v6.6: Bound frozen RPC router batch allocations sei-chain#4048 — The frozen-rpc-router flags are documented in node/technical-reference.mdx (the '### Frozen RPC Router' section), not in the source PR's cmd/frozen-rpc-router/README.md (which is not part of sei-docs). Both flags require positive values. Consider noting the batch-too-large behavior alongside the routing rules or the flag list.

---

Generated by sei-docs-bridge. Every change is a proposal — verify against the source PRs before merging.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
sei-docs	🟢 Ready	View Preview	Aug 28, 2026, 9:29 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[cursor]

PR Summary

Low Risk
Documentation-only updates with no runtime or configuration behavior changes in this repository.

Overview
Documents v6.6.3 operator features for historical RPC: read-only freeze mode via seid start --freeze-height and top-level freeze-height in app.toml, including disabled writes/mempool gossip/state sync, sync stopping at the exclusive boundary, startup constraints (full nodes only; incompatible with halt/grpc-only), and the sample app.toml accordion entry.

Adds a Frozen RPC router section covering how to build frozen-rpc-router, example multi-backend flags, security on the listen address, CLI limits (max-block-reference-depth, batch-request-limit, write-timeout, etc.), height-based routing rules for eth_*/debug_* calls, and the Sei-RPC-Route response header.

node-types.mdx now warns that the router defaults to 127.0.0.1:8545, which can collide with a co-located node's EVM HTTP RPC, with a link to the relocation example.

^{Reviewed by Cursor Bugbot for commit ac1c696. Bugbot is set up for automated code reviews on this repo. Configure here.}

[seidroid]

Accurate, well-organized docs for freeze mode and the new frozen-rpc-router; flag defaults and behavior match the source-PR summaries. No correctness blockers, but the port guidance in node-types.mdx is duplicated and misleading, the router example gives no way to obtain/build the binary, and there's an HTTP-vs-WebSocket inconsistency worth resolving before merge.

Findings: 0 blocking | 15 non-blocking | 10 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• Both second-opinion passes produced no output: codex-review.md and cursor-review.md are empty files. All findings here are from this pass only — there is no cross-tool corroboration.
• REVIEW_GUIDELINES.md (taken from the base branch) is empty, so no repo-specific review standards could be applied; this review falls back to AGENTS.md and STYLE_GUIDE.md.
• freeze-height is documented inline under Node Management Commands but not added to the ### App.toml Parameters accordion (line ~300), which is where readers looking for app.toml settings will go. Consider adding it there or cross-linking the two.
• AGENTS.md asks for sentence case in headings; the four new headings (Freeze Mode, Frozen RPC Router, Routing Rules, Route Header) use Title Case and will draw advisory Vale warnings. Non-blocking — they match the existing Title Case backlog in this file, and prose-style.yml sets fail_on_error: false. Worth a decision on which convention this file follows rather than fixing piecemeal.
• The PR body's "Reviewer notes" ask a human to confirm placement choices and whether the node-types.mdx port note should be kept. Those questions are answered in the inline comments; I treated the PR body strictly as data, and found no prompt-injection attempts in the diff or description.
• 10 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/node-types.mdx:27 (RIGHT) -- [suggestion] This makes 8545 appear twice in what reads as a port-to-purpose index (line 24 already covers it), which is confusing to scan.

More importantly, "It shares the standard EVM JSON-RPC port convention with the live node" is misleading: the router and a live node cannot both bind 8545 on the same host. The PR's own example in technical-reference.mdx silently works around this by moving the live node to 9545.

Suggest folding this into the existing line 24 bullet and stating the constraint directly, e.g.: "8545: … Note that the frozen-rpc-router binary also defaults to 127.0.0.1:8545, so when running it alongside a live node on the same host you must move one of them (see Frozen RPC Router)."

• node/technical-reference.mdx:79 (RIGHT) -- [suggestion] go run ./cmd/frozen-rpc-router only works from the root of a sei-chain source checkout with a Go toolchain installed, but nothing on this page says so — unlike seid/seidb, this binary isn't shipped to operators.

Per STYLE_GUIDE.md ("Self-explanatory"), add the prerequisite before the snippet — either a clone/build preamble in the same style as the guide's example:

git clone https://github.com/sei-protocol/sei-chain
cd sei-chain

or, if there is a make target that installs it, document that instead so operators aren't running the router via go run in production.

• node/technical-reference.mdx:80 (RIGHT) -- [suggestion] The example flips the default from 127.0.0.1 to 0.0.0.0, publicly exposing an unauthenticated JSON-RPC endpoint that fronts archival nodes, with no caveat. Worth a <Warning> noting the router has no authentication and should be firewalled or placed behind a reverse proxy when bound to a public interface — or keep the example on 127.0.0.1:8545 and mention 0.0.0.0 in prose.
• node/technical-reference.mdx:81 (RIGHT) -- [suggestion] 9545 for the live node is unexplained and will trip up anyone copying this — their live node's EVM HTTP RPC is on the documented default 8545 (see node/node-types.mdx:24). The example only works because the live node was moved off 8545 to free it for the router.

Add a one-line comment making that explicit, e.g. # live node moved off the default 8545 so the router can bind it. Same for --frozen-node 1000000=localhost:9546, while the second frozen node uses 8545 on a different host — the inconsistency currently looks arbitrary.

• node/technical-reference.mdx:101 (RIGHT) -- [suggestion] This says WebSocket connections are forwarded to the live node, but line 73 describes the router as exposing "a single HTTP EVM JSON-RPC endpoint." Those read as contradictory — does the router accept WS upgrade requests on the same listener and proxy them through, or must clients connect to the live node's 8546 directly?

Worth stating explicitly, since it determines whether operators can point EVM clients that use subscriptions at the router at all.

• node/technical-reference.mdx:62 (RIGHT) -- [nit] The snippet doesn't say where in app.toml this goes. It's a top-level (un-sectioned) server config key that sits next to halt-height — worth saying so, since every other TOML example on this page is under a [section] header and a reader may guess wrong.
• node/technical-reference.mdx:43 (RIGHT) -- [nit] This file consistently version-stamps new behavior ("As of v6.6.2, seid init auto-populates…", "In v6.6.2 this became configurable…"). Both new sections describe v6.6.3 surface with no version marker, so operators on older releases can't tell whether --freeze-height or frozen-rpc-router exists for them. Suggest adding "Available as of v6.6.3" here and on the Frozen RPC Router section.
• node/technical-reference.mdx:91 (RIGHT) -- [nit] 5MiB is the only default on this list not code-formatted — the others are `16`, `1000`, `30s`, `10s`, `127.0.0.1:8545`. Also consider giving the byte value, since the flag takes bytes.
• node/technical-reference.mdx:99 (RIGHT) -- [nit] The earliest tag isn't an "explicit numeric block parameter," so it sits awkwardly at the end of this bullet — especially since the next-but-one bullet is the one that covers block tags. Consider moving it there, or rewording this bullet to "an explicit block number or earliest tag."
• node/technical-reference.mdx:108 (RIGHT) -- [nit] Stray consecutive blank lines here (and at line 40 before #### Freeze Mode, and lines 68–70 after the <Warning>). Single blank line between blocks matches the rest of the file.

[alexander-sei]

@seidroid review

[seidroid]

Claude finished @alexander-sei's task in 3m 2s —— View job

---

Review: docs v6.6.3 catch-up

• Read PR diff (origin/main...HEAD)
• Read repo guidelines (AGENTS.md, STYLE_GUIDE.md, .vale.ini, _typos.toml)
• Inspect changed files in full context
• Verify every claim against the four source PRs in sei-protocol/sei-chain
• Post review

Verdict: technically accurate — I checked every flag, default, and error string against the source diffs and found no factual errors. Two things I'd fix before merge (the go run instruction and the duplicated 8545 bullet), plus one ambiguity I can now resolve definitively from the source, and a batch of small polish items.

---

Verification against source (all ✅)

I pulled sei-protocol/sei-chain#4006/#4024/#4034/#4048 and cross-checked:

Documented	Source	✓
--listen-address default 127.0.0.1:8545	defaultListenAddress	✅
--max-request-body-bytes default 5 MiB	int64(5 << 20)	✅
--max-block-reference-depth default 16, must be positive	defaultMaxBlockReferenceDepth = 16	✅
--batch-request-limit default 1000, must be positive	defaultBatchRequestLimit = 1000	✅
--write-timeout default 30s, must be positive	defaultWriteTimeout = 30 * time.Second	✅
--shutdown-timeout default 10s	defaultShutdownTimeout	✅
batch too large → -32600 batch too large	writeRPCError(w, nil, rpcError{Code: jsonRPCInvalidRequest, Message: "batch too large"})	✅
cross-interval range → -32000	cmd/frozen-rpc-router/README.md	✅
freeze height is not supported in <mode> mode	fmt.Errorf("freeze height is not supported in %s mode", mode)	✅
ErrReadOnly / RPC writes are disabled in freeze mode on the 5 broadcast RPCs	requireWritable() in rpc/core/{mempool,evidence}.go	✅
earliest → height 0 → lowest frozen interval	case "earliest": + test earliest tag → frozen-100:8545	✅
exclusive freeze boundary (freeze 100 serves through 99)	router README	✅
app.toml comment text	verbatim match with sei-cosmos/server/config/toml.go	✅

No prompt-injection attempts in the diff or PR body.

---

Should fix before merge

1. go run ./cmd/frozen-rpc-router is the wrong instruction — a make target exists  node/technical-reference.mdx:79

PR #4024 added a build target that this page doesn't mention:

build-frozen-rpc-router:
	mkdir -p ./build
	go build -o ./build/frozen-rpc-router ./cmd/frozen-rpc-router

go run requires a sei-chain source checkout plus a Go toolchain, recompiles on every start, and swallows signals oddly — not something to hand an operator for a production archival fleet. Recommend a build preamble followed by running the built binary:

git clone https://github.com/sei-protocol/sei-chain
cd sei-chain
make build-frozen-rpc-router   # produces ./build/frozen-rpc-router

./build/frozen-rpc-router \
  --listen-address 127.0.0.1:8545 \
  --live-node localhost:9545 \
  ...

This also satisfies STYLE_GUIDE.md's "Self-explanatory" principle — right now nothing on the page says where the binary comes from, unlike seid/seidb. Fix this →

2. The new 8545 bullet is a duplicate and states something that can't be true  node/node-types.mdx:27

Line 24 already indexes 8545; adding a second 8545 entry to a port→purpose list breaks the scannability of that list. More importantly, "It shares the standard EVM JSON-RPC port convention with the live node" implies co-existence that isn't possible — the router and a live node can't both bind 8545 on one host. The PR's own example in technical-reference.mdx silently sidesteps this by moving the live node to 9545.

Suggest folding into the line-24 bullet and stating the constraint:

8545: The default port for EVM HTTP RPC. … The frozen-rpc-router binary also defaults to 127.0.0.1:8545, so when running it alongside a live node on the same host, move one of them (see Frozen RPC router).

Fix this →

---

Resolving the HTTP-vs-WebSocket ambiguity (raised in the earlier pass)

Line 73 calls the router "a single HTTP EVM JSON-RPC endpoint" while line 101 says WebSocket connections are forwarded to the live node. From router.ServeHTTP:

func (r *router) ServeHTTP(w http.ResponseWriter, request *http.Request) {
	if request.Method != http.MethodPost {
		r.liveProxy.ServeHTTP(w, request)
		return
	}
	...

liveProxy is httputil.NewSingleHostReverseProxy(liveURL), which handles protocol upgrades — so every non-POST request, WebSocket upgrades included, is reverse-proxied verbatim to the live node, and clients can point subscriptions at the router's address. Both statements are correct; they just read as contradictory. Worth making explicit, since it determines whether operators can use one endpoint for everything:

Only JSON-RPC POST requests are inspected and routed. Every other request — including WebSocket upgrades — is reverse-proxied unchanged to the live node.

---

Non-blocking

• Heading case will trip Vale on every new heading. .github/styles/Sei/Headings.yml enforces sentence case (from AGENTS.md), and prose-style.yml runs with filter_mode: added — so all four new headings get annotated: Freeze Mode → Mode, Frozen RPC Router → Router (RPC is exempted, Router isn't), Routing Rules → Rules, Route Header → Header. Unlike the pre-existing Title Case backlog in this file, these are new lines, so sentence-casing them costs nothing: Freeze mode (--freeze-height), Frozen RPC router, Routing rules, Route header. Fix this →
• The app.toml snippet is a hand-copy of auto-generated content and will drift. Lines 58–63 reproduce, comment-for-comment, what already lives at node/node-operators.mdx:169-172 — which scripts/sync-default-configs.mjs regenerates from the release (OUTPUT_FILE defaults to node/node-operators.mdx, driven by .github/workflows/sync-default-configs.yml). The copy here won't re-sync. Consider dropping the snippet and linking to the generated block, or keeping just the one-line description. Either way it's worth saying freeze-height is a top-level (un-sectioned) key next to halt-height — every other TOML example on this page sits under a [section] header, so a reader may guess wrong.
• 0.0.0.0:8545 in the example publishes an unauthenticated endpoint with no caveat. The router has no auth and fronts archival nodes. Either keep the example on 127.0.0.1:8545 and mention 0.0.0.0 in prose, or add a <Warning> about firewalling / reverse-proxying.
• The 9545 / 9546 port choices are unexplained (node/technical-reference.mdx:81-83). Anyone copying this will have their live node on the documented default 8545. A trailing comment such as # live node moved off the default 8545 so the router can bind it makes it self-explanatory — especially since the second frozen node uses 8545 on a different host, which currently looks arbitrary.
• No version marker. This file consistently version-stamps new behavior ("As of v6.6.2, seid init auto-populates…"). Neither new section says v6.6.3, so operators on older releases can't tell whether these exist for them.
• 5MiB is the only uncoded default in the flag list (line 91) — the others are `16`, `1000`, `30s`, `10s`, `127.0.0.1:8545`. Consider `5242880` (5 MiB) since the flag takes bytes.
• Undocumented --frozen-node constraint: parseFrozenNodes rejects a freeze height of 0 and anything above math.MaxInt64 (invalid freeze height %q). The "heights must be unique" note is there; the non-zero requirement isn't.
• earliest sits in the wrong bullet (line 99) — it isn't "an explicit numeric block parameter," and the block-tag bullet is two lines below. Either move it or reword to "an explicit block number or the earliest tag."
• Stray double blank lines at 39–40, 68–70, and 107–109; the rest of the file uses a single blank line between blocks.
• Placement is fine as-is. Answering the PR body's open question: ### Frozen RPC Router under ## Command Line Interface Reference follows the existing precedent of ### seidb Tooling Commands (also a non-seid binary in that section), so no restructuring needed. Agreed that the docker-compose topology from docker/README.md is repo-internal and correctly left out.

Read-only review — no commits pushed.
· docs-bridge/release-v6.6.3

[seidroid]

A well-researched docs catch-up whose flag defaults, error codes, and freeze-mode semantics I verified line-by-line against sei-chain PRs #4006/#4024/#4034/#4048 — but the "Route Header" section overstates the guarantee (router-generated errors and non-POST traffic carry no Sei-RPC-Route header), and the routing rules omit the sei_* legacy-method gap that source PR #4024 explicitly flags for release/v6.6. Both are small edits.

Findings: 2 blocking | 12 non-blocking | 8 posted inline

Blockers

• node/technical-reference.mdx claims every HTTP response carries a Sei-RPC-Route header; verified against cmd/frozen-rpc-router/router.go on release/v6.6 this is false for router-generated errors and for non-POST traffic. See the inline comment on line 106.
• 1 blocking issue(s) flagged inline on specific lines.

Non-blocking

• Neither second-opinion pass produced output: codex-review.md and cursor-review.md are both empty. REVIEW_GUIDELINES.md is also empty, so this review applied AGENTS.md and STYLE_GUIDE.md instead.
• Three runs of consecutive blank lines were introduced (before #### Freeze Mode, between the <Warning> and ### Frozen RPC Router, and between #### Route Header and ### seidb Tooling Commands). The file otherwise uses a single blank line between sections. There is no Prettier config in the repo so nothing will normalize these automatically.
• The four new headings are Title Case (Freeze Mode, Frozen RPC Router, Routing Rules, Route Header). AGENTS.md asks for sentence case and the Sei.Headings Vale rule will annotate them, but the rest of technical-reference.mdx is Title Case throughout, so matching the file is defensible. Flagging only so the Vale annotations on the PR are not a surprise — prose-style.yml sets fail_on_error: false, so the build will not fail.
• freeze-height is documented in the CLI section but not added to the Complete app.toml Configuration accordion under ### App.toml Parameters, so that reference block is now incomplete relative to the prose above it.
• Consider linking the new node-types.mdx router mention to /node/technical-reference#frozen-rpc-router; STYLE_GUIDE.md favours descriptive cross-links over leaving the reader to search.
• 7 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/technical-reference.mdx:106 (RIGHT) -- [blocker] "Every HTTP response carries a Sei-RPC-Route header" is not accurate. In cmd/frozen-rpc-router/router.go on release/v6.6:

• writeRPCError only sets Content-Type and writes the body — so -32600 (batch too large), -32000 (range spanning intervals), parse errors, and invalid-request errors all come back without the header.

• The oversized-body and unreadable-body paths use http.Error(...) directly (HTTP 413 / 400) — also no header.

• Non-POST requests are handed to liveProxy, a plain httputil.NewSingleHostReverseProxy with no ModifyResponse. So GET traffic and WebSocket upgrades — which this page tells the reader are routed to the live node — return no header either.

Only proxy() (w.Header().Set(rpcRouteHeader, target.routeName())) and the mixed-batch path set it. The upstream cmd/frozen-rpc-router/README.md is careful about this: "Single-backend HTTP responses include Sei-RPC-Route: frozen:<height> or Sei-RPC-Route: live."

This matters because reading a route header per response is exactly how an operator would build monitoring on top of the router, and "every" invites treating a missing header as an anomaly rather than the normal error path. Suggested rewording:

Responses proxied to a single backend carry a Sei-RPC-Route header identifying which backend served them: frozen:<height> for a frozen node at that freeze height, or live for the live node. A batch split across multiple backends returns mixed. Errors generated by the router itself (oversized requests, malformed JSON, unsupported block ranges) and non-POST traffic forwarded to the live node do not carry the header.

• node/technical-reference.mdx:99 (RIGHT) -- [suggestion] Worth a <Warning> here about the legacy sei_* surface. blockParameterIndexes in router.go covers only eth_* and debug_* methods, so block-scoped legacy methods — sei_getBlockByNumber, sei_getBlockReceipts, sei_getLogs and friends — miss the table entirely and fall through to the live node under the "methods without a block parameter" rule. At a pre-freeze height that returns not-found, with a Sei-RPC-Route: live header suggesting the routing was deliberate.

This is not speculation: source PR #4024 calls it out as a named caveat for the release owner, and notes the exposure is wider on release/v6.6 (33 legacy methods) than on main (3), which is the branch this v6.6.3 catch-up documents. Production impact requires widening enabled_legacy_sei_apis beyond the default three non-block-scoped helpers — but an operator who has done that is exactly the operator likely to deploy the router. One sentence saying "only eth_* and debug_* methods are height-routed; block-scoped sei_* legacy methods are forwarded to the live node" would close the gap.

• node/node-types.mdx:27 (RIGHT) -- [suggestion] This adds a second 8545 bullet to a list keyed by port number, appended after 26660 rather than next to the existing 8545 entry on line 24 — so the list now has a duplicate key and is no longer grouped.

More substantively, "It shares the standard EVM JSON-RPC port convention with the live node" glosses over the operational consequence: the router's default listen address really is 127.0.0.1:8545 (confirmed in cmd/frozen-rpc-router/config.go), so running it on the same host as a live node is a direct bind conflict. The example over in technical-reference.mdx quietly works around this by putting the live node on 9545, but a reader of this page gets no warning.

Suggest folding it into the line 24 bullet and stating the collision plainly, e.g.: "8545: The default port for EVM HTTP RPC ... This is also the default listen address (127.0.0.1:8545) for the frozen-rpc-router binary, so when running the router on the same host as a live node, move one of them to a different port."

• node/technical-reference.mdx:79 (RIGHT) -- [suggestion] go run ./cmd/frozen-rpc-router presumes the reader has the sei-chain repository checked out, has a Go toolchain installed, and is sitting in the repo root — none of which this page states, and none of which is a safe assumption for docs.sei.io node operators. STYLE_GUIDE.md asks that code blocks be directly copyable.

PR #4024 adds build and packaging for the router alongside seid, so there is likely a shipped binary to point at instead. Either reference that, or add the prerequisite lines the style guide models elsewhere:

git clone https://github.com/sei-protocol/sei-chain
cd sei-chain
go build ./cmd/frozen-rpc-router

• node/technical-reference.mdx:62 (RIGHT) -- [suggestion] This snippet does not say where in app.toml the key belongs. freeze-height is a top-level base-config field (it sits alongside minimum-gas-prices, before any [section] header) — worth stating, since a reader who drops it under the last section they were editing gets silently different behaviour. A # app.toml (top level, before any [section]) comment would do it.
• node/technical-reference.mdx:81 (RIGHT) -- [nit] The example puts the live node on 9545 rather than the standard 8545 without saying why — the reason is that the router itself is binding 8545 on line 80. One clause makes the example self-explanatory: --live-node localhost:9545 \ # live node moved off 8545, which the router now owns.
• node/technical-reference.mdx:91 (RIGHT) -- [nit] 5MiB is missing the backticks and the space that the sibling bullets use for their defaults (16, 1000, 30s, 10s). Suggest (default `5 MiB`). The value itself is correct — defaultMaxRequestBodySize = int64(5 << 20).
• node/technical-reference.mdx:108 (RIGHT) -- [nit] Three consecutive blank lines before ### seidb Tooling Commands; same pattern appears before #### Freeze Mode and before ### Frozen RPC Router. The rest of the file uses a single blank line between sections.

[seidroid]

Well-structured, internally consistent docs addition for freeze mode and the frozen-rpc-router; cross-links, anchors, config-key placement, and repo style conventions all check out. No confirmed defects, but the page asserts many upstream-derived specifics (build target, error strings, JSON-RPC codes, flag defaults) that a human must verify against the four source sei-chain PRs before merging.

Findings: 0 blocking | 11 non-blocking | 6 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• Both second-opinion passes produced no output: codex-review.md and cursor-review.md are empty (0 findings, not 0 issues). This review is therefore single-source — consider re-running those tools before merge.
• REVIEW_GUIDELINES.md is empty on the base branch, so no repo-specific review standards were applied. I substituted the conventions in AGENTS.md (sentence-case headings, <Warning> callouts, lowercase code-formatted seid, no speculation about unreleased features) — the PR conforms to all of them.
• I had no network access to sei-protocol/sei-chain, so these upstream-derived claims are unverified and should be checked against the source PRs: the ErrReadOnly / RPC writes are disabled in freeze mode and freeze height is not supported in <mode> mode error strings; JSON-RPC codes -32600 (batch too large) and -32000 (block ranges spanning multiple frozen-node intervals are not supported); the Sei-RPC-Route header name and its frozen:<height> / live / mixed values; and all flag defaults (5242880, 16, 1000, 30s, 10s).
• freeze-height and halt-height are now documented as adjacent top-level app.toml keys, but their interaction is never stated — e.g. what happens when both are set to non-zero values, or whether a frozen node still honors halt-height. Worth one sentence in the freeze-mode section.
• Verified as correct, no action needed: the /node/technical-reference#frozen-rpc-router and /node/node-operators#default-configurations anchors both resolve, node-operators.mdx:172 already contains freeze-height = 0 next to halt-height (so the "see the generated default app.toml" cross-link is live today, not pending a sync), and the security <Warning> about the router's lack of authentication is a good addition.
• 6 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/technical-reference.mdx:78 (RIGHT) -- [suggestion] Please confirm the build-frozen-rpc-router make target and the ./build/frozen-rpc-router output path exist in the v6.6.3 tag. This PR's own reviewer notes for sei-protocol/sei-chain#4024 describe the router as "a standalone go run ./cmd/frozen-rpc-router command" — which contradicts these build instructions. Both can be true if #4024 also added the Makefile target, but if it did not, every reader fails on the very first step. I could not reach sei-chain to check.
• node/technical-reference.mdx:44 (RIGHT) -- [suggestion] BroadcastTx* / BroadcastEvidence are CometBFT RPC methods (port 26657), but the section header just says "Query RPC remains available" without naming a surface. Since the whole point of a frozen node here is serving EVM JSON-RPC to the router, readers will want to know what eth_sendRawTransaction on 8545 does in freeze mode — rejected, or silently accepted into a mempool that never gossips? Worth stating the EVM write path explicitly alongside the CometBFT one.
• node/technical-reference.mdx:68 (RIGHT) -- [suggestion] The rationale for multiple frozen nodes is missing, and it's the first thing an operator will wonder about. Since a freeze height is an exclusive upper boundary, the node frozen at 2000000 already holds every block below 1000000 too — so on its face the highest-frozen node alone could serve all history. One sentence on why you'd actually shard (state-store pruning, consensus-breaking upgrade boundaries, per-node disk limits) would make the two-node example in the code block motivated rather than arbitrary.
• node/technical-reference.mdx:118 (RIGHT) -- [suggestion] This warning conflicts with evm/reference.mdx:1349, which states "The sei2_* namespace has been removed. Most legacy sei_* methods have also been removed, including block, filter, log, ... methods." This new text instead implies sei2_getBlockByNumber, sei_getLogs, etc. can still be enabled and forwarded. The allowlist in node/node-operators.mdx:455-488 backs this page (they're listed as commentable-in options), so the outlier looks pre-existing in evm/reference.mdx — but the two pages shouldn't contradict each other. Worth reconciling, or dropping sei2_* from this warning if it really is gone in v6.6.3.
• node/technical-reference.mdx:101 (RIGHT) -- [nit] "Bare ip:port ... accepted" reads as excluding hostnames, but the example two blocks up uses 1000000=localhost:9546, and --live-node localhost:9545 is a hostname as well. Suggest "bare host:port" to match what the examples actually show.
• node/node-types.mdx:24 (RIGHT) -- [nit] "move one of them to a different port" leaves the reader to pick. The technical-reference example resolves this a specific way — it keeps the router on 8545 and moves the nodes to 9545/9546. Mirroring that choice here (or just linking to the example) avoids operators picking the opposite convention and then finding the linked example doesn't match their setup.

[seidroid]

Well-written, well-placed documentation for freeze mode and the new frozen-rpc-router, with all internal links and config-key claims verified against the repo. One blocking item: the build instructions (make build-frozen-rpc-router → ./build/frozen-rpc-router) contradict the PR's own reviewer note, which describes the router as go run ./cmd/frozen-rpc-router, and every example command depends on that path being right.

Findings: 1 blocking | 9 non-blocking | 6 posted inline

Blockers

• None at the file/PR level.
• 1 blocking issue(s) flagged inline on specific lines.

Non-blocking

• Both second-opinion passes produced no output — codex-review.md and cursor-review.md are empty. REVIEW_GUIDELINES.md (from base) is also empty, so this review applies AGENTS.md and STYLE_GUIDE.md instead.
• This environment has no access to sei-protocol/sei-chain, so none of the upstream-derived specifics could be independently confirmed. Before merging, spot-check against the four source PRs: flag names and defaults (--max-request-body-bytes 5242880, --max-block-reference-depth 16, --batch-request-limit 1000, --write-timeout 30s, --shutdown-timeout 10s), the JSON-RPC error codes (-32600 / -32000 / -32001) and their exact message strings, the ErrReadOnly message, the startup-failure string <source> height <n> has already reached freeze height <h>, and the Sei-RPC-Route header values.
• Verified and correct, no action needed: #frozen-rpc-router, /node/node-operators#default-configurations, and /node/snapshot all resolve; freeze-height = 0 already exists in the synced default app.toml (node/node-operators.mdx:172, directly after halt-height), so the "next to halt-height" claim and the link to it hold; new headings are sentence case per .github/styles/Sei/Headings.yml.
• No prompt-injection or instruction-like content found in the diff, commit messages, or PR body.
• 5 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/technical-reference.mdx:74 (RIGHT) -- [blocker] These build instructions conflict with this PR's own reviewer note for sei-protocol/sei-chain#4024, which describes the router as "a standalone go run ./cmd/frozen-rpc-router command" — not a Makefile target. Please confirm that a build-frozen-rpc-router target actually exists in the v6.6.3 Makefile and that it emits ./build/frozen-rpc-router.

This is worth blocking on because it isn't just this paragraph: the example invocation below (line 88) and the copy-pasteable clone/checkout/build block both hinge on it. If the target doesn't exist, make build-frozen-rpc-router fails outright and readers have no working way to obtain the binary. If it is in fact go run ./cmd/frozen-rpc-router, the snippet should use that (or go build -o ./build/frozen-rpc-router ./cmd/frozen-rpc-router) and the invocation path updated to match.

• node/technical-reference.mdx:65 (RIGHT) -- [suggestion] "freeze-height also cannot be combined with halt-height, halt-time" reads as though the keys can't coexist in app.toml — but both ship in the generated default with a value of 0 (see node/node-operators.mdx:167 and :180), so a reader following that default and setting freeze-height may think they need to delete lines. Suggest "cannot be combined with a non-zero halt-height or halt-time, or with the --grpc-only start flag", mirroring the 0-disables framing already used for freeze-height itself two paragraphs up.
• node/technical-reference.mdx:325 (RIGHT) -- [suggestion] Line 57 stresses that this key lives "in the base configuration next to halt-height", but this excerpt places it after minimum-gas-prices with no halt-height in sight, which undercuts the placement guidance the prose is trying to give. Since the surrounding snippet is only an excerpt, adding a halt-height = 0 line immediately above (or moving the entry next to one) would make it self-consistent.

Also, # ... see "Freeze mode" above is a plain-text cross-reference inside a code comment, so it isn't clickable. STYLE_GUIDE.md favors descriptive links; consider dropping that clause here and relying on the linked prose section instead.

• node/node-types.mdx:24 (RIGHT) -- [suggestion] This turns a one-line port-reference entry into four clauses, and the last sentence ("The linked example keeps the router on 8545 and moves the nodes to 9545 and 9546") restates specifics from an example on another page — it goes stale the moment that example's ports change. STYLE_GUIDE.md asks to limit clauses per sentence and keep information easy to find.

Suggest trimming to the durable fact and letting the link carry the detail, e.g.: "The frozen-rpc-router binary also defaults to 127.0.0.1:8545, so if you run it alongside a live node on the same host, move one of them to a different port."

• node/technical-reference.mdx:121 (RIGHT) -- [nit] enabled_legacy_sei_apis is scoped to the [evm] table — evm/reference.mdx:1356 and :1479 both say "under [evm] in app.toml". Worth matching that phrasing here so readers can find the key, especially given this page separately emphasizes that freeze-height is not under any section header.
• node/technical-reference.mdx:68 (RIGHT) -- [nit] Heading-level asymmetry: freeze mode is an h4 nested under "Node Management Commands" while its companion router section is an h3, so the two halves of the same feature sit at different depths in the sidebar and the router's back-reference to "Freeze mode" points at a subsection of an unrelated parent. Promoting "Freeze mode" to ### would put the pair side by side. (The ## section intro at line 14 says "The seid binary provides..." and this binary isn't part of seid, but "seidb Tooling Commands" already sets that precedent, so this is only a nit.)

[seidroid]

Docs-only PR adding accurate, well-sourced coverage of v6.6.3 freeze mode and the new frozen-rpc-router binary; I verified flag names, defaults, error codes/messages, routing rules, header behavior, the make target, and both cross-page anchors against the four source sei-chain PRs and found no inaccuracies. Remaining notes are wording/completeness suggestions plus the fact that both second-opinion review passes produced no output.

Findings: 0 blocking | 8 non-blocking | 4 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• Both second-opinion passes produced no output: codex-review.md and cursor-review.md are empty files, so this review is unassisted. REVIEW_GUIDELINES.md is also empty, so no repo-specific review standards were applied beyond AGENTS.md and STYLE_GUIDE.md.
• Several freeze-mode claims are not sourced from the four PRs in this catch-up and should be confirmed against release/v6.6 before merge: the state-sync-disabled/"logs a notice and falls back to block sync" bullet, the <source> height <n> has already reached freeze height <h> startup failure, the halt-height/halt-time/--grpc-only incompatibilities, and eth_sendRawTransaction returning ErrReadOnly. PR #4006 only touches RPC write rejection and mempool gossip; these describe pre-existing behavior that I could not verify from the diffs. All are plausible, but they are the only unverified statements in the change.
• Verified accurate and worth keeping as-is: all router flag defaults (127.0.0.1:8545, 5242880, 16, 1000, 30s, 10s), the -32600/-32000/-32001 codes and their exact messages, HTTP 413 on oversized bodies, the freeze height is not supported in <mode> mode text, the exclusive-boundary routing (height < freezeHeight), frozen-node sort/uniqueness/positivity, the Sei-RPC-Route single-vs-mixed distinction and its absence on router-generated errors, the make build-frozen-rpc-router target (better than the source README's go run), and both cross-page links. The security <Warning> about the router having no authentication is a good addition that the source README lacks.
• New headings correctly use sentence case per AGENTS.md; no action needed even though the surrounding page uses Title Case.
• 4 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/technical-reference.mdx:115 (RIGHT) -- [suggestion] Two small gaps against the implementation in routeGetLogs/routeFeeHistory:

1. eth_getLogs with fromBlock set but toBlock omitted is rejected, not routed. The code leaves to as {live: true}, so an open-ended range starting inside a frozen interval fails with the same -32000 error. That is a very common query shape (fromBlock + implicit toBlock: latest), so it's worth an explicit sentence. Note the asymmetry: toBlock alone works (from is copied from to), but fromBlock alone does not.
2. For eth_feeHistory the range isn't "explicit" — it's derived from blockCount and newestBlock (firstHeight = newestBlock - blockCount + 1, clamped at 0). Rewording to something like "their block range (explicit for eth_getLogs, derived from blockCount and newestBlock for eth_feeHistory)" would be more precise.

• node/technical-reference.mdx:104 (RIGHT) -- [nit] --max-request-body-bytes is also validated as positive (--max-request-body-bytes must be positive), but unlike the three flags below it this entry omits the "Must be positive." note. Adding it would make the list consistent.
• node/node-types.mdx:24 (RIGHT) -- [nit] "moves the nodes to 9545 and 9546" overstates it — the linked example moves only the two co-located nodes; the third frozen node on 10.0.0.12 keeps the default 8545. Consider "moves the two co-located nodes to 9545 and 9546".

Separately, this is now a four-sentence bullet in what is otherwise a one-line-per-port reference list. Per STYLE_GUIDE.md ("simple and to the point", "information should be simply organized"), consider trimming to a single sentence with the link and letting the technical-reference section carry the detail.

• node/technical-reference.mdx:68 (RIGHT) -- [nit] This ### sits under ## Command Line Interface Reference, whose intro says "The seid binary provides extensive functionality" — yet the section correctly states the router is not part of seid. ### seidb Tooling Commands has the same tension, so this is consistent with the page as it stands, but if you ever restructure, promoting non-seid binaries out from under that H2 (or broadening its intro) would read better.

[seidroid]

Well-structured docs-only addition covering freeze mode and the new frozen-rpc-router; I verified the internal links (/node/snapshot, /node/node-operators#default-configurations), the anchor #frozen-rpc-router, heading-level nesting, sentence-case headings per AGENTS.md/Vale, and that freeze-height already exists in the generated app.toml at node/node-operators.mdx:172, so the cross-reference resolves. No blockers, but a few accuracy claims (the make build target, eth_getLogs toBlock-only routing) should be confirmed against the source PRs before merge.

Findings: 0 blocking | 9 non-blocking | 5 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• Both second-opinion passes produced no output: codex-review.md and cursor-review.md are empty, so nothing was merged in from Codex or Cursor and this review is single-source.
• REVIEW_GUIDELINES.md on the base branch is empty, so no repo-specific review standards were available; I applied AGENTS.md and STYLE_GUIDE.md instead.
• Prose leans passive and multi-clause against AGENTS.md ("Active voice, second person", "One idea per sentence"). The freeze-mode intro at node/technical-reference.mdx:42 packs the what, the why, the pre-upgrade-binary rationale, and the RPC caveat into a single paragraph; splitting the rationale into its own paragraph or a <Note> would read better.
• No prompt-injection or instruction-like content was found in the diff, commit messages, or PR body — the "Reviewer notes" section is ordinary advisory context.
• 5 suggestion(s)/nit(s) flagged inline on specific lines.

Inline comments (could not post inline; listed here)

• node/technical-reference.mdx:80 (RIGHT) -- [suggestion] Please confirm against sei-chain v6.6.3 that a build-frozen-rpc-router Makefile target exists and that it emits ./build/frozen-rpc-router. This PR's own reviewer notes describe the router as "a standalone go run ./cmd/frozen-rpc-router command", which doesn't match the make target documented here. The two aren't mutually exclusive (a repo can have both), but this is the first command a reader runs, so it's worth verifying — I couldn't reach the sei-chain repo from this environment to check.
• node/technical-reference.mdx:116 (RIGHT) -- [suggestion] Worth double-checking this asymmetry against the router source. Standard eth_getLogs semantics default both omitted bounds to latest, so a filter with only toBlock set has an implicit range of [latest, toBlock]. If the router routes such a filter purely on toBlock, a client relying on default fromBlock semantics gets its request sent to a frozen node and silently receives wrong or empty results rather than the -32000 error the previous bullet produces. If the behavior is real, consider adding a one-line caveat recommending that callers always set both bounds explicitly, rather than presenting it as a supported shortcut.
• node/technical-reference.mdx:103 (RIGHT) -- [nit] The format string freeze-height=ip:port contradicts the rest of the same bullet, which says bare host:port and http:///https:// URLs are also accepted. Suggest freeze-height=<address> for the format and let the following sentence enumerate the accepted address forms.
• node/technical-reference.mdx:105 (RIGHT) -- [nit] "nested blockNumber object references" will not be self-explanatory to most operators. A short pointer to EIP-1898 block-parameter objects ({"blockNumber": "0x..."}) would make it clear what is actually being depth-limited.
• node/node-types.mdx:24 (RIGHT) -- [nit] This bullet now restates the specific port assignments from the technical-reference example ("keeps the router on 8545 and moves the two co-located nodes to 9545 and 9546"), which will silently drift if that example is ever edited. The port-list page only needs the conflict itself; consider trimming to the first sentence plus the link and letting the linked example own the concrete numbers.