Sei Technical Reference

Access detailed command syntax, configuration parameters, and troubleshooting procedures for node operators and validators running Sei network infrastructure.

This guide is a reference for Sei node operators and validators. It gives detailed command syntax, configuration parameters, and troubleshooting procedures. For API documentation, see the API Documentation section.

Command line interface reference

The seid binary has extensive functionality to manage 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:

If you see an error such as panic: recovered: runtime error: integer divide by zero, it means that you cannot start nodes directly from the genesis file. Instead, sync to the block tip with state sync or a snapshot.

# Start the node
seid start [flags]

# Show node status
seid status

# Show validator consensus key
seid tendermint show-validator

# Query node information
seid query node info

Experimental config manager (SEI_CONFIG_MANAGER)

The experimental SEI_CONFIG_MANAGER environment variable selects how seid loads its configuration. The value must match exactly.

• Unset or legacy: the default config loader.
• v2: boots the node the same way as legacy, from the same config.toml and app.toml, and also logs config validation warnings. It never changes your files, and the node always starts. v2 does not validate a new node on its first start, because its config files do not exist yet.
• Any other value: seid refuses to start with an invalid SEI_CONFIG_MANAGER error.

SEI_CONFIG_MANAGER=v2 seid start

Freeze mode (--freeze-height)

As of v6.6.3, you can put a full node into read-only freeze mode at a specified block height. Use the --freeze-height start flag or the corresponding freeze-height field in app.toml. Freeze mode exists for historical RPC nodes. A node frozen at an upgrade height keeps running the pre-upgrade binary and keeps serving the state that binary produced. It does not shut down at the boundary or execute the upgrade block with code that no longer matches that state.

Query RPC remains available, so the node can continue to serve 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). The EVM endpoint submits transactions through the same path, so eth_sendRawTransaction fails with the same error.
• Mempool gossip is disabled. The mempool reactor does not start, and the node does not advertise the mempool p2p channel to peers.
• State sync is disabled. If it is enabled in config.toml, the node logs a notice and falls back to block sync.

Block sync and consensus stop before they execute the configured height and do not advance beyond it.

The node must not have reached the freeze height yet. If the application, block store, or state store height is already at or above freeze-height, startup fails with <source> height <n> has already reached freeze height <h>. To build a frozen node, start from a data directory that is below the freeze height. This can be a fresh sync from genesis or a snapshot taken below that height. Then let block sync stop at the boundary.

# Start a full node in read-only freeze mode at a given block height
seid start --freeze-height <height>

You can configure the same behavior persistently with the freeze-height field. Its value is the first block height that a full node must not execute. A value of 0 disables freeze mode. The key is a top-level entry in app.toml, in the base configuration next to halt-height, not under any [section] header. The generated default app.toml shows the field in context.

# app.toml — top-level key in the base configuration (next to halt-height), not under any [section]
freeze-height = 0

Freeze mode is supported only for full nodes. In validator or seed mode, the node rejects a non-zero freeze-height at startup with an error (freeze height is not supported in <mode> mode). You also cannot combine freeze-height with halt-height, halt-time, or the --grpc-only start flag. The node rejects each combination at startup.

Frozen RPC router

The frozen-rpc-router binary, available as of v6.6.3, 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. It routes each request to the correct backend based on the block height that the request references. With the router, a set of archival nodes can collectively serve historical state through one endpoint. Each node is frozen at a different upgrade height and runs the binary that was live for its interval.

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. It sends height 100 to the next configured interval, or to the live node when no frozen interval covers it.

The router is a standalone binary in the sei-chain repository. It is not part of seid, and make install does not install it. Build it from a source checkout with the build-frozen-rpc-router target, which writes the binary to ./build/frozen-rpc-router:

git clone https://github.com/sei-protocol/sei-chain.git
cd sei-chain
git checkout <version-tag>  # v6.6.3 or later
make build-frozen-rpc-router

# Route between a live node and two frozen nodes. The router takes the default EVM
# HTTP RPC port (8545), so the live node and the frozen node that share this host
# have been moved to 9545 and 9546. The frozen node on 10.0.0.12 runs on its own
# host and keeps the default port.
./build/frozen-rpc-router \
  --listen-address 127.0.0.1:8545 \
  --live-node localhost:9545 \
  --frozen-node 1000000=localhost:9546 \
  --frozen-node 2000000=10.0.0.12:8545

