Runtime Configuration & Network Launch

This guide covers runtime configuration (app.toml, config.toml) and network launch procedures. Complete these steps after your genesis file is finalized.

Related Documentation:

Pre-Genesis & Genesis Setup - Initial configuration and genesis preparation
Configuration Reference - Commands, examples, and quick reference

Overview

Once you have your network configuation and genesis file ready, you can prepare to launch the network:

Configure Runtime Settings - Set node-specific parameters in app.toml and config.toml
Distribute Genesis File - Share the final genesis file with all validators
Launch Network - Coordinate the chain start across all validators
Monitor and Maintain - Ensure healthy network operation post-launch

Runtime Configuration

Runtime configuration is set in config files located at ~/.yourchain/config/. These settings can be changed after genesis and are node-specific.

Configuration Files

Three main configuration files control your node’s runtime behavior:

app.toml - Application settings including EVM parameters, JSON-RPC server, gas prices, and API endpoints. Changes require node restart.
config.toml - CometBFT (consensus) settings including P2P networking, consensus timeouts, and mempool configuration. Changes require node restart.
client.toml - CLI client defaults including chain-id, keyring backend, and output preferences. Changes take effect immediately.

app.toml Configuration

Located at ~/.yourchain/config/app.toml, this file controls application-level settings.

Minimum Gas Prices

Show More Details

Attribute	Value
Description	Node-level minimum gas price to accept transactions into mempool
File	`app.toml`
Section	Root level
Type	String
Format	`<amount><denom>`
Default	`"0aatom"`
Adjustable	Per Node (requires restart)
Source	`server/config/migration/v0.50-app.toml:11`
Why Configure	Protect against spam and ensure validators can cover operational costs

Configuration
Recommendations

Edit app.toml:

# Minimum gas prices for the node to accept transactions
minimum-gas-prices = "1000000000atoken"

Format: <amount><denom>Examples:

"1000000000atoken" = 1 gwei
"500000000atoken" = 0.5 gwei
"0atoken" = accept all transactions (not recommended)

How it works:

Node rejects transactions with gas price below this value
Protects against spam
Should align with genesis fee market min_gas_price

For 18-decimal tokens:

minimum-gas-prices = "1000000000atoken"  # 1 gwei

For 6-decimal tokens:

minimum-gas-prices = "1000utoken"  # 0.001 token

Testing/Development:

minimum-gas-prices = "0atoken"  # Accept all (not for production)

Production:

Set to at least expected minimum to prevent mempool spam
Can be higher than network minimum
Each validator can set their own value

JSON-RPC Configuration

Show More Details

Attribute	Value
Description	Ethereum-compatible RPC endpoints for EVM interactions
File	`app.toml`
Section	`[json-rpc]`
Type	Object containing multiple JSON-RPC configuration parameters
Default Ports	`8545` (HTTP), `8546` (WebSocket)
Default Address	`127.0.0.1:8545` (HTTP), `127.0.0.1:8546` (WebSocket)
Adjustable	Per Node (requires restart)
Source	`server/config/config.go:236-310`
Why Configure	Control API exposure, security settings, and performance limits

Standard Configuration
API Namespaces
Security Settings

[json-rpc]
# Enable JSON-RPC server
enable = true

# HTTP server address
# Use 127.0.0.1 for localhost only, 0.0.0.0 for public access
address = "0.0.0.0:8545"

# WebSocket server address
ws-address = "0.0.0.0:8546"

# API namespaces to enable
api = ["eth", "net", "web3", "txpool"]

# Gas cap for eth_call and eth_estimateGas
gas-cap = 25000000

# EVM execution timeout
evm-timeout = "5s"

# Transaction fee cap (in native token units)
txfee-cap = 1.0

# Maximum number of logs returned
logs-cap = 10000

# Maximum block range for queries
block-range-cap = 10000

# HTTP request timeout
http-timeout = "30s"

# HTTP idle timeout
http-idle-timeout = "2m0s"

# Allow unprotected transactions (only for development)
allow-unprotected-txs = false

# Maximum open connections (0 = unlimited)
max-open-connections = 0

# Enable indexer for historical queries
enable-indexer = false

Available Namespaces:

