Skip to main content
This guide covers the detailed operational aspects of running a Sei node, 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/:
The snippets below are opinionated tuning recommendations layered on top of the defaults. For the full unmodified app.toml, config.toml, and client.toml shipped by the latest tagged seid release, jump to Default Configurations at the bottom of this section.

Essential Configuration Parameters

Network Settings (config.toml)

The [rpc] section also supports max-tx-search-results, which caps the number of results returned by the tx_search and block_search RPC endpoints. The cap is applied after results are sorted by order_by, and the reported TotalCount reflects the post-cap count. The default is 10000. Set it to 0 to disable the cap entirely (not recommended on public nodes, since unbounded searches can be used to exhaust node resources). The value must not be negative.

Application Settings (app.toml)

SeiDB state-commit (SC) must be enabled; IAVL backend has been fully deprecated

Autobahn / GigaRouter (config.toml)

Autobahn (the GigaRouter consensus path) is enabled by pointing the autobahn-config-file field at a JSON file describing the validator committee and the consensus/producer parameters. Leave it empty (the default) to disable Autobahn entirely.
When autobahn-config-file is set the node loads its committee membership and block-production parameters from the referenced JSON file. The node must be a committee member: its own validator key and node key must appear in the validators list, otherwise startup fails.
Autobahn does not support remote validator signers. If autobahn-config-file is set together with priv-validator.laddr (a remote signer listen address), the node fails to start. A local validator key is required — non-validator (observer) nodes are not yet supported under Autobahn.
The referenced JSON file supports the following fields:
The mempool_size field has been removed from the Autobahn config and is no longer required by validation. Autobahn no longer reaps transactions from the shared CometBFT TxMempool; instead the block producer maintains its own mempool whose capacity is derived from the per-lane block budget (BlocksPerLane). This producer-backed mempool inserts EVM transactions in strict per-account nonce order and enforces the per-block gas-wanted and gas-estimated limits, so transactions with unexpected nonces or exceeding the size/gas limits are rejected at insertion time. The maximum gas per block is now derived from the genesis ConsensusParams.Block (MaxGas and MaxGasWanted) rather than a max_gas_per_block config field.

Mempool transaction TTL (config.toml)

Under the [mempool] section of config.toml, the transaction TTL settings control how long a transaction is allowed to remain in the mempool before it is purged. Both settings are now optional, and a value of 0 explicitly disables the corresponding TTL.
Previously a non-zero value enabled the corresponding TTL; now ttl-duration = 0 and ttl-num-blocks = 0 explicitly disable time-based and block-based TTL purging respectively. The defaults remain 5s and 10 blocks.
The separate pending TTL fields pending-ttl-duration and pending-ttl-num-blocks under [mempool] are now deprecated and have no effect. Pending TTL is no longer used by the mempool, so setting these fields does nothing. They are retained only for backward compatibility and may be removed in a future release; do not rely on them to expire pending transactions.
Expiration behavior differs between READY and PENDING transactions. remove-expired-txs-from-queue now governs whether expired READY transactions are pruned from the mempool queue. Expired PENDING transactions are always removed regardless of this setting.
When Autobahn is enabled, the node builds blocks directly from the shared TxMempool and disables the mempool gossip reactor, the consensus reactor, state sync, and block sync — those subsystems are not compatible with the GigaRouter consensus path. Each produced block is bounded by the on-chain caps of 2000 transactions and ~2 MB of total transaction bytes in addition to the max_gas_per_block and max_txs_per_block limits from the config file.

Monitoring under Autobahn

Enabling Autobahn changes what several CometBFT RPC endpoints report, because the CometBFT block store and consensus reactor are not fed on the GigaRouter path. Operators relying on status and monitoring endpoints should be aware of the following. /status additions The SyncInfo object returned by /status now includes a last_committed_block_height field (a JSON string-encoded integer) reporting the last block finalized by consensus:
  • Under CometBFT, commit and app-apply happen in a single step, so last_committed_block_height always equals latest_block_height.
  • Under Autobahn, the value is derived from the latest CommitQC. Consensus finalizes a block before the app executes it, so last_committed_block_height can briefly lead latest_block_height (the invariant is last_committed_block_height >= latest_block_height).