If you bind the router to a public interface (for example, --listen-address 0.0.0.0:8545), put it behind a firewall or reverse proxy. Protect it as you would a node’s own EVM RPC port. The router has no authentication of its own, so anyone who can reach its listen address can query every backend behind it. The example binds to 127.0.0.1 so that only local clients can connect.

The binary accepts these flags:

• --listen-address: The address on which the router listens (default 127.0.0.1:8545).
• --live-node: The HTTP RPC address of the live node (required).
• --frozen-node: A freeze-height=ip:port pair. Repeat it once for each frozen node. The router accepts bare host:port addresses and http:// or https:// URLs. You may list frozen nodes in any order, but each freeze height must be positive and unique.
• --max-request-body-bytes: The maximum JSON-RPC request body size in bytes (default 5242880, which is 5 MiB). It must be positive. The router rejects larger requests with HTTP 413.
• --max-block-reference-depth: The maximum nested block reference depth (default 16). It limits how deeply nested blockNumber object references are parsed when the router resolves a request’s block parameter. It must be positive.
• --batch-request-limit: The maximum number of calls in a JSON-RPC batch (default 1000). It must be positive. The router rejects a batch over this limit with JSON-RPC error -32600 (batch too large).
• --write-timeout: The maximum duration to write an HTTP response (default 30s). It must be positive.
• --shutdown-timeout: The graceful shutdown timeout (default 10s). It must be positive.

Routing rules

The router inspects and routes only JSON-RPC POST requests. It passes every other request, including WebSocket upgrade requests, straight through to the --live-node address without inspection. That address is the live node’s HTTP RPC endpoint, which does not accept WebSocket upgrades. Clients that need subscriptions should therefore connect directly to the live node’s WebSocket port (8546 by default), not through the router.

• eth_* and debug_* methods that take an explicit block number or the earliest tag are routed to the interval that contains that height. Examples include eth_getBlockByNumber, eth_getBalance, eth_call, eth_getStorageAt, and debug_traceBlockByNumber. earliest resolves to height 0.
• eth_getLogs and eth_feeHistory are routed only when their entire block range falls within a single interval. The range is explicit for eth_getLogs. For eth_feeHistory, the router derives it from blockCount and newestBlock (newestBlock - blockCount + 1 through newestBlock, clamped at 0). The router rejects a range that crosses an interval boundary with JSON-RPC error -32000 (block ranges spanning multiple frozen-node intervals are not supported).
• An eth_getLogs filter that sets fromBlock but omits toBlock is treated as ending at latest. As a result, the router rejects it with the same -32000 error whenever fromBlock is inside a frozen interval. To stay within one interval, set toBlock explicitly. The reverse works: a filter that sets only toBlock is routed to the interval that contains toBlock.
• Requests with latest-style block tags (latest, pending, safe, finalized) are forwarded to the live node. So are requests that reference a block by hash, methods without a block parameter, and stateful filter methods.
• Batch requests are split so that each call reaches its correct backend, then reassembled into a single response.
• Calls whose backend cannot be reached return JSON-RPC error -32001 (upstream request failed).

Route header

Responses proxied to a single backend carry a Sei-RPC-Route header. The header identifies which backend served the response: frozen:<height> for the frozen node at that freeze height, or live for the live node. A batch split across multiple backends returns mixed. Router-generated errors (oversized or malformed requests, batches over the limit, block ranges that span intervals, and unreachable backends) do not carry the header. Neither does non-POST traffic that passes through to the live node.

seidb tooling commands

The seidb binary has low-level tools to inspect and maintain 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 intended mainly for integration and operator tooling that polls each validator to check whether the FlatKV EVM migration has completed. The tooling then needs no custom RPC handler and does not have to grep through node logs.

# Report FlatKV EVM migration status at the latest available version
seidb migrate-evm-status --db-dir <flatkv-dir>