Namespace	Purpose	Production Use
`eth`	Standard Ethereum RPC	✅ Required
`net`	Network information	✅ Recommended
`web3`	Web3 client version	✅ Recommended
`txpool`	Transaction pool inspection	⚠️ Caution
`debug`	Debug/trace endpoints	❌ Dev only

Production configuration:

api = ["eth", "net", "web3"]

Development configuration:

api = ["eth", "net", "web3", "txpool", "debug"]

Note: The debug namespace can expose sensitive information and cause performance issues. Only enable for development.

For public RPC nodes:

# Bind to localhost only
address = "127.0.0.1:8545"
ws-address = "127.0.0.1:8546"

# Disable unprotected transactions
allow-unprotected-txs = false

# Limit connections
max-open-connections = 100

# Disable debug APIs
api = ["eth", "net", "web3"]

# Set reasonable caps
gas-cap = 25000000
logs-cap = 10000
block-range-cap = 10000

Security recommendations:

Use reverse proxy (nginx, traefik) for public access
Implement rate limiting at proxy level
Enable TLS/HTTPS
Monitor for abuse
Consider DDoS protection

Default Port: 8545 (HTTP), 8546 (WebSocket)

EVM Configuration

Show More Details

Attribute	Value
Description	EVM module settings including chain ID, tracer, and gas limits
File	`app.toml`
Section	`[evm]`
Type	Object containing multiple EVM configuration parameters
Default	Chain ID from config, no tracing, unlimited gas per tx
Adjustable	Per Node (requires restart); `evm-chain-id` is read-only
Source	`server/config/config.go:56-149`
Why Configure	Debug transactions, limit gas usage, control EVM behavior

Configuration
Parameter Details

[evm]
# EVM chain ID (set during init from config/config.go)
# Do not modify - change in source code before init
evm-chain-id = 262144

# Tracer type for debugging
tracer = ""

# Maximum gas limit for individual transactions
# 0 = unlimited
max-tx-gas-wanted = 0

# Cache preimages for historical queries
cache-preimage = false

# Minimum tip (priority fee) required
min-tip = 0

1. evm-chain-id (uint64) - Read-only

Automatically written during yourchain init
Value from config/config.go:78
Do not modify in app.toml
To change: Edit source code and rebuild before init

2. tracer (string)

Options: "json", "markdown", "struct", ""
"json": Detailed traces for debugging
"": No tracing (production recommended)

3. max-tx-gas-wanted (uint64)

0: Unlimited (default)
30000000: Example limit per transaction
Protects against excessive gas usage

4. min-tip (uint64)

Minimum priority fee in wei
0: Accept all transactions
1000000000: Require at least 1 gwei tip

EVM Mempool Configuration

Show More Details

Attribute	Value
Description	Transaction pool behavior including price limits, queue sizes, and lifetime
File	`app.toml`
Section	`[evm.mempool]`
Type	Object containing mempool configuration parameters
Default	1 wei price limit, 5120 global slots, 3 hour lifetime
Adjustable	Per Node (requires restart)
Source	`server/config/config.go:158-187`
Why Configure	Optimize mempool capacity, prevent spam, manage transaction lifetime

New in v0.5.0: Mempool configuration is now fully exposed in app.toml and can be adjusted without code changes.

Standard Configuration
Parameter Details

[evm.mempool]
# Minimum gas price to accept into pool (in wei)
price-limit = 1

# Minimum price bump % to replace existing transaction
price-bump = 10

# Executable transaction slots guaranteed per account
account-slots = 16

# Maximum executable slots for all accounts
global-slots = 5120

# Non-executable slots per account
account-queue = 64

# Non-executable slots for all accounts
global-queue = 1024

# Maximum time non-executable transactions stay queued
lifetime = "3h0m0s"

1. price-limit (uint64, wei)

Minimum gas price to accept into mempool
Default: 1 wei
Example: 1000000000 = reject txs below 1 gwei

2. price-bump (uint64, percentage)

Minimum % increase to replace transaction with same nonce
Default: 10 (10%)
Example: 20 = require 20% higher gas price

3. account-slots (uint64)

Guaranteed executable slots per account
Default: 16
Higher = more pending txs per account

4. global-slots (uint64)

Total executable slots across all accounts
Default: 5120
Higher = larger mempool capacity

5. account-queue (uint64)

