Configuration
App wiring (dependency injection), genesis state, and the operator-facing config files of a running chain.
Third-party documentation. This is independently authored analysis of the public Cosmos SDK codebase — not the official docs, and not reviewed or endorsed by the Cosmos SDK team.
Configuration
Configuring an SDK chain happens at two layers: how the application binary composes modules at build time, and what the operator tunes at runtime.
App wiring
Modern chains use app wiring — dependency injection declared in Go code (or an app.yaml in fully-declarative setups) that instantiates keepers and modules in dependency order. The wiring file is effectively the chain's composition root: adding a module means registering it here, wiring its store keys, and including it in genesis. Older chains do the same imperatively inside app.go.
Genesis state
genesis.json carries per-module sections (accounts, staking parameters, governance proposals). Launches, testnets, and upgrades all flow through export/import of this format — a chain restart is a genesis round-trip.
Operator configuration files
At runtime, node operators edit generated TOML: app.toml (SDK-level: minimum gas prices, pruning, telemetry, gRPC/JSON-RPC endpoints) and config.toml (CometBFT-level: p2p ports, peers, consensus timeouts). These are deployment concerns — they never affect state transitions.
Upgrades
The upgrade module's store loader enforces named upgrade heights; operators schedule an upgrade, ship a new binary containing migration handlers, and the chain halts-and-resumes deterministically at the boundary rather than forking off.