# The --db-dir flag may be abbreviated as -d
seidb migrate-evm-status -d $HOME/.sei/data/state_commit/flatkv

# Report status at a specific FlatKV version (0 selects the latest)
seidb migrate-evm-status --db-dir <flatkv-dir> --height <n>

The command opens FlatKV read-only. It first hardlink-clones the latest snapshot and copies the WAL into a temporary directory. You can therefore run it safely against a directory that a live node is still writing to.

The emitted JSON contains these fields:

• version_at: The FlatKV version that was read.
• migration_version: The on-disk migration version (0 means that the FlatKV EVM migration has not completed yet).
• migrate_evm_complete: true after the migration version reaches the FlatKV EVM (v1) target.
• boundary_present: true while the migration is in flight (the in-progress resume cursor is still present).
• boundary_hex: The hex-encoded migration boundary cursor. It appears only when a boundary is present.
• version_raw_hex: The hex-encoded raw migration-version bytes. It appears 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). With this digest, you can compare a memIAVL node and a FlatKV node at the same chain height.

A freshly migrated FlatKV node stamps a per-key blockHeight into each value, and this stamp differs from the memIAVL leaf versions. As a result, 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. It then digests only the height-independent logical payload (storage word, bytecode, or balance+nonce+codehash) and produces a comparable FINAL_DIGEST for each backend.

# FlatKV digest at a height (WAL-replays to it). Prints per-bucket
# bucket_digest values and one FINAL_DIGEST line for backend comparison.
seidb evm-logical-digest --backend flatkv \
    --db-dir $HOME/.sei/data/state_commit/flatkv --height 213200000

# memIAVL digest at the same height (0 = current symlink), using the default
# semantic normalization. memiavl resolves snapshot-<height>/evm or current/evm
# and does not replay WAL in this tool.
seidb evm-logical-digest --backend memiavl \
    --db-dir $HOME/.sei/data/state_commit/memiavl --height 213200000

# Translator-based memIAVL digest, which feeds each leaf through the current
# migration mapping (flatkv.ImportTranslator).
seidb evm-logical-digest --backend memiavl \
    --db-dir $HOME/.sei/data/state_commit/memiavl --height 213200000 \
    --memiavl-normalization translator

Two backends match when the FlatKV FINAL_DIGEST equals the memIAVL FINAL_DIGEST. FlatKV can also hold two internal rows that a memiavl-only node never has: the migration-version marker and, during a migration, the migration boundary cursor. The command omits both rows from the final comparison.

The command accepts these flags:

• --backend: The backend to read: flatkv, memiavl, or composite. Use composite on a node in the middle of the migration. It digests the union of the FlatKV and memIAVL rows, so you can compare the node with a memiavl-only node at the same height.
• --db-dir (-d): For FlatKV, the FlatKV data directory. For memIAVL, the memIAVL root directory that contains current/ and snapshot-*. Required unless you use composite.
• --flatkv-dir and --memiavl-dir: The two data directories for --backend composite. You must set both in that mode.
• --height: The target version. FlatKV WAL-replays to it, and memIAVL resolves snapshot-<height>/evm (0 selects the current symlink).
• --memiavl-open-mode: How the command reads memIAVL. snapshot (the default) scans the snapshot file at --height. It is the fastest mode, but it needs a snapshot at that height, or --height 0. changelog reads the nearest snapshot at or below --height and adds the changelog’s EVM writes up to --height. replay opens the database, replays the changelog to --height, and walks the tree. It is about 10 times slower than snapshot. changelog and replay return the same rows. Use one of them when no snapshot exists at --height.
• --memiavl-normalization: The memIAVL normalization mode. Use semantic or independent for the raw EVM key-value decoder, or translator for the current migration mapping. The default is semantic.
• --json: Print the digest or inspect report as one JSON object on stdout, and the progress messages on stderr.
• --inspect-bucket: Inspect one normalized bucket (account, code, storage, or misc), not the global digest. Inspect mode with --memiavl-normalization translator, or with --details on the storage bucket, requires --memiavl-open-mode snapshot.
• --inspect-plan (inspect mode): A JSON file that lists several inspect reports to produce from one scan. It replaces the single-report inspect flags.
• --key-offset (inspect mode): The byte offset into the physical key, applied before --key-prefix or sharding.
• --key-prefix (inspect mode): A hex prefix, relative to --key-offset, that filters physical keys.
• --shard-next-bytes (inspect mode): Group matching keys by this many bytes after --key-prefix.
• --list (inspect mode): List pairs of matching keys and logical values instead of shard bucket_digest values.
• --list-limit (inspect mode): The maximum number of pairs to print with --list (default 1000). A value <= 0 means unlimited.
• --details (inspect list mode): Include backend-specific version metadata.
• --find-hash: An optional 32-byte hex per-entry hash to search for. When two bucket_digest values differ by exactly one entry, their XOR is the hash of that entry. This flag prints every matching entry, so you can locate a single diverging row.