Queued (non-executable) slots per account
Default: 64
For transactions with gaps in nonce sequence

6. global-queue (uint64)

Total queued slots across all accounts
Default: 1024

7. lifetime (duration)

Maximum time transaction stays in mempool
Default: "3h0m0s" (3 hours)
Format: Go duration (e.g., "1h30m", "24h0m0s")

Source: server/config/config.go:158-187

Advanced Mempool Configuration: For detailed information on integrating the EVM mempool, see the EVM Mempool Integration guide.

config.toml Configuration

Located at ~/.yourchain/config/config.toml, this file controls CometBFT (consensus layer) settings.

Persistent Peers

Show More Details

Attribute	Value
Description	List of nodes to maintain persistent connections to
File	`config.toml`
Section	`[p2p]`
Type	String (comma-separated list)
Format	`node_id@ip:port,node_id2@ip:port`
Default	`""` (empty - no persistent peers)
Default Port	`26656`
Adjustable	Per Node (requires restart)
Why Configure	Ensure validators stay connected to the network

Configuration
Getting Node IDs
Coordinator Sheet

Edit config.toml:

[p2p]
# Comma separated list of nodes to keep persistent connections to
persistent_peers = "node_id@ip:port,node_id2@ip:port"

Example:

persistent_peers = "7c90e16cca334eb7@192.168.1.100:26656,abc123def456@192.168.1.101:26656"

Each validator runs:

yourchain comet show-node-id

Output: 7c90e16cca334eb7259754f964918d879ca54996Share format:

Node ID: 7c90e16cca334eb7259754f964918d879ca54996
Public IP: 192.168.1.100
P2P Port: 26656 (default)
Connection string: 7c90e16cca334eb7@192.168.1.100:26656

Create a coordination sheet for validators:

Validator	Node ID	IP Address	P2P Port	Connection String
Validator 1	`7c90e16c...`	192.168.1.100	26656	`7c90e16c@192.168.1.100:26656`
Validator 2	`abc123de...`	192.168.1.101	26656	`abc123de@192.168.1.101:26656`
Validator 3	`def456ab...`	192.168.1.102	26656	`def456ab@192.168.1.102:26656`

Each validator updates their persistent_peers with all other validators.

Verification:

# Check connected peers
curl localhost:26657/net_info | jq '.result.peers'

Default P2P Port: 26656

Consensus Timeouts

Show More Details

Attribute	Value
Description	Timing parameters for consensus protocol
File	`config.toml`
Section	`[consensus]`
Type	Duration strings
Default	`"5s"` commit timeout (determines block time)
Adjustable	Per Node (requires restart)
Why Configure	Adjust block time, optimize for network conditions

Production
Development Settings
Parameter Explanation

Default values:

[consensus]
timeout_propose = "3s"
timeout_propose_delta = "500ms"
timeout_prevote = "1s"
timeout_prevote_delta = "500ms"
timeout_precommit = "1s"
timeout_precommit_delta = "500ms"
timeout_commit = "5s"

Typically you do not need to adjust these.

Faster block times for local development or testing:

[consensus]
timeout_propose = "2s"
timeout_propose_delta = "200ms"
timeout_prevote = "500ms"
timeout_prevote_delta = "200ms"
timeout_precommit = "500ms"
timeout_precommit_delta = "200ms"
timeout_commit = "1s"

These are the parameters used in ./local_node.sh.

Consensus Phases:

Propose: Block proposer broadcasts new block
Prevote: Validators vote on proposed block
Precommit: Validators commit to block
Commit: Block is finalized

Timeout Parameters:

timeout_propose: Time for proposer to broadcast block
timeout_prevote: Time to collect prevotes
timeout_precommit: Time to collect precommits
timeout_commit: Target block time
*_delta: Incremental increase per round

Trade-offs:

Shorter timeouts = faster blocks, but higher chance of timeouts on slow networks
Longer timeouts = more robust on slow networks, but slower blocks

Prometheus Metrics

Show More Details

Attribute	Value
Description	Enable metrics collection for monitoring
File	`config.toml`
Section	`[instrumentation]`
Type	Boolean + String (address)
Default	`false` (disabled), port `26660`
Adjustable	Per Node (requires restart)
Why Configure	Monitor node health, track performance metrics

