docs(node): confirm v6.6 SC migration model, add version-scoping note for operators

node/node-operators.mdx

@@ -9,9 +9,9 @@
 including configuration management, maintenance procedures, and best practices
 for stable and performant operations.
 
 ## Configuration Management
 
 ### Directory Structure
 
 The Sei node configuration is stored in `$HOME/.sei/config/`:
 
@@ -31,9 +31,9 @@
 [Default Configurations](#default-configurations) at the bottom of this
 section.
 
 ### Essential Configuration Parameters
 
 #### Network Settings (config.toml)
 
 ```toml
 [p2p]
@@ -59,7 +59,7 @@
 timeout-broadcast-tx-commit = "10s"
 ```
 
 #### Application Settings (app.toml)
 
 ```toml
 # Minimum gas prices to prevent spam transactions
@@ -97,7 +97,7 @@
 rs-backend = "pebbledb"
 ```
 
 ### Default Configurations
 
 The full unmodified `app.toml`, `config.toml`, and `client.toml` produced by
 `seid init` against the latest tagged `seid` release. Use these as the
@@ -216,12 +216,14 @@
 # WriteMode defines the write routing mode for EVM data in the SC layer.
 # Valid values: memiavl_only, migrate_evm, evm_migrated, migrate_all_but_bank,
 # all_migrated_but_bank, migrate_bank, flatkv_only, test_only_dual_write
-# defaults to memiavl_only
 sc-write-mode = "memiavl_only"
 
 # KeysToMigratePerBlock controls how many EVM keys the in-flight migration
 # (sc-write-mode = migrate_evm / migrate_bank / migrate_all_but_bank) drains
-# from memiavl into flatkv per block. Must be > 0; ignored when not migrating.
+# from memiavl into flatkv per block. Default 1024 is appropriate for
+# production drains; lower it (e.g. 256) to spread the migration across more
+# blocks for test runs that need to observe the resume / hybrid-read path.
+# Must be > 0; ignored entirely when not in a migration mode.
 sc-keys-to-migrate-per-block = 1024
 
 # Max concurrent historical proof queries (RPC /store path)
@@ -1361,7 +1363,7 @@
   </Tab>
 </Tabs>
 
 ## Database Management
 
 ### Architecture
 
@@ -1386,7 +1388,7 @@
 deprecated and slated for removal — new deployments and existing nodes
 should run on SeiDB.
 
 ### SeiDB Configuration
 
 The full set of knobs is in the auto-generated
 [Default Configurations](#default-configurations) above. The block below
@@ -1471,7 +1473,7 @@
 snapshot creation. Too-large (less frequent) intervals mean pruning takes
 longer overall, which can cause missed blocks and excessive resync time.
 
 ### Giga Storage and Giga Executor
 
 These are two **separate** opt-in features that ship in newer `seid`
 releases. Both default to off; only enable them deliberately and after
@@ -1497,6 +1499,22 @@
 sc-write-mode = "memiavl_only"
 ```
 
+<Note>
+The SC keys on this page are the **v6.6+** model (first tagged in
+`v6.6.0-rc1`). v6.5.x binaries use a different set — `sc-write-mode` =
+`cosmos_only` / `dual_write` / `split_write` plus `sc-read-mode` and
+`sc-enable-lattice-hash` — and each binary rejects the other line's
+`sc-write-mode` values at startup. When upgrading across v6.6, update or
+remove any explicit `sc-write-mode` in `app.toml`; the removed
+`sc-read-mode` / `sc-enable-lattice-hash` keys are ignored and can be
+deleted. Post-v6.6, on sei-chain `main`, the drain rate moves from
+`sc-keys-to-migrate-per-block` to the `NumKeysToMigratePerBlock`
+governance parameter (default `0` = paused) and a new
+`sc-write-mode-enable-auto` (default `true`) derives the effective mode
+from on-disk migration state, ignoring the explicit key — expect these
+knobs to change again in the release after v6.6.
+</Note>
+
 Enabling Giga Storage requires a fresh state sync — flipping `evm-ss-split`
 on a node with existing data fails the startup safety checks because
 the new EVM SS DB starts empty while Cosmos SS already has history. The
@@ -1517,7 +1535,7 @@
 occ_enabled = false
 ```
 
 ### Database Maintenance
 
 The database is typically stable and can be left alone, although some attention
 may be required:
@@ -1544,9 +1562,9 @@
 
 <Warning>The wipe command above deletes the entire local database (everything except `priv_validator_state.json`) and the `wasm` folder. It does not compact data in place — after running it, the node must be re-synced from a [snapshot](/node/snapshot) or via [state sync](/node/statesync) before it can serve traffic again.</Warning>
 
 ## Service Management
 
 ### Systemd Commands
 
 ```bash
 # Check service status
@@ -1565,7 +1583,7 @@
 journalctl -fu seid -o cat
 ```
 
 ### Log Management
 
 Prevent logs from consuming excessive disk space by enabling rotation:
 
@@ -1586,9 +1604,9 @@
 EOF
 ```
 
 ## Update Procedures
 
 ### Minor Updates
 
 For minor updates that are non-consensus-breaking:
 
@@ -1606,7 +1624,7 @@
 sudo systemctl restart seid
 ```
 
 ### Major Updates
 
 For major upgrades that introduce state-breaking changes:
 
@@ -1630,7 +1648,7 @@
   with minimal downtime.
 </Tip>
 
 ## Performance Optimization
 
 Performance optimizations can yield different results depending on your system's
 hardware, workload, and network conditions. Before implementing any changes,
@@ -1638,7 +1656,7 @@
 your specific configuration and requirements. Always back up important data
 before making modifications.
 
 ### Memory Management (sysctl tuning)
 
 Optimizing memory management settings can help improve performance and
 stability, particularly for high-load nodes. These settings control swap usage
@@ -1652,7 +1670,7 @@
 vm.dirty_writeback_centisecs = 100  # Frequency (in hundredths of a second) at which the system writes "dirty" pages to disk
 ```
 
 ### Network Stack Optimization
 
 Tuning the network stack can enhance packet processing efficiency and
 throughput, particularly for nodes handling a large number of peers and high
@@ -1666,7 +1684,7 @@
 net.core.wmem_max = 16777216  # send buffer size for network sockets
 ```
 
 ### Storage Optimization
 
 Optimizing storage settings can significantly reduce write latency and improve
 database performance, especially for nodes using NVMe SSDs.
@@ -1676,9 +1694,9 @@
 blockdev --setra 4096 /dev/nvme0n1  # readahead value to optimize sequential reads
 ```
 
 ## Backup and Recovery
 
 ### Regular Backups
 
 Automate backups to avoid data loss:
 
@@ -1697,7 +1715,7 @@
 systemctl start seid
 ```
 
 ### Recovery Procedure
 
 Restoring from backup in case of corruption or accidental deletion:
 
@@ -1715,7 +1733,7 @@
 systemctl start seid
 ```
 
 ## Security Considerations
 
 - Use firewalls and rate-limiting to prevent attacks
 - Keep your system and node software updated