Dumping FlatKV state and verifying its lattice hash

dump-flatkv writes every physical key-value pair of a FlatKV store to one file per bucket. The format matches dump-iavl, so the same diff tools work on both. The command can also compute the lattice hash (LtHash) of each bucket and of the whole store. Then it compares the total with the committed value in the snapshot metadata.

The command reads from a temporary read-only copy of the store, so you can run it against a live node. --read-limit-mb limits its disk reads, so it does not slow the node down.

# Latest version, all buckets, default 64 MiB/s read limit, LtHash check.
seidb dump-flatkv -d $HOME/.sei/data/state_commit/flatkv -o /tmp/flatkv-dump

# A specific height.
seidb dump-flatkv -d $HOME/.sei/data/state_commit/flatkv -o /tmp/flatkv-dump \
    --height 216890000

# Idle disk: no read limit and no LtHash.
seidb dump-flatkv -d $HOME/.sei/data/state_commit/flatkv -o /tmp/flatkv-dump \
    --read-limit-mb 0 --lthash=false

# Check the LtHash only, without writing dump files.
seidb dump-flatkv -d $HOME/.sei/data/state_commit/flatkv --lthash-only

The command accepts these flags:

• --db-dir (-d): The FlatKV data directory, which contains current/, snapshot-*, and changelog/. Required.
• --output-dir (-o): The directory for the dump files, one file per bucket. Required unless you set --lthash-only.
• --height: The target version. The default, 0, selects the latest version.
• --bucket (-b): Write only one bucket: account, code, storage, or misc. The command still scans every bucket, so the LtHash total stays valid.
• --lthash: Compute the LtHash and check it against the snapshot metadata. The default is true.
• --lthash-only: Check the LtHash, but do not write dump files. It requires --lthash=true. Do not use it with --bucket.
• --read-limit-mb: The maximum read speed in MiB/s. The default is 64, and 0 turns the limit off. Raise it only for offline runs.

With --lthash, the output lists the count and checksum of each bucket, the TOTAL, and a PASS or FAIL line. On a mismatch, the command prints TOTAL FAIL and stops with an error. The command skips the check when the snapshot has no committed LtHash to compare with.

Inspecting hash log archives

The seidb hashlog commands read the archives that the per-block hash logger writes. They do not change the archives.

get-block prints every hash recorded for one block. If the node executed the block more than once, for example after a rollback, the command prints each execution separately. A hash type that was not recorded for the block prints as <none>, or as null in JSON.

seidb hashlog get-block <archive> <block> [--json]

compare lists the blocks whose hashes differ between two archives, which shows where two nodes diverged. If the archives match over the compared range, the command reports that.

seidb hashlog compare <archive-a> <archive-b> [--low <N> --high <M>] [--max-diffs <N>] [--full] [--json]

• --low and --high: Compare only this block range (inclusive). Set both or neither.
• --max-diffs: The maximum number of blocks with differences to report. The default, -1, reports all of them. If the output stops at the limit, the command warns that more blocks can have differences.
• --full: Show every column for each block with differences. By default, the command shows only the columns that differ. Use --full when the archives hold a different number of records for a block.
• --json: Print JSON instead of text.

Autobahn (GigaRouter) config generation

When you use 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, so you must create it by hand with the node’s EVM RPC URL. If the file is missing, the command fails with an error. The mempool_size field is no longer part of autobahn.json. Remove it from existing config files.