[instrumentation]
# Enable Prometheus metrics
prometheus = true

# Prometheus listen address
prometheus_listen_addr = ":26660"

Access metrics:

curl http://localhost:26660/metrics

Enable for production to monitor node and overall network health.

client.toml Configuration

Located at ~/.yourchain/config/client.toml, this file configures client behavior.

Set Client Chain ID

Show More Details

Attribute	Value
Description	Chain ID for CLI client operations
File	`client.toml`
Section	Root level
Type	String
Default	`""` (empty - must be set manually)
Adjustable	Per Node (takes effect immediately)
Why Configure	Required for node startup - must match genesis chain ID

The node reads chain-id from client.toml at startup. If this doesn’t match genesis.json, the node will fail to start.

Configuration

yourchain config set client chain-id mychain-1 --home ~/.yourchain

Or edit client.toml directly:

chain-id = "mychain-1"

Other client settings:

# Keyring backend - This can be changed to "file", or "test" to create additional keys in different formats.
# "Test" creates an UNSAFE key that requires no password to submit txs for quicker iteration when testing.
keyring-backend = "os"

# Output format
output = "text"

# Node RPC address - This can be changed to a public endpoint to use the light client without syncing the full node.
node = "tcp://localhost:26657"

# Broadcast mode
broadcast-mode = "sync"

Network Launch

After all validators have configured their nodes, coordinate the network launch.

Pre-Launch Checklist

Show More Details

Finalize Genesis

All genesis parameters configured
Genesis validation passes
Genesis accounts and validators added
Genesis time set for future launch

Distribute Genesis

Share final genesis file with all validators
All validators verify genesis hash matches
No modifications allowed after distribution

Runtime Configuration

All validators configure app.toml
All validators configure config.toml
All validators set client.toml chain-id
Persistent peers exchanged

Pre-Launch Tests

Validators verify binary version
Validators test node starts without errors
Network connectivity verified
Monitoring systems ready

Distribute Genesis File

Show More Details

After finalizing your genesis file, distribute it to all validators.

GitHub Release
IPFS

Recommended for public networks:

# Coordinator creates release
gh release create v1.0.0-genesis \
  ~/.yourchain/config/genesis.json \
  --title "Genesis File" \
  --notes "Official genesis file for mychain-1"

# Validators download
wget https://github.com/yourorg/yourchain/releases/download/v1.0.0-genesis/genesis.json \
  -O ~/.yourchain/config/genesis.json

Recommended for decentralization:

# Coordinator uploads
ipfs add ~/.yourchain/config/genesis.json
# Returns: QmXyz123...

# Validators download
ipfs get QmXyz123... -o ~/.yourchain/config/genesis.json

Verify Genesis Hash

Show More Details

Critical: All validators must verify they have the identical genesis file.

Generate Hash
Coordination

Each validator runs:

jq -S -c . ~/.yourchain/config/genesis.json | shasum -a 256

Example output:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6  -

1. Coordinator publishes canonical hash:

# Generate and save hash
jq -S -c . ~/.yourchain/config/genesis.json | shasum -a 256 > genesis_hash.txt

# Publish hash via official channel
cat genesis_hash.txt

2. All validators verify:

# Each validator generates hash
jq -S -c . ~/.yourchain/config/genesis.json | shasum -a 256

# Compare with published hash

3. All validators confirm:

Report matching hash on official communication channel
Proceed only when all validators confirm

Exchange Peer Information

Show More Details

Validators need each other’s peer information to connect.

Collect Information
Update Config
Verification

Each validator provides:

# Get node ID
yourchain comet show-node-id
# Output: 7c90e16cca334eb7259754f964918d879ca54996

# Share:
# - Node ID: 7c90e16cca334eb7259754f964918d879ca54996
# - Public IP: 192.168.1.100
# - P2P Port: 26656 (default)

Format for sharing:

7c90e16cca334eb7259754f964918d879ca54996@192.168.1.100:26656

Each validator updates config.toml:

# Edit ~/.yourchain/config/config.toml
# Add all other validators to persistent_peers

[p2p]
persistent_peers = "7c90e16c@192.168.1.100:26656,abc123de@192.168.1.101:26656,def456ab@192.168.1.102:26656"

Remove your own node ID from the list (nodes don’t connect to themselves).

