Configuration Management
Directory Structure
The Sei node configuration is stored in$HOME/.sei/config/:
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)
Autobahn / GigaRouter (config.toml)
Autobahn (the GigaRouter consensus path) is enabled by pointing theautobahn-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.
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.
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.
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.
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_heightalways equalslatest_block_height. - Under Autobahn, the value is derived from the latest
CommitQC. Consensus finalizes a block before the app executes it, solast_committed_block_heightcan briefly leadlatest_block_height(the invariant islast_committed_block_height >= latest_block_height).
/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:
/blockreturns 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 asAppHash,ProposerAddress, andLastCommitstay at their zero values./block_by_hashresolves 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_resultsreturns a valid-but-empty result at the requested height:TxsResultsis intentionally empty becauseFinalizeBlockresponses are not persisted under Autobahn, butConsensusParamUpdates.Block.MaxGasis populated from the producer’smax_gas_per_blockconfig so consumers relying on the gas limit keep working. Per-transaction execution details are not available./validatorsreturns the genesis committee for any retained height, withblock_heightmatching the requested height. (This fixes the prior behavior where the height could get stuck at1due 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 thevalidators list, you can generate the JSON
config file from a set of node directories with the seid tendermint gen-autobahn-config command:
node-dir argument must contain four files describing that committee
member:
validator_pubkey.txt— the validator public key invalidator:<pubkey>formatnode_pubkey.txt— the p2p node public key innode:ed25519:public:<hex>formatautobahn_address.txt— the node’s network address inhost:portformatevmrpc_url.txt— the node’s EVM RPC HTTP URL (for examplehttp://<node-ip>:8545, using the EVM RPC HTTP port from the[evm]section ofapp.toml). This is used to proxy EVM RPC requests to the validator that owns the sender’s EVM address shard.
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 aneth_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 unmodifiedapp.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.
- app.toml
- config.toml
- client.toml
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:- 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 bysc-write-mode/sc-read-modeand defaults to memiavl-only — FlatKV is only opened when one of those modes is set to a non-default value. - 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).
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.Giga Storage and Giga Executor
These are two separate opt-in features that ship in newerseid
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.Database Maintenance
The database is typically stable and can be left alone, although some attention may be required: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:- Wait for the designated upgrade block height [this can be seen in the upgrade proposal under ‘plan’]
- The node will halt automatically.
- Update/replace the binary
- Restart the node.
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)