# Generate an autobahn JSON config from one or more node directories
seid tendermint gen-autobahn-config [node-dirs...] --output <path>

# The --output flag may be abbreviated as -o
seid tendermint gen-autobahn-config ./node0 ./node1 ./node2 -o autobahn.json

# Choose where autobahn consensus state and BlockDB are persisted (default: data/autobahn)
seid tendermint gen-autobahn-config ./node0 ./node1 --output autobahn.json --persistent-state-dir data/autobahn

# Pass an empty value to disable persistence and run in-memory only (memblock)
seid tendermint gen-autobahn-config ./node0 ./node1 --output autobahn.json --persistent-state-dir=

# Tune BlockDB retention and GC
seid tendermint gen-autobahn-config ./node0 ./node1 --output autobahn.json --blockdb-retention 30s --blockdb-gc-period 10s

The --persistent-state-dir flag controls where Autobahn persists its consensus state and BlockDB across restarts. The default is data/autobahn, so persistence is on by default. The node resolves a relative path against its --home directory. An empty value (--persistent-state-dir=) turns persistence off, and Autobahn keeps everything in memory. If you set the flag, it fills the PersistentStateDir field in the generated config.

Autobahn stores blocks and commit quorum certificates in a LittDB-based BlockDB under <persistent_state_dir>/blockdb. Since v6.7.0, it no longer reads the old globalblocks/ and fullcommitqcs/ write-ahead log directories.

Two more flags tune the BlockDB. The command writes their values to the block_db section of autobahn.json:

• --blockdb-retention: The minimum age before the BlockDB can delete pruned records. The default is 30s, because this command targets local and Docker clusters. Pass an empty value (--blockdb-retention=) to omit the field and use the BlockDB default of 1 hour.
• --blockdb-gc-period: How often the BlockDB runs garbage collection, for example 10s. If you omit it, the BlockDB default applies.

"block_db": {
  "retention": "30s",
  "gc_period": "10s"
}

Both fields are optional. If you set a field, its value must be greater than zero. Autobahn ignores block_db when persistence is off.

The command reads these files from each node directory:

• 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 network address (host:port) that the node advertises to peers.
• evmrpc_url.txt: The node’s EVM RPC URL. It is written into the validator’s evmrpc field for cross-shard transaction proxying.

The validator_pubkey.txt and node_pubkey.txt files are written automatically next to priv_validator_key.json and node_key.json whenever those keys are saved. They are therefore usually already present in each node’s config directory.

The generated autobahn.json file describes the validator set, 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 make a node use the file, reference it from config.toml with the autobahn-config-file key.

Giga mode behavior and per-block limits

A node starts in Giga mode when autobahn-config-file is set in config.toml. In Giga mode, the block production and networking behavior differs significantly from standard Tendermint consensus:

• The CometBFT TxMempool is not used. Under Giga, the standard mempool and its gossip reactor are disabled entirely. Transactions route through the Autobahn producer-backed mempool instead.
• Consensus reactor, state sync, and block sync are disabled. In Giga mode, the node skips the consensus and state-sync reactors entirely. The block-sync reactor still runs without a syncer. State sync and block sync are both forced off, regardless of other configuration.
• Transactions are admitted through the producer mempool. The RPC broadcast endpoints call the producer’s InsertTx or TryInsertTx, not the CometBFT mempool’s CheckTx. BroadcastTx uses InsertTx, which blocks while the mempool is full. The async path calls TryInsertTx in the background and returns immediately. As a result, when the mempool is full, the transaction is silently dropped. The mempool is full error from TryInsertTx never reaches async callers.
• Sequential EVM nonce ordering is enforced. For EVM transactions, the producer mempool admits transactions strictly in nonce order per sender. A transaction whose nonce does not match the next expected nonce is rejected with a bad nonce error. Because admission is sequential, the mempool can track pending nonces (EvmNextPendingNonce) as callers submit them.

The producer enforces these limits on each Autobahn block payload as it fills a block:

• Maximum transactions per block: The lower of the configured max_txs_per_block and the built-in maximum of 2,000 (see the transaction payload caps below).
• Maximum total transaction bytes per block: A fixed per-block byte cap. A single transaction larger than this cap is rejected with a transaction too large error.
• Wanted gas per block (MaxGasWantedPerBlock): Derived from the genesis MaxGasWanted block param. A transaction whose GasWanted exceeds this per-block limit is rejected as too large.
• Estimated gas per block (MaxGasEstimatedPerBlock): Derived from the genesis MaxGas block param. A transaction whose (normalized) estimated gas exceeds this per-block limit is rejected as too large.

The producer seals the current block and starts a new one as soon as the next transaction would exceed a limit. This rule covers the transaction-count, byte, wanted-gas, and 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:

• Maximum validators per committee: The Autobahn committee has a hard limit of 100 validators (MaxValidators). Committee creation rejects any validator set over this limit with a too many validators error. It does not silently truncate the set.
• Bounded consensus network messages. Autobahn consensus protobuf messages carry declared size and count constraints. These constraints are checked against the raw wire bytes before the message is decoded. Payloads that violate them are rejected during decoding, before any allocation. This protects nodes from oversized or malformed inputs that could otherwise decode into much larger in-memory structures.

The enforced message constraints include:

• Per-field maximum sizes on fixed-width fields such as hashes, signatures, and public keys.
• Maximum repeated-field counts on validator-related lists. Signature and quorum-certificate lists are capped at 100 entries, which matches the 100-validator committee cap.
• Transaction payload caps: A block payload may carry at most 2,000 transactions. The combined transaction byte budget is exactly 2,048,000 bytes (2,000 × 1,024), and it may be split arbitrarily across the transactions in the payload. These are the built-in maxima that the per-block limits above refer to.

Any message whose fields exceed these limits is rejected at decode time, so an oversized network payload never reaches the consensus logic.

Giga replaces the CometBFT mempool, so Giga does not support the unsafe_flush_mempool RPC endpoint. The endpoint returns unsafe_flush_mempool is not supported with autobahn mempool.

HashVault app-hash equivocation guard

Under Autobahn, validators and fullnodes run HashVault by default. HashVault records the app hash of each finalized height before the node commits the state. If the node later tries to commit a different app hash for the same height, HashVault halts the node. Without HashVault, a validator can commit two different app hashes for one height. This can cause slashing.

HashVault stores the hashes in a Pebble database at <PersistentStateDir>/hashvault. When Autobahn runs in memory only, HashVault gives no protection and logs an error at startup.

If HashVault halts a node, follow HashVault app-hash equivocation panic before you restart it. As a last resort, the top-level hash-vault-disabled-unsafe key in config.toml turns HashVault off. Keep the default, false.

Key management

Proper key management is critical for security. Use these commands to manage your keys:

# Create new key
seid keys add <name> [flags]

# List all keys
seid keys list

# Delete key
seid keys delete <name>

# Export key (encrypted)
seid keys export <name>

# Import key
seid keys import <name> <keyfile>

# Show key address
seid keys show <name> -a

Transaction commands

These commands let you interact with Sei:

# Send tokens
seid tx bank send <from-key> <to-address> <amount>usei [flags]

# Delegate tokens
seid tx staking delegate <validator-addr> <amount>usei --from <delegator-key>

# Withdraw rewards
seid tx distribution withdraw-rewards <validator-addr> --from <delegator-key>

# Edit validator
seid tx staking edit-validator [flags] --from <validator-key>

Configuration parameters

Understanding configuration parameters is essential to optimize your node’s performance and security.

App.toml parameters

The app.toml file controls application-specific settings:

Complete app.toml configuration

# Minimum gas prices for transaction acceptance
minimum-gas-prices = "0.02usei"

# First block height a full node must not execute (read-only freeze mode).
# 0 disables freeze mode. Full nodes only; see "Freeze mode" above.
freeze-height = 0

# API configuration
[api]
enable = true
swagger = true
address = "tcp://0.0.0.0:1317"
max-open-connections = 1000

# State sync configuration
[state-sync]
snapshot-interval = 1000
snapshot-keep-recent = 2

# State store configuration
[state-store]
ss-enable = true
ss-backend = "pebbledb"
ss-keep-recent = 100000
ss-prune-interval = 600