After starting nodes, verify connectivity:

# Check number of connected peers
curl localhost:26657/net_info | jq '.result.n_peers'

# List connected peers
curl localhost:26657/net_info | jq '.result.peers[].node_info.moniker'

# Check peer details
curl localhost:26657/net_info | jq '.result.peers'

Expected: Each validator should connect to all other validators.

Coordinate Launch Time

Show More Details

Set and coordinate the exact launch time across all validators.

Set Genesis Time
Launch Timeline
Validator Experience

Coordinator sets future genesis time:

jq '.genesis_time = "2024-12-01T00:00:00Z"' \
  ~/.yourchain/config/genesis.json > tmp && mv tmp ~/.yourchain/config/genesis.json

Timing recommendations:

Testnet: 1-2 hours ahead (allows validator setup)
Mainnet: 24-48 hours ahead (allows thorough preparation)
Local dev: Past time (starts immediately)

Example launch timeline:

T-48h: Announce genesis time to all validators
T-24h: Distribute final genesis file
T-4h:  Validators complete configuration
T-2h:  All validators verify genesis hash
T-1h:  Validators start nodes (wait for genesis time)
T-30m: Monitor validator connections
T-0:   Genesis time - network starts automatically
T+10m: Verify all validators online and signing
T+1h:  Monitor network health

Validators start early:

# Start node before genesis time
yourchain start

# Node output while waiting:
Genesis time is in the future. Waiting...
Time until genesis: 29m 45s
...

# At genesis time:
Starting consensus...
INF finalizing commit of block hash=ABC123... height=1
INF finalizing commit of block hash=DEF456... height=2

Network automatically begins when genesis time is reached.

Start Validator Nodes

Show More Details

After configuration and coordination, start the nodes.

Start Command
Monitor Logs
Systemd Service

# Standard startup
yourchain start

# With log level
yourchain start --log_level info

# In background with systemd (recommended)
sudo systemctl start yourchain

# In background with nohup
nohup yourchain start > yourchain.log 2>&1 &

# Follow logs
yourchain start 2>&1 | grep "finalizing commit"

# Expected output:
INF finalizing commit of block hash=ABC123... height=1 module=consensus
INF finalizing commit of block hash=DEF456... height=2 module=consensus
INF finalizing commit of block hash=GHI789... height=3 module=consensus

Healthy signs:

Block height increasing
No error messages
Blocks finalizing every ~5-8 seconds

Create service file at /etc/systemd/system/yourchain.service:

[Unit]
Description=Cosmos EVM Chain
After=network-online.target

[Service]
User=yourchain
ExecStart=/usr/local/bin/yourchain start --home /home/yourchain/.yourchain
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl enable yourchain
sudo systemctl start yourchain

# Check status
sudo systemctl status yourchain

# View logs
sudo journalctl -fu yourchain -ocat

Verify Network Health

Show More Details

After launch, verify the network is operating correctly.

Block Production
Validator Participation
Network Connectivity
Health Check
RPC Endpoints

Check block height increasing:

# Via CometBFT RPC
curl localhost:26657/status | jq '.result.sync_info.latest_block_height'

# Via EVM RPC
curl http://localhost:8545 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Should see: Block height increasing over time.

Check validator set:

# Number of validators
curl localhost:26657/validators | jq '.result.validators | length'

# List validators
curl localhost:26657/validators | jq '.result.validators[].address'

# Check voting power
curl localhost:26657/validators | \
  jq '[.result.validators[].voting_power | tonumber] | add'

Should see: All expected validators present and voting.

Check peers:

# Number of connected peers
curl localhost:26657/net_info | jq '.result.n_peers'

# List connected peers
curl localhost:26657/net_info | jq '.result.peers[].node_info.moniker'

Should see: Connected to expected number of peers.

CometBFT health:

curl localhost:26657/health
# Returns: {}  (empty object = healthy)

Node status:

curl localhost:26657/status | jq '.result'

Shows:

Node info
Sync status
Latest block info
Validator info

Test JSON-RPC:

# Check chain ID
curl http://localhost:8545 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

# Get latest block
curl http://localhost:8545 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'

# Check gas price
curl http://localhost:8545 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'

Should see: Valid JSON responses with expected data.

Post-Launch Operations

After successful launch, maintain healthy network operation.

