Ignite CLI Documentation

IGNITE® CLI is a development tool designed to simplify building, testing, and launching blockchain applications. It is built on top of the Cosmos SDK and utilizes the CometBFT (formerly Tendermint) consensus engine.

Key capabilities include:

• Scaffolding: Rapidly generate modules, messages, CRUD operations, and IBC packets.
• Live Reloading: Real-time updates during blockchain node development and testing.
• Frontend Support: Templates available for Vue.js, React, Typescript, or Go.
• IBC Integration: Built-in support for Inter-Blockchain Communication via an integrated IBC relayer.
• Versatile Use Cases: Supports DeFi, NFTs, supply chain, smart contracts (EVM and WASM), and decentralized exchanges (DEXes).

The cosmosclient package provides a high-level client designed for querying Cosmos SDK chains and managing the lifecycle of transactions (building, signing, and broadcasting).

Use this package when you need to:

• Connect Ignite tooling to a running node to query status and block information.
• Build and broadcast SDK messages using shared settings for gas, fees, and keyring.
• Wait for transaction inclusion or inspect block transactions and events.

The cosmosver package provides utilities to parse, compare, and detect the Cosmos SDK version used in a chain project. It is useful for gating scaffolding, migrations, or version-specific features based on the detected SDK version.

import "github.com/ignite/cli/v29/ignite/pkg/cosmosver"

The gen-mig-diffs tool is used to manage and visualize code changes across multiple major versions of IGNITE®. It works by scaffolding blockchains using both an old and a new version of IGNITE® and then displaying the differences. This is particularly useful for understanding how scaffolded code changes between versions to help developers apply necessary updates to their projects.

gen-mig-diffs --output temp/migration --from v0.27.2 --to v28.3.0

In v28.0.0, the plugin system has been renamed to Apps. This change affects configuration files, directory structures, and CLI command names.

• Configuration File: Rename plugins.yml (or similar) to igniteapps.yml.
• Home Directory: The plugins configuration directory has moved from $HOME/.ignite/plugins to $HOME/.ignite/apps.
• Automatic Updates: You can automatically apply these updates by running ignite doctor within your blockchain application directory. Running it outside the directory will only update global apps.

In Cosmos SDK modules, state is managed using the collections package. This package provides type-safe, efficient ways to store and query data in the module store. IGNITE® scaffolds modules using this package, which includes collection types like collections.Map, collections.Item, and collections.List.

Key benefits include:

• Type Safety: Reduces runtime errors by enforcing types at compile time.
• Simplified API: Provides standard methods like Get, Set, and Has.
• Performance: Optimized for minimal overhead within the Cosmos SDK ecosystem.

The Manifest defines the identity and capabilities of your app. It is a protobuf message containing:

• name: The app name.
• shared_host: A boolean. If true, all apps of the same path loaded from the same configuration share a single app server. This is useful for long-running commands or maintaining shared execution context.
• commands: A list of new commands to add to the ignite CLI.
• hooks: A list of hooks to attach to existing ignite commands.

Use commands to add new functionality and hooks to extend existing functionality.

message Manifest {
  string name = 1;
  bool shared_host = 2;
  repeated Command commands = 3;
  repeated Hook hooks = 4;
}

Before installing, ensure your environment meets these requirements:

Operating Systems

• GNU/Linux
• macOS
• Windows Subsystem for Linux (WSL)

Go Environment

IGNITE® CLI is written in Go. You must have:

• Go version 1.24.1 or higher installed.
• Go environment variables (like GOPATH) set up correctly on your system.

Follow these patterns when working with the cosmosaccount package:

• Registry Reuse: Instantiate a single Registry with your desired WithKeyringBackend and WithHome options and reuse that instance for all subsequent key operations.
• Predictable Signers: Call EnsureDefaultAccount in setup paths where your application requires a predictable signer account.
• Address Resolution: Use Account.Address(prefix) to resolve addresses when your application utilizes non-default Bech32 prefixes.

Data backend adapters allow the collector to save and query collected data in different storage systems. Every adapter must implement the cosmostxcollector.adapter.Adapter interface.

A PostgreSQL implementation is provided via cosmostxcollector.adapter.postgres.Adapter. When using the PostgreSQL adapter, calling db.Init(ctx) will automatically create the required database tables if they do not exist.