# gRPC server configuration
[grpc]
enable = true
address = "0.0.0.0:9090"
# Maximum message size, in bytes, that the server accepts. Default 4 MiB.
max-recv-msg-size = 4194304
# Maximum number of simultaneous open connections. 0 means unlimited.
max-open-connections = 1000
# Duration after which an idle connection is closed. 0 means infinity.
max-connection-idle = "5m0s"
# Maximum duration a connection may exist before it is closed. 0 means infinity.
max-connection-age = "0s"
# Extra time after max-connection-age before the server closes the connection.
# 0 means infinity.
max-connection-age-grace = "0s"
# Interval after which, with no activity, the server pings the client for liveness.
keepalive-time = "2h0m0s"
# Duration the server waits for a keepalive ping ack before closing the connection.
keepalive-timeout = "20s"
# Minimum interval between client keepalive pings.
# The server penalizes clients that ping more often.
keepalive-min-time = "5m0s"
# Whether the server allows keepalive pings even when there are no active streams.
keepalive-permit-without-stream = false

If an older app.toml does not have these [grpc] keys, the node uses the defaults shown above, not unlimited values. A negative keepalive or connection-age duration falls back to its default.

Config.toml parameters

The config.toml file controls the core consensus engine and networking:

Complete config.toml configuration

# P2P Configuration
[p2p]
laddr = "tcp://0.0.0.0:26656"
external-address = ""
# bootstrap-peers holds seed/peer addresses (NodeID@host:port, comma-separated)
# dialled to populate the address book via PEX. As of v6.6.2, `seid init`
# auto-populates this field with the built-in Sei Labs seed nodes for
# well-known public networks (pacific-1, atlantic-2). Devnets (arctic-1) and
# unknown/private chains get none, and an existing bootstrap-peers value is
# never overwritten. The example below reflects a fresh init on an
# unrecognised chain.
bootstrap-peers = ""
persistent-peers = ""
upnp = false
max-connections = 100
max-outbound-connections = 20
max-packet-msg-payload-size = 1000000
handshake-timeout = "10s"
dial-timeout = "3s"
# How often the node accepts a new inbound connection. A larger interval paces
# the accept loop more slowly; if the kernel accept backlog outpaces it, arriving
# peers wait past handshake-timeout and the node silently stops acquiring inbound
# peers. In v6.6.2 this became configurable and the default accept rate rose from
# ~1/s to ~100/s (a "10ms" interval). A value of 0 disables the limiter; negative
# values are rejected during config validation.
accept-interval = "10ms"

# RPC Configuration
[rpc]
laddr = "tcp://0.0.0.0:26657"
cors-allowed-origins = []
cors-allowed-methods = ["HEAD", "GET", "POST"]
cors-allowed-headers = ["Origin", "Accept", "Content-Type", "X-Requested-With", "X-Server-Time"]
max-open-connections = 900
# timeout-broadcast-tx-commit is now enforced by the BroadcastTxCommit RPC: when set
# greater than 0 it is applied as a context timeout on the request, so a
# BroadcastTxCommit call will be cancelled if it does not complete within this duration.
timeout-broadcast-tx-commit = "10s"
# Maximum number of results returned by tx_search and block_search.
# Set to 0 to disable the cap (not recommended on public nodes).
max-tx-search-results = 10000
# Maximum number of KV index entries that all running tx_search and
# block_search requests may scan at once. The budget is shared by both
# indexers. When it runs out, searches fail with "kv indexer scan budget
# exceeded; narrow the query or retry later". Set to 0 to disable the cap
# (not recommended on public nodes).
max-search-scan-budget = 100000

# Mempool Configuration
[mempool]
size = 5000
max-txs-bytes = 1073741824
cache-size = 10000
# ttl-duration and ttl-num-blocks now treat zero (or unset) as "TTL purging disabled".
# A non-zero value defines the time / number of blocks after which a transaction
# is removed from the mempool; leaving them unset or set to zero disables TTL-based
# purging entirely.
ttl-duration = "5s"
ttl-num-blocks = 10