Under Autobahn, /status derives latest_block_height and latest_app_hash from the app layer (via ABCIInfo) rather than from the CometBFT block store, so these fields report live values instead of 0. Fields that remain unpopulated under Autobahn Because the CometBFT block store and consensus reactor are not fed, the following SyncInfo fields are not currently populated under Autobahn: latest_block_hash, latest_block_time, all earliest_* fields, and max_peer_block_height. catching_up is hardcoded to true. Block-data RPC endpoints under Autobahn The CometBFT block store and state store are not populated under Autobahn. Instead, /block, /block_by_hash, /block_results, and /validators are now served by routing through the GigaRouter’s in-memory finalized state, so these endpoints return real data on Autobahn nodes (previously they returned nil/empty because the block store height stayed at 0). Downstream consumers such as the EVM RPC endpoints (for example eth_getBlockByNumber) that walk through these endpoints keep working as a result. Be aware of the following Autobahn-specific limitations:
  • /block returns the finalized block translated from Autobahn’s in-memory state at the requested height. Only a subset of the CometBFT block fields are populated (block ID hash, chain ID, height, time, and the transaction list); fields such as AppHash, ProposerAddress, and LastCommit stay at their zero values.
  • /block_by_hash resolves a block by its header hash via an in-memory hash index that tracks the same retain window as /block. Unknown hashes, or hashes below the pruning watermark, return an empty block ({"block": null}) with no error, matching CometBFT semantics.
  • /block_results returns a valid-but-empty result at the requested height: TxsResults is intentionally empty because FinalizeBlock responses are not persisted under Autobahn, but ConsensusParamUpdates.Block.MaxGas is populated from the producer’s max_gas_per_block config so consumers relying on the gas limit keep working. Per-transaction execution details are not available.
  • /validators returns the genesis committee for any retained height, with block_height matching the requested height. (This fixes the prior behavior where the height could get stuck at 1 due to the unpopulated state store.)
Requesting a height that has already been pruned out of Autobahn’s retain window returns an ErrHeightNotAvailable-class error, mirroring the CometBFT path so external tooling sees consistent error shapes.
| block_interval | Target interval between blocks. Must be > 0. | | allow_empty_blocks | Whether to produce blocks when there are no transactions. | | view_timeout | Consensus view timeout. Must be > 0. | | persistent_state_dir | Directory used to persist the Autobahn consensus and data-layer write-ahead logs (WALs) across restarts. Both layers share this on-disk root and write to distinct subdirectories under it. Relative paths are resolved against the node’s --home directory at load time; absolute paths are used as-is. When generated via gen-autobahn-config this defaults to data/autobahn, so persistence is on by default. Set it to an empty value (or omit it entirely) to disable persistence and run both the consensus and data layers in-memory only. | | dial_interval | Interval between dial attempts to committee peers. Must be > 0. |

Generating the Autobahn config