Validator Operations

Show Validator Operations

Unjail Validator
Edit Validator
Monitor Performance

If validator gets jailed for downtime:

# Check if jailed
yourchain query staking validator $(yourchain keys show validator --bech val -a)

# Unjail
yourchain tx slashing unjail \
  --from validator \
  --chain-id mychain-1 \
  --fees 1000000000000000000atoken

Update validator information:

yourchain tx staking edit-validator \
  --moniker "New Moniker" \
  --website "https://example.com" \
  --identity "keybase-id" \
  --details "Description" \
  --commission-rate 0.05 \
  --from validator \
  --chain-id mychain-1

Track validator performance:

# Check signing info
yourchain query slashing signing-info $(yourchain comet show-validator)

# Check delegations
yourchain query staking validator $(yourchain keys show validator --bech val -a)

# Check rewards
yourchain query distribution validator-outstanding-rewards \
  $(yourchain keys show validator --bech val -a)

Monitoring and Alerting

Show Monitoring and Alerting

Key Metrics
Common Issues

Monitor these metrics:

Block height - Should increase steadily
Peer count - Should maintain connections
Validator signing - Should sign every block
Memory/CPU usage - Should be stable
Disk space - Should have adequate free space

Prometheus metrics available at http://localhost:26660/metrics

Chain not producing blocks:

Check >= 2/3 voting power online
Verify network connectivity
Check validator logs for errors

Node out of sync:

May need to resync from genesis
Or use state sync (if configured)
Check peer connections

High memory usage:

Check mempool size
Monitor for transaction spam
May need to adjust app.toml settings

Validator missing blocks:

Check node is running
Verify network connectivity
Check slashing params

Backup and Recovery

Show Backup and Recovery

Backup Critical Data
Disaster Recovery

What to backup:

# Validator private key
cp ~/.yourchain/config/priv_validator_key.json /secure/backup/

# Node key
cp ~/.yourchain/config/node_key.json /secure/backup/

# Genesis file
cp ~/.yourchain/config/genesis.json /secure/backup/

Store securely:

Encrypted storage
Multiple locations
Offline backups
Access controls

If validator node fails:

Restore on new hardware:

IMPORTANT Never run two validators with same private key simultaneously (double-sign risk). Before putting your keys onto another running node make sure there is absolutely no chance of the previous one starting back up.

# Install binary
# Copy priv_validator_key.json
# Copy node_key.json
# Copy genesis.json
# Sync blockchain data

Sync options:

Full sync from genesis or snapshot (slow, not recommended in this case)
State sync from snapshot (fast)
Copy data directory from backup or additional node (if available)

Restart validator:

yourchain start

Next Steps

Your chain should now be launched and operational! If not, start the process over from the beginning, or contact us! Further resources:

Configuration Reference - Complete command reference and examples
VM Module Documentation - EVM configuration details
Cosmos SDK Documentation - General Cosmos SDK operations

Cosmos EVM

​Overview

​Runtime Configuration

​Configuration Files

​app.toml Configuration

​Minimum Gas Prices

​JSON-RPC Configuration

​EVM Configuration

​EVM Mempool Configuration

​config.toml Configuration

​Persistent Peers

​Consensus Timeouts

​Prometheus Metrics

​client.toml Configuration

​Set Client Chain ID

​Network Launch

​Pre-Launch Checklist

​Distribute Genesis File

​Verify Genesis Hash

​Exchange Peer Information

​Coordinate Launch Time

​Start Validator Nodes

​Verify Network Health

​Post-Launch Operations

​Validator Operations

​Monitoring and Alerting

​Backup and Recovery

​Next Steps

Overview

Runtime Configuration

Configuration Files

app.toml Configuration

Minimum Gas Prices

JSON-RPC Configuration

EVM Configuration

EVM Mempool Configuration

config.toml Configuration

Persistent Peers

Consensus Timeouts

Prometheus Metrics

client.toml Configuration

Set Client Chain ID

Network Launch

Pre-Launch Checklist

Distribute Genesis File

Verify Genesis Hash

Exchange Peer Information

Coordinate Launch Time

Start Validator Nodes

Verify Network Health

Post-Launch Operations

Validator Operations

Monitoring and Alerting

Backup and Recovery

Next Steps