# Consensus Configuration
[consensus]
wal-file = "data/tendermint/cs.wal/wal"
# Consensus timeouts are governed by on-chain ConsensusParams; the old
# timeout-* keys were removed and produce a startup error if present.
# Local overrides are only possible via the unsafe-*-timeout-override
# keys, which take effect only when unsafe-overrides-enabled = true.
double-sign-check-height = 0

The [consensus] section may still parse a stateless-leader-election field, but the field is deprecated and ignored. Stateless (seed-based) leader election is always enabled, regardless of the value, so the field has no effect. It remains only for config-parsing compatibility, and you can safely omit it.

Out-of-process ABCI support was removed. The full node now runs only with Tendermint in-process. External standalone ABCI processes (socket or gRPC) are no longer supported. As a result:

• The seid start flags --address and --transport are deprecated and ignored.
• The Tendermint node flags --proxy-app and --abci are deprecated and ignored.
• The proxy-app and abci fields in config.toml are deprecated and ignored. Newly generated config.toml files no longer include them. If you upgrade a node and these lines are in your config.toml, delete them.

Network parameters

Understanding network parameters helps you operate your node effectively.

Chain parameters

These parameters define the network’s behavior:

Block Time: ~400ms target
Max Validators: 40
Unbonding Period: 21 days
Minimum Self Delegation: 1 SEI

Slashing Parameters:
  - signed_blocks_window:        108,000 blocks
  - min_signed_per_window:       5%   (validator must sign ≥5% of blocks in the window)
  - downtime_jail_duration:      10 minutes
  - slash_fraction_downtime:     0%   (no stake slash; jail only)
  - slash_fraction_double_sign:  0%   (no stake slash; double-signing still triggers
                                       permanent tombstoning)

Oracle Parameters:
  - min_valid_per_window:        0%   (default changed from 5% now that the Oracle
                                       Price Feeder is retired; distinct from the
                                       slashing module's min_signed_per_window above)

These values reflect the current on-chain parameters. For the source of truth, query them directly with seid query staking params and seid query slashing params. Per-validator settings (for example, commission rate and commission max change rate) are configured per validator and are not chain-level parameters.

Build tags

The historical_replay build tag makes a seid binary to replay old blocks. This binary accepts transaction bodies with non-canonical encoding. Normal binaries reject these bodies. The replay binary can therefore execute blocks from before that check existed.

make install BUILD_TAGS=historical_replay

A historical_replay binary is not safe for consensus. Do not use it to validate, produce blocks, or serve live traffic. Normal builds do not include the lenient decoder.

File locations

Understanding the purpose and location of important files helps with maintenance and troubleshooting:

$HOME/.sei/
├── config/
│   ├── app.toml         # Application configuration
│   ├── client.toml      # Client configuration
│   ├── config.toml      # Tendermint configuration
│   ├── genesis.json     # Chain genesis file
│   ├── node_key.json    # Node identity key
│   ├── node_pubkey.txt  # Node public key in autobahn format ("node:ed25519:public:<hex>"), written when the node key is saved
│   ├── priv_validator_key.json  # Validator signing key
│   └── validator_pubkey.txt  # Validator public key in autobahn format ("validator:<pubkey>"), written when the validator key is saved
├── data/
│   ├── application.db   # Application state
│   └── tendermint/     # Tendermint consensus DBs (new subdirectory layout)
│       ├── blockstore.db    # Block data
│       ├── cs.wal/          # Consensus write-ahead logs
│       ├── evidence.db      # Evidence of misbehavior
│       ├── peerstore.db     # Peer store
│       ├── state.db         # Tendermint state
│       └── tx_index.db      # Transaction index
└── keyring-file/       # Local key storage

New nodes place the Tendermint consensus databases (blockstore, state, tx_index, evidence, peerstore, and cs.wal) under data/tendermint/. Existing nodes with the legacy flat layout keep these databases directly under data/ (for example, data/blockstore.db and data/cs.wal/). These nodes continue to use the legacy paths automatically. The legacy location takes precedence when it is present, so no migration is required.

This reference guide gives essential technical information for operating Sei nodes and validators. For API documentation and other detailed specifications, see the relevant sections of this documentation.