Rather than hand-writing the validators list, you can generate the JSON config file from a set of node directories with the seid tendermint gen-autobahn-config command:
Each node-dir argument must contain four files describing that committee member:
  • validator_pubkey.txt — the validator public key in validator:<pubkey> format
  • node_pubkey.txt — the p2p node public key in node:ed25519:public:<hex> format
  • autobahn_address.txt — the node’s network address in host:port format
  • evmrpc_url.txt — the node’s EVM RPC HTTP URL (for example http://<node-ip>:8545, using the EVM RPC HTTP port from the [evm] section of app.toml). This is used to proxy EVM RPC requests to the validator that owns the sender’s EVM address shard.
The command reads these files from each directory, assembles the validators list, and writes a complete Autobahn JSON config (with default consensus and producer parameters) to the path given by --output (short flag -o). The --output flag is required. The validator_pubkey.txt and node_pubkey.txt files are produced automatically: whenever seid saves the validator private key (priv_validator_key.json) it also writes validator_pubkey.txt, and whenever it saves the node key (node_key.json) it also writes node_pubkey.txt, both in the same directory as the key file. You need to supply autobahn_address.txt and evmrpc_url.txt yourself. Point autobahn-config-file at the generated file to enable Autobahn.

EVM RPC request proxying

Each validator is assigned a shard of the EVM address space. When a node receives an eth_sendRawTransaction request, or an eth_getTransactionCount request for the pending block, it forwards (proxies) the request to the EVM RPC endpoint of the validator that owns the sender’s shard, using the evmrpc URL from that validator’s config entry. Requests whose sender maps to the local validator are handled locally. Proxied requests are counted by the evmrpc_redirected_requests_total telemetry metric (labeled with the endpoint and connection type). This is why every committee member must publish an evmrpc URL via evmrpc_url.txt.

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 canonical reference for every available knob and its default value.
Application-layer configuration: gas, API, gRPC, pruning, SeiDB, EVM, etc.

Database Management

Architecture

Sei stores chain data through SeiDB, a two-layer design that replaces the legacy single-database IAVL store with separate hot- and historical-data tiers:
  1. State Commit (SC) — the active chain state used for transaction execution and to compute the per-block app hash. Cosmos modules sit on a memory-mapped Merkle tree (memiavl) ported from Cronos. EVM state can additionally be routed through FlatKV, an EVM-tuned PebbleDB store with per-type sub-databases (account, code, storage, legacy, metadata). Routing is controlled by sc-write-mode / sc-read-mode and defaults to memiavl-only — FlatKV is only opened when one of those modes is set to a non-default value.
  2. State Store (SS) — versioned raw key/value pairs used for historical queries. Required for any node that serves RPC. The default backend is PebbleDB; RocksDB is available for iteration-heavy workloads such as archive nodes or RPC nodes that run a lot of debug_trace* (see the RocksDB Backend Guide for build instructions).
The legacy IAVL backend is still selectable via sc-enable = false but is 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 above. The block below covers the values most node operators tune in practice.
Setting small (more frequent) pruning intervals may collide with 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 following the relevant migration guide. Giga Storage repartitions SeiDB so EVM state lives in its own databases at both the SC and SS layers, freeing non-EVM modules from EVM write amplification.
For step-by-step instructions — including the full state-sync flow, startup verification, safety checks, and rollback — see the Giga SS Store Migration Guide. The snippet below is just the resulting app.toml shape.
Enabling Giga Storage requires a fresh state sync — flipping the EVM SS modes 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 full procedure is in the Giga SS Store Migration Guide and is currently supported on RPC nodes only; validators and archive nodes are not yet covered. Giga Executor is independent of Giga Storage. It swaps the EVM interpreter from go-ethereum’s geth to an evmone-based executor for higher throughput, with optional OCC parallelism on top:

Database Maintenance

The database is typically stable and can be left alone, although some attention may be required:
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 or via state sync before it can serve traffic again.

Service Management

Systemd Commands

Log Management

Prevent logs from consuming excessive disk space by enabling rotation:

Update Procedures

Minor Updates

For minor updates that are non-consensus-breaking:

Major Updates

For major upgrades that introduce state-breaking changes:
  1. Wait for the designated upgrade block height [this can be seen in the upgrade proposal under ‘plan’]
  2. The node will halt automatically.
  3. Update/replace the binary
  4. Restart the node.
Build the upgrade before the halt-height so you can quickly replace it with minimal downtime.

Performance Optimization

Performance optimizations can yield different results depending on your system’s hardware, workload, and network conditions. Before implementing any changes, research and test them in a controlled environment to ensure they align with 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 and the handling of dirty (unwritten) pages in RAM.

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 transaction volume.

Storage Optimization

Optimizing storage settings can significantly reduce write latency and improve database performance, especially for nodes using NVMe SSDs.

Backup and Recovery

Regular Backups

Automate backups to avoid data loss:

Recovery Procedure

Restoring from backup in case of corruption or accidental deletion:

Security Considerations

  • Use firewalls and rate-limiting to prevent attacks
  • Keep your system and node software updated
  • Secure SSH access with key-based authentication
  • Protect validator keys with offline storage or hardware security modules (HSMs)
For more in-depth system and configuration guidelines, refer to the Advanced Configuration and Monitoring Guide.