feat: fork Ignite CLI v29 as Mukan Ignite — remove cosmos-sdk restrictions

.dockerignore

@@ -0,0 +1 @@
+.git

.firebaserc

@@ -0,0 +1,14 @@
+{
+  "projects": {
+    "default": "igntservices"
+  },
+  "targets": {
+    "igntservices": {
+      "hosting": {
+        "docs.ignite.com": [
+          "igntservices-docs"
+        ]
+      }
+    }
+  }
+}

.gitattributes

@@ -0,0 +1 @@
+changelog.md merge=union

.github/CODEOWNERS

@@ -0,0 +1,5 @@
+# CODEOWNERS: <https://help.github.com/articles/about-codeowners/>
+
+# Primary repo maintainers
+
+* @ignite/cli-sdk-team

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,82 @@
+---
+name: Ignite CLI Bug Report
+about: Create a report to help identify and fix issues
+title: "FIX: "
+labels: type:bug
+assignees: ""
+---
+
+<!--
+Please adapt sections as needed while keeping core descriptions clear and detailed. These sections are guidance, but accurate information will help ensure effective handling of the issue or request.
+-->
+
+### Context:
+
+<!--
+Provide the background and context for the bug.
+Consider:
+- What were you trying to accomplish when you encountered the issue?
+- Were you following a specific tutorial, guide, or workflow?
+- Is this bug blocking you from continuing development, or is it a minor inconvenience?
+- Were there any recent changes to your environment (e.g., new versions of Ignite CLI, updates to your code, changes in dependencies)?
+- Was the issue related to a specific Ignite CLI command, chain configuration, or part of the Cosmos SDK?
+-->
+
+#### Describe the Bug:
+
+<!--
+Provide a clear and concise description of the bug, explaining what happened and how it deviates from expected behavior.
+
+Consider:
+- What specifically went wrong? (e.g., command failed, wrong output, unexpected behavior)
+- Is this a regression from a previous version or a new issue you've encountered?
+-->
+
+### Steps to Reproduce:
+
+<!-- Provide step-by-step instructions to reproduce the issue. Be as detailed as possible to help us replicate the bug. -->
+
+1.
+2.
+3.
+
+### Expected Behavior:
+
+<!--
+Describe what you expected to happen when following the steps outlined above.
+
+Consider:
+- What would the correct or expected output/behavior have been?
+- How should the CLI or chain have responded under normal circumstances?
+-->
+
+### Actual Behavior:
+
+<!--
+Describe what actually happened instead of the expected behavior.
+
+Consider:
+- Did the command fail, or did the behavior deviate from what you expected?
+- Were there any specific error messages or logs that appeared?
+- Did the issue affect your chain configuration, build process, or other aspects of development?
+-->
+
+### Environment Details:
+
+<!-- Provide details about your environment: OS, Ignite CLI version, etc. -->
+
+- **OS:**
+- **Ignite Version:** Provide the output of the `ignite version` command.
+- **Go Version:** Provide the output of the `go version` command.
+- **Other Relevant Tools:** (e.g., node, npm, or other dependencies, if applicable)
+
+### Notes:
+
+<!--
+Add any other context or information that might help us understand the issue, such as error logs, screenshots, or relevant code snippets.
+
+Consider:
+- Are there any logs or stack traces that might help diagnose the issue?
+- Is this issue tied to specific chain configurations, modules, or dependencies?
+- Have you attempted any workarounds or fixes?
+-->

.github/ISSUE_TEMPLATE/enhancement.md

@@ -0,0 +1,67 @@
+---
+name: Ignite CLI Enhancement Request
+about: Suggest improvements or updates to existing features
+title: "UPDATE: "
+labels: type:enh
+assignees: ""
+---
+
+<!--
+Please adapt sections as needed while keeping core descriptions clear and detailed. These sections are guidance, but accurate information will help ensure effective handling of the issue or request.
+-->
+
+### Context:
+
+<!--
+Provide the background and context for the enhancement request.
+
+Consider:
+- What part of the system are you looking to improve, and why?
+- Is this enhancement focused on performance, usability, developer experience, or another aspect of the tool?
+- Are you aiming to extend, refine, or refactor existing functionality?
+- Is this enhancement based on feedback from users, team discussions, or personal experience using the Ignite CLI?
+- Has the current functionality been problematic, confusing, or insufficient in some way?
+-->
+
+### Proposed Enhancement:
+
+<!--
+Provide a clear and concise description of the improvement or update.
+
+Consider:
+- How does this enhancement improve or optimize existing functionality?
+- Will this update require changes to existing commands, configuration files, or dependencies?
+- How will this benefit developers using Ignite CLI (e.g., better performance, improved usability, easier configuration)?
+-->
+
+#### Alternatives Considered:
+
+<!--
+List any alternative solutions or approaches you've considered and why they may not be suitable.
+
+Consider:
+- Could this be addressed through a different enhancement or workaround?
+- Would refactoring current code or extending existing functionality be better than introducing new features?
+- Are there risks or trade-offs involved with the proposed solution (e.g., complexity, maintenance burden)?
+-->
+
+### Desired Outcome:
+
+<!--
+Describe what success looks like after the enhancement is implemented.
+
+Consider:
+- What specific improvement should be evident? (e.g., reduced build times, better error handling, cleaner code)
+- How will this change be measured or evaluated (e.g., performance benchmarks, usability feedback)?
+-->
+
+### Notes:
+
+<!--
+Add any other relevant information or context that could help in implementing the enhancement request.
+
+Consider:
+- Are there specific examples or use cases that illustrate why this enhancement is important?
+- Can you provide any relevant diagrams, mockups, or code snippets?
+- Have you encountered any issues or challenges when using the existing feature that this enhancement would resolve?
+-->

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,73 @@
+---
+name: Ignite CLI Feature Request
+about: Suggest a new feature or component
+title: "INIT: "
+labels: type:feat, request
+assignees: ""
+---
+
+<!--
+Please adapt sections as needed while keeping core descriptions clear and detailed. These sections are guidance, but accurate information will help ensure effective handling of the issue or request.
+-->
+
+### Context:
+
+<!--
+Describe the context for the feature request. What problem are you trying to solve, or what opportunity are you aiming to capture?
+
+Consider:
+- Is this request about making it easier for developers to use the CLI?
+- Is it related to improving the user experience for bootstrapping Cosmos SDK chains?
+- Is this intended to solve an ongoing issue or pain point encountered during the development process?
+- Is this feature request in response to community feedback or specific needs identified during testing?
+
+If you're unsure whether this should be a feature request, consider starting a new Discussion topic instead. If this is more about generating ideas, brainstorming, or honing in on a solution, starting a discussion might be more appropriate.
+Refer to the guidelines in our [Contributing Guide](./CONTRIBUTING.md).
+-->
+
+### Proposed Solution:
+
+<!--
+Provide a clear and concise description of the solution or feature you would like to see implemented.
+
+Consider:
+- How will this solution be integrated into the existing Ignite CLI workflow?
+- Will this require changes to the configuration files (e.g., `config.yml`, `app.toml`)?
+- Are there any specific commands or flags that this feature would add or modify?
+- How will this feature impact the developer experience and the chain bootstrapping process?
+-->
+
+#### Alternatives Considered:
+
+<!--
+List any alternative solutions or approaches you've considered and why they may not be suitable.
+
+Consider:
+- Could this feature be an Ignite App instead of being part of the core CLI tool?
+- Would this require significant maintenance effort or ongoing support?
+- Is there existing functionality in the CLI or Cosmos SDK that could be extended or refactored instead of introducing new code?
+- Have you explored alternative patterns, third-party tools, or existing Cosmos modules that could address the need?
+- Would this feature introduce technical debt, and if so, what would be the trade-offs?
+-->
+
+### Expected Outcome:
+
+<!--
+Explain what success would look like. What behavior or result would indicate that this feature is working as expected?
+
+Consider:
+- What is the tangible impact of this feature? (e.g., faster setup times, easier customization, reduced developer friction)
+- What are the measurable improvements? (e.g., improved performance, enhanced flexibility)
+- What areas of the Ignite CLI or connected Cosmos SDK modules will this feature touch or improve?
+-->
+
+### Notes:
+
+<!--
+Include any other relevant information or context that could help in understanding the feature request, such as related issues, mockups, or potential use cases.
+
+Consider:
+- Are there related issues or bugs that this feature would resolve?
+- Can you provide any screenshots, diagrams, or code snippets to illustrate your request?
+- Is there a timeline or specific version where this feature should be prioritized?
+-->

.github/ISSUE_TEMPLATE/meta.md

@@ -0,0 +1,64 @@
+---
+name: Ignite CLI Meta Task
+about: Create a larger, multi-step task or initiative
+title: "META: "
+labels: epic
+assignees: ""
+---
+
+<!--
+Please adapt sections as needed while keeping core descriptions clear and detailed. These sections are guidance, but accurate information will help ensure effective handling of the issue or request.
+-->
+
+### Context:
+
+<!--
+Provide the background and context for this meta task.
+
+Consider:
+- What larger goal or initiative is this meta task addressing?
+- Why is it necessary to break this initiative into smaller sub-tasks or actions?
+- Is this meta task part of a larger project or roadmap, and how does it align with ongoing development priorities?
+- Are there specific milestones or deadlines associated with this meta task?
+-->
+
+### Acceptance Criteria:
+
+<!--
+Define what needs to happen for the entire meta task to be considered complete.
+
+Consider:
+- What are the concrete deliverables for each sub-task?
+- How will you know when the overall goal has been met?
+- Are there specific tests, benchmarks, or other criteria that need to be met for each sub-task to be considered complete?
+-->
+
+<!-- Break down the meta task into smaller, actionable tasks. Each task should be achievable on its own.
+
+- [ ] Task 1: Description of the task
+- [ ] Task 2: Description of the task
+- [ ] Task 3: Description of the task
+
+-->
+
+### Dependencies or Related Tasks:
+
+<!--
+List any dependencies or tasks that are related to this meta task.
+
+Consider:
+- Are there other issues, features, or enhancements that need to be completed before this meta task can begin?
+- Is this meta task dependent on any external factors such as third-party tools, upstream changes, or external collaborators?
+- Are there ongoing discussions or other meta tasks related to this one that should be tracked or considered?
+-->
+
+### Notes:
+
+<!--
+Include any relevant links, documentation, or other context that would help in completing this meta task.
+
+Consider:
+- Are there relevant design documents, architecture diagrams, or technical specs that should be referenced?
+- Are there specific constraints or challenges (e.g., time, resources, external dependencies) that could impact the completion of this meta task?
+- Are there potential blockers or risks that might need to be addressed as part of this meta task?
+-->

.github/ISSUE_TEMPLATE/release-tracker.md

@@ -0,0 +1,49 @@
+---
+name: Release tracker
+about: Create an issue to track release progress
+
+---
+
+<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ 
+v                            ✰  Thanks for opening an issue! ✰    
+v    Before smashing the submit button please review the template.
+v    Word of caution: poorly thought-out proposals may be rejected 
+v                     without deliberation 
+☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
+
+## QA
+
+- [ ] Tutorial tests verification
+- [ ] Test `serve` on suite of chains
+
+### Backwards compatibility
+
+<!-- List of tests that need be performed with previous
+versions of cli to guarantee that no regression is introduced -->
+
+### Other testing
+
+## Migration
+
+<!-- Link to migration document -->
+
+## Checklist
+
+<!-- Remove any items that are not applicable. -->
+
+- [ ] Update Ignite CLI version (see [#3793](https://github.com/ignite/cli/pull/3793) for example):
+  - [ ] Rename module version in go.mod to `/vXX` (where `XX` is the new version number).
+  - [ ] Update plugins go plush, protos and re-generate them
+  - [ ] Update documentation links (docs/docs)
+  - [ ] Update GitHub actions, goreleaser and other CI/CD scripts
+
+## Post-release checklist
+
+- [ ] Update [`changelog.md`](https://github.com/ignite/cli/blob/main/changelog.md)
+- [ ] Update [`readme.md](https://github.com/ignite/cli/blob/main/readme.md):
+  - [ ] Version matrix.
+- [ ] Update docs site:
+  - [ ] Add new release tag to [`docs/versioned_docs`](https://github.com/ignite/cli/tree/main/docs/versioned_docs).
+- [ ] After changes to docs site are deployed, check [docs.ignite.com/](https://docs.ignite.com/) is updated.
+
+____

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -0,0 +1,12 @@
+Please make sure to check the following for your PR:
+
+- [ ] This PR complies with the [contributing](../../contributing.md) guidelines.
+- [ ] Reviewed "Files changed" and left comments if necessary
+- [ ] Included relevant documentation changes.
+
+Ignite CLI team only:
+
+- [ ] I have updated the _Unreleased_ section in the changelog.md for my changes.
+- [ ] If the templates in `ignite/templates/files` have been changed, make
+  sure that the change doesn't need to be reflected in the
+  `ignite/templates/files-*` folders.

.github/codecov.yml

@@ -0,0 +1,33 @@
+coverage:
+  precision: 2
+  round: down
+  range: 70...100
+  status:
+    project:
+      default:
+        target: auto
+        threshold: 10%
+        informational: true
+    patch:
+      default:
+        informational: true
+
+comment:
+  layout: "reach, diff, files"
+  behavior: default
+  require_changes: true
+
+codecov:
+  notify:
+    wait_for_ci: false
+    
+ignore:
+  - "*.pb.go"
+  - "*.pb.gw.go"
+  - "*.md"
+  - "*.ts"
+  - "actions/"
+  - "assets/"
+  - "docs/"
+  - "integration/"
+  - "scripts/"

.github/dependabot.yml

@@ -0,0 +1,35 @@
+# To get started with Dependabot version updates, you'll need to specify which
+# package ecosystems to update and where the package manifests are located.
+# Please see the documentation for all configuration options:
+# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
+
+version: 2
+updates:
+  - package-ecosystem: "gomod"
+    directory: "/" # Location of package manifests
+    schedule:
+      interval: "daily"
+      time: "10:00"
+    labels:
+      - "dependencies"
+      - "component:go"
+      - "skip-changelog"
+    open-pull-requests-limit: 0
+
+  - package-ecosystem: "npm"
+    directory: "/docs" # Location of package manifests
+    schedule:
+      interval: "daily"
+      time: "10:00"
+    labels:
+      - "dependencies"
+      - "component:js"
+      - "skip-changelog"
+    open-pull-requests-limit: 0
+
+  - package-ecosystem: github-actions
+    directory: "/"
+    schedule:
+      interval: daily
+      time: "10:00"
+    open-pull-requests-limit: 0

.github/labeler.yml

@@ -0,0 +1,33 @@
+"component:ci":
+  - "!.github/labeler.yml"
+  - "!.github/labels.json"
+  - .github/**/*
+
+"component:docs":
+  - assets/**/*
+  - docs/**/*
+
+"component:tools":
+  - .actions/**/*
+  - .scripts/**/*
+
+"component:packages":
+  - ignite/pkg/**/*
+
+"component:cmd":
+  - ignite/cmd/**/*
+
+"type:services":
+  - ignite/services/**/*
+
+"component:templates":
+  - ignite/templates/**/*
+
+"type:internal":
+  - ignite/config/**/*
+  - ignite/internal/**/*
+  - ignite/version/**/*
+
+"component:configs":
+  - "!*.md"
+  - "*"

.github/labels.json

@@ -0,0 +1,72 @@
+[
+  {
+    "name": "bug",
+    "color": "d73a4a",
+    "description": "Something isn't working"
+  },
+  {
+    "name": "bug fix",
+    "color": "8a1d1c",
+    "description": "Functionality that fixes a bug"
+  },
+  {
+    "name": "dependencies",
+    "color": "5319e7",
+    "description": "Update to the dependencies"
+  },
+  {
+    "name": "docs",
+    "color": "0075ca",
+    "description": "Improvements or additions to documentation"
+  },
+  {
+    "name": "duplicate",
+    "color": "cfd3d7",
+    "description": "This issue or pull request already exists"
+  },
+  {
+    "name": "good first issue",
+    "color": "7057ff",
+    "description": "Good for newcomers"
+  },
+  {
+    "name": "help wanted",
+    "color": "008672",
+    "description": "Extra attention is needed"
+  },
+  {
+    "name": "breaking change",
+    "color": "a7327e",
+    "description": "Functionality that contains breaking changes"
+  },
+  {
+    "name": "don't merge",
+    "color": "b60205",
+    "description": "Please don't merge this functionality temporarily"
+  },
+  {
+    "name": "feature",
+    "color": "ffb703",
+    "description": "New update to Gno"
+  },
+  {
+    "name": "hotfix",
+    "color": "003049",
+    "description": "Major bug fix that should be merged ASAP"
+  },
+  {
+    "name": "info needed",
+    "color": "54eba0",
+    "description": "More information needed"
+  },
+  {
+    "name": "question",
+    "color": "fbca04",
+    "description": "Questions about Gno"
+  },
+  {
+    "name": "investigating",
+    "color": "8c008c",
+    "description": "This behavior is still being tested out"
+  }
+]

.github/mergify.yml

@@ -0,0 +1,33 @@
+queue_rules:
+  - name: default
+    queue_conditions:
+      - "#approved-reviews-by>1"
+      - base=main
+    merge_conditions:
+      - "#approved-reviews-by>1"
+    merge_method: squash
+    commit_message_template: |
+      {{ title }} (#{{ number }})
+      {{ body }}
+
+pull_request_rules:
+  - name: backport patches to v28.x.y branch
+    conditions:
+      - base=main
+      - label=backport/v28.x.y
+    actions:
+      backport:
+        branches:
+          - release/v28.x.y
+  - name: backport patches to v29.x.y branch
+    conditions:
+      - base=main
+      - label=backport/v29.x.y
+    actions:
+      backport:
+        branches:
+          - release/v29.x.y
+  - name: refactored queue action rule
+    conditions: []
+    actions:
+      queue:

.github/workflows/auto-author-assign.yml

@@ -0,0 +1,18 @@
+name: auto-author-assign
+
+on:
+  pull_request_target:
+    types: [ opened, reopened ]
+
+permissions:
+  pull-requests: write
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  assign-author:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: toshimaru/auto-author-assign@v2.1.1

.github/workflows/cl-enforcer.yml

@@ -0,0 +1,19 @@
+name: Changelog Enforcer
+on:
+  pull_request:
+    # The specific activity types are listed here to include "labeled" and "unlabeled"
+    # (which are not included by default for the "pull_request" trigger).
+    # This is needed to allow skipping enforcement of the changelog in PRs with specific labels,
+    # as defined in the (optional) "skipLabels" property.
+    types: [ opened, synchronize, reopened, ready_for_review, labeled, unlabeled ]
+
+jobs:
+  changelog:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: dangoslen/changelog-enforcer@v3
+        with:
+          changeLogPath: 'changelog.md'
+          missingUpdateErrorMessage: 'Please add an entry to the changelog.md file or add the "skip-changelog" label'
+          skipLabels: 'skip-changelog'
+          versionPattern: ''

.github/workflows/docs-deploy-preview.yml

@@ -0,0 +1,46 @@
+name: Docs Deploy Preview
+
+on:
+  pull_request:
+    paths:
+      - "docs/**"
+
+jobs:
+  build_and_deploy:
+    if: "${{ github.event.pull_request.head.repo.full_name == github.repository }}"
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Cache node_modules
+        uses: actions/cache@v4
+        with:
+          path: docs/node_modules
+          key: node_modules-${{ hashFiles('**/yarn.lock') }}
+
+      - name: Setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: yarn
+          cache-dependency-path: docs/yarn.lock
+
+      - name: Install Dependencies
+        run: yarn install
+        working-directory: ./docs
+
+      - name: Build
+        run: yarn run build
+        working-directory: ./docs
+
+      - name: Deploy
+        uses: FirebaseExtended/action-hosting-deploy@v0
+        with:
+          repoToken: "${{ secrets.GITHUB_TOKEN }}"
+          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_IGNTSERVICES }}"
+          expires: 7d
+          target: docs.ignite.com
+          projectId: igntservices
+          firebaseToolsVersion: v11.12.0

.github/workflows/docs-deploy.yml

@@ -0,0 +1,48 @@
+name: Docs Deploy
+
+on:
+  push:
+    branches:
+      - main
+
+concurrency:
+  group: ci-${{ github.ref }}-docs-deploy
+  cancel-in-progress: true
+
+jobs:
+  build_and_deploy:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Cache node_modules
+        uses: actions/cache@v4
+        with:
+          path: docs/node_modules
+          key: node_modules-${{ hashFiles('**/yarn.lock') }}
+
+      - name: Setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: yarn
+          cache-dependency-path: docs/yarn.lock
+
+      - name: Install Dependencies
+        run: yarn install
+        working-directory: ./docs
+
+      - name: Build
+        run: yarn run build
+        working-directory: ./docs
+
+      - name: Deploy
+        uses: FirebaseExtended/action-hosting-deploy@v0
+        with:
+          repoToken: "${{ secrets.GITHUB_TOKEN }}"
+          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_IGNTSERVICES }}"
+          channelId: live
+          target: docs.ignite.com
+          projectId: igntservices

.github/workflows/gen-docs-cli.yml

@@ -0,0 +1,34 @@
+name: Generate Docs
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  cli:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: 'stable'
+
+      - name: Generate CLI Docs
+        run: ./scripts/gen-cli-docs
+
+      - name: Create Pull Request
+        id: cpr
+        uses: peter-evans/create-pull-request@v7
+        with:
+          title: "docs(cli): update generated docs"
+          commit-message: "docs(cli): update generated docs"
+          body: ""
+          branch: feat/gen-cli-docs
+
+      - name: Check outputs
+        run: |
+          echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}"
+          echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}"
+

.github/workflows/gen-docs-config.yml

@@ -0,0 +1,38 @@
+name: Generate Config Doc
+on:
+  push:
+    paths:
+      - "ignite/config/chain/base/*"
+      - "ignite/config/chain/v*"
+    branches:
+      - main
+
+jobs:
+  cli:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: 'stable'
+
+      - name: Generate Config Doc
+        run: ./scripts/gen-config-doc
+
+      - name: Create Pull Request
+        id: cpr
+        uses: peter-evans/create-pull-request@v7
+        with:
+          title: "docs(config): update config doc"
+          commit-message: "docs(config): update config doc"
+          body: ""
+          branch: feat/gen-config-doc
+          add-paths: |
+            docs/
+
+      - name: Check outputs
+        run: |
+          echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}"
+          echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}"
+

.github/workflows/gen-docs-migration.yml

@@ -0,0 +1,34 @@
+name: Generate Migration Docs
+on:
+  release:
+    types: [published]
+  workflow_dispatch:
+
+jobs:
+  cli:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
+
+      - name: Generate Scaffold Migration Docs
+        run: ./scripts/gen-mig-diffs
+
+      - name: Create Pull Request
+        id: cpr
+        uses: peter-evans/create-pull-request@v7
+        with:
+          title: "docs(migration): update generated docs"
+          commit-message: "docs(migration): update generated docs"
+          body: ""
+          branch: feat/gen-migration-docs
+          add-paths: |
+            docs/
+
+      - name: Check outputs
+        run: |
+          echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}"
+          echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}"

.github/workflows/gen-docs-version.yml

@@ -0,0 +1,67 @@
+name: Docusaurus add version
+on:
+  release:
+    types: [published]
+
+jobs:
+  gen-docs-version:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Cache node_modules
+        uses: actions/cache@v4
+        with:
+          path: docs/node_modules
+          key: node_modules-${{ hashFiles('**/yarn.lock') }}
+
+      - name: Setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: yarn
+          cache-dependency-path: docs/yarn.lock
+
+      - name: Install Dependencies
+        run: yarn install
+        working-directory: ./docs
+
+      - name: Skip beta versions
+        continue-on-error: false
+        run: |
+          VERSION=${{ github.ref_name }}
+          if [[ $VERSION == *beta* ]]; then
+            echo "Skipping beta version"
+            exit 1
+          fi
+
+      - name: Generate docusaurus docs for major version
+        run: |
+          VERSION=${{ github.ref_name }}
+          if [[ $VERSION == v0* ]]; then
+            # If version starts with v0, use the patch version
+            DOCUSAURUS_VERSION=${VERSION:1}
+          else
+            # Otherwise, use the major version
+            MAJOR_VERSION=${VERSION%%.*}
+            DOCUSAURUS_VERSION=${MAJOR_VERSION:1}
+          fi
+
+          jq --arg version "v$DOCUSAURUS_VERSION" 'del(.[] | select(. == $version))' versions.json > versions.json.tmp
+          mv versions.json.tmp versions.json
+          rm -rf versioned_docs/version-v$DOCUSAURUS_VERSION
+          rm -rf versioned_sidebars/version-v$DOCUSAURUS_VERSION-sidebars.json
+          yarn run docusaurus docs:version v$DOCUSAURUS_VERSION
+        working-directory: ./docs
+
+      - name: Create Pull Request
+        uses: peter-evans/create-pull-request@v7
+        with:
+          title: "chore: docusaurus deploy version ${{ github.ref_name }}"
+          commit-message: "chore(docs): deploy version ${{ github.ref_name }}"
+          body: ""
+          base: main
+          branch: chore/docs/new-version
+          add-paths: |
+            docs/

.github/workflows/gh-cleanup-cache.yml

@@ -0,0 +1,29 @@
+name: cleanup caches by a branch
+on:
+  pull_request:
+    types:
+      - closed
+
+jobs:
+  cleanup:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Cleanup
+        run: |
+          gh extension install actions/gh-actions-cache
+
+          echo "Fetching list of cache key"
+          cacheKeysForPR=$(gh actions-cache list -R $REPO -B $BRANCH -L 100 | cut -f 1 )
+
+          ## Setting this to not fail the workflow while deleting cache keys.
+          set +e
+          echo "Deleting caches..."
+          for cacheKey in $cacheKeysForPR
+          do
+              gh actions-cache delete $cacheKey -R $REPO -B $BRANCH --confirm
+          done
+          echo "Done"
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          REPO: ${{ github.repository }}
+          BRANCH: refs/pull/${{ github.event.pull_request.number }}/merge

.github/workflows/go-formatting.yml

@@ -0,0 +1,29 @@
+name: Go formatting
+on:
+  push:
+    branches: [ main ]
+    paths:
+      - '**.go'
+
+jobs:
+  go-formatting:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Install Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: 'stable'
+
+      - name: Run make format
+        run: make format
+
+      - name: Create Pull Request
+        uses: peter-evans/create-pull-request@v7
+        with:
+          title: "chore: go formatting"
+          commit-message: "chore: go formatting"
+          body: ""
+          branch: chore/go-formatting

.github/workflows/janitor.yml

@@ -0,0 +1,16 @@
+name: Janitor
+# Janitor cleans up previous runs that are not completed for a given workflow
+# It cancels Sims and Tests
+# Reference the API https://api.github.com/repos/:org/:repo/actions/workflows to find workflow ids
+on:
+  pull_request:
+
+jobs:
+  cancel:
+    name: "Cancel Previous Runs"
+    runs-on: ubuntu-latest
+    timeout-minutes: 3
+    steps:
+      - uses: styfle/cancel-workflow-action@0.12.1
+        with:
+          access_token: ${{ github.token }}

.github/workflows/labeler.yml

@@ -0,0 +1,16 @@
+name: "Pull Request Labeler"
+on:
+  - pull_request_target
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  triage:
+    permissions:
+      contents: read
+      pull-requests: write
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/labeler@v4 # keep v4 due to unwanted behavior changes in later versions.

.github/workflows/link-checker-config.json

@@ -0,0 +1,34 @@
+{
+  "ignorePatterns": [
+    {
+      "pattern": "^https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request"
+    },
+    {
+      "pattern": "^https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax"
+    },
+    {
+      "pattern": "^https://docs.ignite.com/"
+    },
+    {
+      "pattern": "^http://localhost"
+    },
+    {
+      "pattern": "^index.md"
+    },
+    {
+      "pattern": "^https://docs.starport.network"
+    }
+  ],
+  "replacementPatterns": [
+    {
+      "pattern": "^/",
+      "replacement": "https://docs.ignite.com/"
+    }
+  ],
+  "baseUrl": "https://docs.ignite.com",
+  "projectBaseUrl": "https://docs.ignite.com",
+  "timeout": "20s",
+  "retryOn429": true,
+  "retryCount": 5,
+  "fallbackRetryDelay": "30s"
+}

.github/workflows/link-checker.yml

@@ -0,0 +1,22 @@
+name: Check links
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - release/*
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  markdown-link-check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: gaurav-nelson/github-action-markdown-link-check@1.0.16
+        with:
+          folder-path: "."
+          use-verbose-mode: "yes"
+          config-file: ".github/workflows/link-checker-config.json"

.github/workflows/proto-checker.yml

@@ -0,0 +1,30 @@
+name: Protobuf Files
+
+on:
+  pull_request:
+    paths:
+      - "proto/**"
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    steps:
+      - uses: actions/checkout@v4
+      - uses: bufbuild/buf-setup-action@v1.50.0
+      - uses: bufbuild/buf-lint-action@v1
+        with:
+          input: "proto"
+
+  break-check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: bufbuild/buf-setup-action@v1.50.0
+      - uses: bufbuild/buf-breaking-action@v1
+        with:
+          input: "proto"
+          against: "https://github.com/${{ github.repository }}.git#branch=${{ github.event.pull_request.base.ref }},ref=HEAD~1,subdir=proto"

.github/workflows/release-binary.yml

@@ -0,0 +1,36 @@
+name: Release Binaries
+
+on:
+  release:
+    types: [ published ]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  binary:
+    runs-on: ubuntu-latest
+    env:
+      working-directory: go/src/github.com/ignite/cli
+
+    steps:
+      - name: Set up Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: 'stable'
+
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          path: ${{ env.working-directory }}
+          fetch-depth: 0
+
+      - name: Run GoReleaser
+        uses: goreleaser/goreleaser-action@v6
+        with:
+          workdir: ${{ env.working-directory }}
+          version: '~> v2'
+          args: release --clean
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/release-docker.yml

@@ -0,0 +1,66 @@
+name: Release Docker Image
+
+on:
+  release:
+    types: [ published ]
+  schedule:
+    - cron: "0 0 * * *" # every day at midnight
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  check-latest-run:
+    runs-on: "ubuntu-latest"
+    steps:
+      - uses: octokit/request-action@v2.x
+        id: check_last_run
+        with:
+          route: GET /repos/${{github.repository}}/actions/workflows/release-docker.yml/runs?per_page=1&status=completed
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    outputs:
+      last_sha: ${{ fromJson(steps.check_last_run.outputs.data).workflow_runs[0].head_sha }}
+
+  docker:
+    name: Push Docker image to Docker Hub
+    if: needs.check-latest-run.outputs.last_sha != github.sha
+    runs-on: ubuntu-latest
+    needs: [ check-latest-run ]
+
+    steps:
+      - name: Check out the repo
+        uses: actions/checkout@v4
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Login to DockerHub
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Docker meta
+        id: meta
+        uses: docker/metadata-action@v5
+        with:
+          images: ignitehq/cli
+          # push to ignitehq/cli:latest on every push to master
+          # push to ignitehq/cli:vx.x.x on every release published
+          tags: |
+            type=raw,value=latest
+            type=semver,pattern=v{{version}}
+
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          push: true
+          context: .
+          platforms: linux/amd64,linux/arm64
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}

.github/workflows/release-homebrew.yml

@@ -0,0 +1,31 @@
+name: Publish Ignite to HomeBrew
+
+on:
+  release:
+    types: [published]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  homebrew:
+    name: Bump Homebrew formula
+    runs-on: ubuntu-latest
+    steps:
+      - name: Extract version
+        id: extract-version
+        # Strip a string prefix from the git tag name:
+        run: |
+          echo "tag-name=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT
+
+      - uses: mislav/bump-homebrew-formula-action@v3.3
+        with:
+          formula-name: ignite
+          formula-path: Formula/i/ignite.rb
+          homebrew-tap: Homebrew/homebrew-core
+          base-branch: master
+          download-url: https://github.com/ignite/cli/archive/refs/tags/${{ steps.extract-version.outputs.tag-name }}.tar.gz
+        env:
+          # the personal access token should have "repo" & "workflow" scopes
+          COMMITTER_TOKEN: ${{ secrets.COMMITTER_TOKEN }}

.github/workflows/release-nightly.yml

@@ -0,0 +1,79 @@
+name: Release nightly
+
+on:
+  schedule:
+    - cron: "0 0 * * *" # every day at midnight
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  check-latest-run:
+    runs-on: "ubuntu-latest"
+    steps:
+      - uses: octokit/request-action@v2.x
+        id: check_last_run
+        with:
+          route: GET /repos/${{github.repository}}/actions/workflows/release-nightly.yml/runs?per_page=1&status=completed
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    outputs:
+      last_sha: ${{ fromJson(steps.check_last_run.outputs.data).workflow_runs[0].head_sha }}
+
+  release-nightly:
+    if: needs.check-latest-run.outputs.last_sha != github.sha
+    runs-on: ubuntu-latest
+    needs: [check-latest-run]
+    env:
+      working-directory: go/src/github.com/ignite/cli
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Delete the nightly release
+        uses: dev-drprasad/delete-tag-and-release@v1.1
+        with:
+          tag_name: nightly
+          delete_release: true
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Push new nightly tag
+        uses: mathieudutour/github-tag-action@v6.2
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          custom_tag: nightly
+          tag_prefix: ""
+
+      - name: Create the new nightly release
+        uses: ncipollo/release-action@v1
+        with:
+          tag: nightly
+          name: nightly
+          body: "Install and move the CLI to your bin directory: `curl https://get.ignite.com/cli@nightly! | bash`"
+          prerelease: true
+
+  releases-binaries:
+    if: needs.check-latest-run.outputs.last_sha != github.sha
+    name: Release Go Binary
+    needs: [check-latest-run]
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        goos: [linux, darwin]
+        goarch: [amd64, arm64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: wangyoucao577/go-release-action@v1.53
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          project_path: "./ignite/cmd/ignite"
+          binary_name: "ignite"
+          asset_name: ignite-nightly-${{ matrix.goos }}-${{ matrix.goarch }}
+          release_name: "nightly"
+          goos: ${{ matrix.goos }}
+          goarch: ${{ matrix.goarch }}
+          ldflags: -s -w -X github.com/ignite/cli/v29/ignite/version.Version=nightly
+          retry: 10

.github/workflows/stats.yaml

@@ -0,0 +1,17 @@
+on:
+  schedule:
+    # Run this once per day, towards the end of the day for keeping the most
+    # recent data point most meaningful (hours are interpreted in UTC).
+    - cron: "0 23 * * *"
+  workflow_dispatch: # Allow for running this manually.
+
+jobs:
+  j1:
+    name: Ignite CLI Repository Statistics
+    runs-on: ubuntu-latest
+    steps:
+      - name: run-ghrs
+        uses: jgehrcke/github-repo-stats@v1.4.2
+        with:
+          ghtoken: ${{ secrets.ghrs_github_api_token }}
+

.github/workflows/test-cov.yml

@@ -0,0 +1,30 @@
+name: Test Coverage
+
+on:
+  schedule:
+    - cron: "0 0 * * *" # every day at midnight
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  test:
+    runs-on: $ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: main # change in release branches
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
+
+      - run: ./scripts/test-coverage
+
+      - name: Upload coverage to Codecov
+        uses: codecov/codecov-action@v5
+        with:
+          file: ./coverage.txt
+          fail_ci_if_error: false
+          verbose: true

.github/workflows/test-integration.yml

@@ -0,0 +1,79 @@
+name: Integration
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - release/*
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  pre-test:
+    runs-on: ubuntu-latest
+    outputs:
+      matrix: ${{ steps.set-matrix.outputs.matrix }}
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Finding files and store to output
+        id: set-matrix
+        run: echo "matrix=$({ cd integration && find . -type d ! -name testdata -maxdepth 1 -print; } | tail -n +2 | cut -c 3- | jq -R . | jq -cs .)" >> $GITHUB_OUTPUT
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
+
+      - name: Download Go modules
+        run: go mod tidy
+
+      - name: Upload prepared workspace
+        uses: actions/upload-artifact@v4
+        with:
+          name: workspace
+          path: .
+          retention-days: 1
+
+  integration:
+    name: test ${{ matrix.test-path }} on ${{ matrix.os }}
+    runs-on: ${{ matrix.os }}
+    needs: pre-test
+    if: fromJSON(needs.pre-test.outputs.matrix)[0] != null
+    continue-on-error: true
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest]
+        test-path: ${{ fromJson(needs.pre-test.outputs.matrix) }}
+    steps:
+      - name: Download prepared workspace
+        uses: actions/download-artifact@v5
+        with:
+          name: workspace
+          path: .
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
+
+      - name: Run Integration Tests
+        env:
+          GOTOOLCHAIN: local+path
+          GOSUMDB: off
+        run: go test -v -timeout 120m ./integration/${{ matrix.test-path }}
+
+  status:
+    runs-on: ubuntu-latest
+    needs: integration
+    if: always()
+    steps:
+      - name: Update result status
+        run: |
+          if [ "${{ needs.integration.result }}" = "failure" ]; then
+              exit 1
+          else
+              exit 0
+          fi

.github/workflows/test-lint.yml

@@ -0,0 +1,33 @@
+name: Lint
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - release/*
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  lint:
+    name: Lint Go code
+    runs-on: ubuntu-latest
+    timeout-minutes: 6
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: go.mod
+          cache: false
+
+      - uses: golangci/golangci-lint-action@v6
+        with:
+          version: v1.64.5
+          install-mode: goinstall
+          args: --timeout 10m
+          github-token: ${{ secrets.github_token }}
+          skip-save-cache: true

.github/workflows/test-semantic.yml

@@ -0,0 +1,16 @@
+name: Semantic PR
+
+on:
+  pull_request_target:
+    types:
+      - opened
+      - edited
+      - synchronize
+
+jobs:
+  semantic_pr:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/test.yml

@@ -0,0 +1,27 @@
+name: Test
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - release/*
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  test:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-latest]
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
+
+      - run: ./scripts/test

.gitignore

@@ -0,0 +1,12 @@
+scripts/**/nodetime-*
+**/testdata/**/go.sum
+**/testdata/go.sum
+dist/
+node_modules
+.DS_Store
+.idea
+.vscode
+docs/.vuepress/dist
+build/
+*coverage.*
+*.ign

.golangci.yml

@@ -0,0 +1,71 @@
+run:
+  tests: false
+
+linters:
+  disable-all: true
+  enable:
+    - bodyclose
+    - copyloopvar
+    - decorder
+    - depguard
+    - dogsled
+    - dupword
+    - errcheck
+    - errchkjson
+    - errorlint
+    - exhaustive
+    - gci
+    - goconst
+    - gocritic
+    - godot
+    - gofumpt
+    - revive
+    - gosec
+    - gosimple
+    - govet
+    - grouper
+    - ineffassign
+    - misspell
+    - nakedret
+    - nolintlint
+    - staticcheck
+    - reassign
+    - stylecheck
+    - typecheck
+    - unconvert
+    - usetesting
+    - thelper
+    - unused
+    - unparam
+    - misspell
+    - forbidigo
+
+linters-settings:
+  gci:
+    custom-order: true
+    sections:
+      - standard # Standard section: captures all standard packages.
+      - default # Default section: contains all imports that could not be matched to another section type.
+      - prefix(cosmossdk.io)
+      - prefix(github.com/cosmos/cosmos-sdk)
+      - prefix(github.com/cosmos/ibc-go
+      - prefix(github.com/cometbft/cometbft)
+      - prefix(github.com/ignite/cli)
+  forbidigo:
+    forbid:
+      - p: ^fmt\.Errorf$
+        msg: fmt.Errorf should be replaced by '"github.com/ignite/cli/ignite/pkg/errors"'
+  depguard:
+    rules:
+      main:
+        deny:
+          - pkg: "errors"
+            desc: Should be replaced by '"github.com/ignite/cli/ignite/pkg/errors"'
+          - pkg: "github.com/pkg/errors"
+            desc: Should be replaced by '"github.com/ignite/cli/ignite/pkg/errors"'
+
+issues:
+  exclude-dirs:
+    - ignite/ui
+  max-issues-per-linter: 0
+  max-same-issues: 0

.goreleaser.yml

@@ -0,0 +1,11 @@
+project_name: ignite
+builds:
+  - main: ./ignite/cmd/ignite
+    ldflags:
+      - -s -w -X github.com/ignite/cli/v28/ignite/version.Version={{.Tag}} # bump to v29? check which action is ran on tagging
+    goos:
+      - linux
+      - darwin
+    goarch:
+      - amd64
+      - arm64

Dockerfile

@@ -0,0 +1,51 @@
+# syntax = docker/dockerfile:1.2
+# WARNING! Use `DOCKER_BUILDKIT=1` with `docker build` to enable --mount feature.
+
+## prep the base image.
+#
+FROM golang as base
+
+RUN apt update && \
+    apt-get install -y \
+    build-essential \
+    ca-certificates \
+    curl
+
+# enable faster module downloading.
+ENV GOPROXY https://proxy.golang.org
+
+## builder stage.
+#
+FROM base as builder
+
+WORKDIR /ignite
+
+# cache dependencies.
+COPY ./go.mod . 
+COPY ./go.sum . 
+RUN go mod download
+
+COPY . .
+
+RUN --mount=type=cache,target=/root/.cache/go-build go install -v ./...
+
+## prep the final image.
+#
+FROM base
+
+RUN useradd -ms /bin/bash tendermint
+USER tendermint
+
+COPY --from=builder /go/bin/ignite /usr/bin
+
+WORKDIR /apps
+
+# see docs for exposed ports:
+#   https://docs.ignite.com/kb/config.html#host
+EXPOSE 26657
+EXPOSE 26656
+EXPOSE 6060 
+EXPOSE 9090 
+EXPOSE 1317 
+
+ENTRYPOINT ["ignite"]

LICENSE

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<https://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<https://www.gnu.org/licenses/why-not-lgpl.html>.

Makefile

@@ -0,0 +1,110 @@
+#! /usr/bin/make -f
+
+# Project variables.
+PROJECT_NAME = ignite
+DATE := $(shell date '+%Y-%m-%dT%H:%M:%S')
+HEAD = $(shell git rev-parse HEAD)
+LD_FLAGS =
+BUILD_FLAGS = -mod=readonly -ldflags='$(LD_FLAGS)'
+BUILD_FOLDER = ./dist
+
+## install: Install de binary.
+install:
+	@echo Installing Ignite CLI...
+	@go install $(BUILD_FLAGS) ./...
+	@ignite version
+
+## build: Build the binary.
+build:
+	@echo Building Ignite CLI...
+	@-mkdir -p $(BUILD_FOLDER) 2> /dev/null
+	@go build $(BUILD_FLAGS) -o $(BUILD_FOLDER) ./...
+
+## mocks: generate mocks
+mocks:
+	@echo Generating mocks
+	@go install github.com/vektra/mockery/v2
+	@go generate ./...
+
+
+## clean: Clean build files. Also runs `go clean` internally.
+clean:
+	@echo Cleaning build cache...
+	@-rm -rf $(BUILD_FOLDER) 2> /dev/null
+	@go clean ./...
+
+.PHONY: install build mocks clean
+
+## govet: Run go vet.
+govet:
+	@echo Running go vet...
+	@go vet ./...
+
+## govulncheck: Run govulncheck
+govulncheck:
+	@echo Running govulncheck...
+	@go tool golang.org/x/vuln/cmd/govulncheck ./...
+
+## format: Install and run goimports and gofumpt
+format:
+	@echo Formatting...
+	@go tool mvdan.cc/gofumpt -w .
+	@go tool golang.org/x/tools/cmd/goimports -w -local github.com/ignite/cli/v29 .
+	@go tool github.com/tbruyelle/mdgofmt/cmd/mdgofmt -w docs
+
+## lint: Run Golang CI Lint.
+lint:
+	@echo Running golangci-lint...
+	@go tool github.com/golangci/golangci-lint/cmd/golangci-lint run --out-format=tab --issues-exit-code=0
+
+lint-fix:
+	@echo Running golangci-lint...
+	@go tool github.com/golangci/golangci-lint/cmd/golangci-lint run --fix --out-format=tab --issues-exit-code=0
+
+.PHONY: govet format lint
+
+## proto-all: Format, lint and generate code from proto files using buf.
+proto-all: proto-format proto-lint proto-gen format
+
+## proto-gen: Run buf generate.
+proto-gen:
+	@echo Generating code from proto...
+	@buf generate --template ./proto/buf.gen.yaml --output ./
+
+## proto-format: Run buf format and update files with invalid proto format>
+proto-format:
+	@echo Formatting proto files...
+	@buf format --write
+
+## proto-lint: Run buf lint.
+proto-lint:
+	@echo Linting proto files...
+	@buf lint
+
+.PHONY: proto-all proto-gen proto-format proto-lint
+
+## test-unit: Run the unit tests.
+test-unit:
+	@echo Running unit tests...
+	@go test -race -failfast -v ./ignite/...
+
+## test-integration: Run the integration tests.
+test-integration: install
+	@echo Running integration tests...
+	@go test -race -failfast -v -timeout 60m ./integration/...
+
+## test: Run unit and integration tests.
+test: govet govulncheck test-unit test-integration
+
+.PHONY: test-unit test-integration test
+
+help: Makefile
+	@echo
+	@echo " Choose a command run in "$(PROJECT_NAME)", or just run 'make' for install"
+	@echo
+	@sed -n 's/^##//p' $< | column -t -s ':' |  sed -e 's/^/ /'
+	@echo
+
+.PHONY: help
+
+.DEFAULT_GOAL := install

README.md

@@ -0,0 +1,59 @@
+<h1 align="center">
+    <b>Mukan Ignite</b>
+</h1>
+
+<p align="center">
+  The sovereign development CLI for the <b>Mukan Network</b> stack, forked from Ignite CLI.
+</p>
+
+## Overview
+
+**Mukan Ignite** is a hard-fork of [Ignite CLI v29](https://github.com/ignite/cli), specifically patched for the Mukan Network sovereign blockchain stack. It removes hardcoded restrictions that prevent building chains with a custom SDK fork (like `mukan-sdk`).
+
+## What's Different?
+
+Ignite CLI normally enforces that your chain uses the **exact** `github.com/cosmos/cosmos-sdk` module path. This is an intentional restriction that breaks any project that uses a sovereign SDK fork.
+
+Mukan Ignite removes these restrictions with two surgical patches:
+
+### Patch 1 — `ignite/pkg/cosmosver/detect.go`
+Extended `CosmosSDKModulePathPattern` to also recognize `mukan-sdk` as a valid Cosmos SDK variant:
+```go
+// Before (Ignite CLI)
+CosmosSDKRepoName = "cosmos-sdk"
+
+// After (Mukan Ignite)
+CosmosSDKRepoName = "cosmos-sdk|mukan-sdk"  // also matches git.cw.tr/mukan-network/mukan-sdk
+```
+
+### Patch 2 — `ignite/version/version.go`
+Removed the version gate check that blocked sovereign SDK forks:
+```go
+// AssertSupportedCosmosSDKVersion — version check disabled for Mukan sovereign stack
+func AssertSupportedCosmosSDKVersion(v cosmosver.Version) error {
+    return nil  // All Mukan SDK versions are valid
+}
+```
+
+## Building from Source
+
+```bash
+git clone https://git.cw.tr/mukan-network/mukan-ignite
+cd mukan-ignite
+make install
+```
+
+## Usage
+
+Drop-in replacement for `ignite`. Use `mukan-ignite` wherever you'd use `ignite`:
+
+```bash
+mukan-ignite chain serve --reset-once
+mukan-ignite chain build
+```
+
+## License
+
+Licensed under the **GNU General Public License v3.0 (GPLv3)**.
+
+*Original Ignite CLI components remain under their respective Apache 2.0 licenses where applicable.*

actions/cli/Dockerfile

@@ -0,0 +1,4 @@
+FROM ignitehq/cli:latest
+
+# Set the github runner user and group id
+USER 1001:121

actions/cli/action.yml

@@ -0,0 +1,5 @@
+name: cli 
+description: Ignite CLI 
+runs:
+  using: docker
+  image: Dockerfile

actions/cli/readme.md

@@ -0,0 +1,23 @@
+# Ignite CLI Action
+
+This action makes the `ignite` CLI available as a Github Action.
+
+## Quick start
+
+Add a new workflow to your repo:
+
+```yml
+on: push
+
+jobs:
+  help:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Print Help 
+        uses: ignite/cli/actions/cli@main
+        with:
+          args: -h 
+```

actions/release/vars/action.yml

@@ -0,0 +1,50 @@
+name: vars 
+description: Outputs variables that can be useful while creating a release
+outputs:
+  should_release:
+    description: Indicates whether a release should be created or not
+    value: ${{ steps.vars.outputs.should_release }}
+  is_release_type_latest:
+    description: Shows if release type is latest (not a v* release) 
+    value: ${{ steps.vars.outputs.is_release_type_latest }}
+  tag_name:
+    description: Name of the tag that should be used for release
+    value: ${{ steps.vars.outputs.tag_name }}
+  tarball_prefix:
+    description: A prefix to use in tarball asset names
+    value: ${{ steps.vars.outputs.tarball_prefix }}
+runs:
+  using: "composite"
+  steps:
+    - id: vars 
+      run: |
+        repo_name=${GITHUB_REPOSITORY##*/}
+        ref_name=${GITHUB_REF##*/}
+        default_branch=$(git remote show origin | awk '/HEAD branch/ {print $NF}')
+
+        should_release=true
+        is_release_type_latest=false
+        tag_name=""
+
+        if [[ $GITHUB_REF == refs/tags/* ]]
+        then
+          tag_name=$ref_name
+        elif [[ $GITHUB_REF == refs/heads/* && $ref_name == $default_branch ]]
+        then
+          tag_name=latest
+          is_release_type_latest=true
+        else
+          should_release=false
+        fi
+
+        echo "should_release=$should_release" >> $GITHUB_OUTPUT
+        echo "is_release_type_latest=$is_release_type_latest" >> $GITHUB_OUTPUT
+        echo "tag_name=$tag_name" >> $GITHUB_OUTPUT
+        echo "tarball_prefix=$repo_name_$tag_name" >> $GITHUB_OUTPUT
+      shell: bash
+    - run: |
+        echo "- should_release: ${{ steps.vars.outputs.should_release }}"
+        echo "- is_release_type_latest: ${{ steps.vars.outputs.is_release_type_latest }}"
+        echo "- tag_name: ${{ steps.vars.outputs.tag_name }}"
+        echo "- tarball_prefix: ${{ steps.vars.outputs.tarball_prefix }}"
+      shell: bash

buf.yaml

@@ -0,0 +1,20 @@
+version: v2
+modules:
+  - path: proto
+    name: buf.build/ignitehq/cli
+lint:
+  use:
+    - STANDARD
+    - FILE_LOWER_SNAKE_CASE
+  except:
+    - COMMENT_FIELD
+    - RPC_REQUEST_STANDARD_NAME
+    - RPC_RESPONSE_STANDARD_NAME
+    - SERVICE_SUFFIX
+  disallow_comment_ignores: true
+breaking:
+  use:
+    - FILE
+  except:
+    - EXTENSION_NO_DELETE
+    - FIELD_SAME_DEFAULT

code_of_conduct.md

@@ -0,0 +1,125 @@
+# Contributor Covenant Code of Conduct
+
+## Our pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+    and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+    overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery and sexual attention or
+    advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+    address, without their explicit permission
+* Other conduct that could reasonably be considered inappropriate in a
+    professional setting
+
+## Enforcement responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting by using an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Report instances of abusive, harassing, or otherwise unacceptable behavior to the community leaders responsible for
+enforcement at
+<conduct@ignite.com>.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement guidelines
+
+Community leaders will follow these community impact guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This restriction
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary ban
+
+**Community impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent ban
+
+**Community impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from
+the [Contributor Covenant](https://www.contributor-covenant.org/version/2/0/code_of_conduct.html).
+
+Community impact guidelines are inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+See the [FAQ](https://www.contributor-covenant.org/faq) for answers to common questions about this code of
+conduct. [Translations](https://www.contributor-covenant.org/translations) are also available.

contributing.md

@@ -0,0 +1,306 @@
+# Contributing Guidelines
+
+Before submitting a PR to the Ignite CLI repository, please review and follow these guidelines to ensure consistency and smooth collaboration across the project.
+
+If you have suggestions or want to propose changes to these guidelines, start a new [Discussion topic](https://github.com/ignite/cli/discussions/new) to gather feedback.
+
+To contribute to docs and tutorials, see [Contributing to Ignite CLI Docs](https://docs.ignite.com/contributing).
+
+We appreciate your contribution!
+
+* [Contributing Guidelines](#contributing-guidelines)
+  * [Providing Feedback](#providing-feedback)
+  * [Opening Pull Requests (PRs)](#opening-pull-requests-prs)
+    * [Choosing a Good PR Title](#choosing-a-good-pr-title)
+    * [Reviewing Your Own Code](#reviewing-your-own-code)
+    * [Commit Guidelines \& Title Conventions](#commit-guidelines--title-conventions)
+    * [Do Not Rebase After Opening a PR](#do-not-rebase-after-opening-a-pr)
+  * [Contributing to Documentation](#contributing-to-documentation)
+    * [Ask for Help](#ask-for-help)
+  * [Prioritizing Issues with Milestones](#prioritizing-issues-with-milestones)
+  * [Issue Title Conventions and Labeling](#issue-title-conventions-and-labeling)
+  * [Go Code Style Guidelines](#go-code-style-guidelines)
+    * [Foundation: Uber Go Style Guide](#foundation-uber-go-style-guide)
+    * [Package Structure](#package-structure)
+      * [Utility Packages](#utility-packages)
+    * [Code Organization](#code-organization)
+      * [Type Definitions](#type-definitions)
+      * [Encapsulation](#encapsulation)
+    * [Comments](#comments)
+
+## Providing Feedback
+
+* Before opening an issue, search for [existing open and closed issues](https://github.com/ignite/cli/issues) to check if your question has already been addressed. If a relevant issue exists, consider commenting on it instead of opening a duplicate issue.
+* For feedback, questions, or suggestions, open a [Discussion topic](https://github.com/ignite/cli/discussions/new) to share your thoughts. Providing detailed information, such as use cases and links, will make the discussion more productive and actionable.
+
+* For quick questions or informal feedback, join the **#🛠️ build-chains** channel in the official [Ignite Discord](https://discord.com/invite/ignitecli).
+
+## Opening Pull Requests (PRs)
+
+Please review relevant issues and discussions before opening a PR to ensure alignment with ongoing work.
+
+### Choosing a Good PR Title
+
+* Keep PR titles concise (fewer than 60 characters).
+* Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines for structuring your titles. For example: `feat(services/chain)`, `fix(scaffolding)`, `docs(migration)`.
+* Your PR title should reflect the purpose of the changes and follow a consistent format.
+
+### Reviewing Your Own Code
+
+* Manually test your changes before submitting a PR or adding new commits.
+* Ensure all CI checks pass before requesting a review. Your PR should show **All checks have passed** with a green checkmark.
+
+### Commit Guidelines & Title Conventions
+
+* **Standardized Issue Prefixes:**  
+  Issue titles should begin with one of the following standardized prefixes, depending on the type of action being taken:
+
+  * **`FIX:`** for resolving bugs or problems within existing features.
+  * **`INIT:`** for creating new components, features, or initiatives.
+  * **`UPDATE:`** for making improvements or modifications to existing functionality.
+  * **`META:`** for larger, multi-step initiatives that consist of multiple tasks (e.g., epics).
+
+  **Examples:**
+
+  * `FIX: Resolve crash during chain initialization`
+  * `INIT: Add staking module to example chain`
+  * `UPDATE: Improve performance of block synchronization`
+  * `META: Overhaul user permissions system`
+
+* **Why Standardized Prefixes?**  
+  The use of standardized prefixes ensures that the focus is on what needs to be done, making the task clear and actionable. This approach avoids redundancy with Conventional Commits, which are used for PR titles and commit messages to capture the purpose of the change. By separating the action (described by the prefix) from the nature of the issue (captured by labels), we reduce duplication and improve clarity. For example, if the issue is labeled `type:bug`, there’s no need to state "bug" in the title—the `FIX:` prefix already implies that the task involves resolving a bug.
+
+* **Labels for Characteristics:**  
+  Labels are used to classify the characteristics, elements, and descriptors of the issue or initiative. Labels help clarify the type of issue, the component involved, and its priority or status, without cluttering the title. Here are some examples:
+
+  * **Type:** Describes the nature of the issue.
+
+    * `type:bug` – Something isn't working.
+    * `type:feat` – A new feature to be implemented.
+    * `type:refactor` – Refactoring code without adding features.
+
+  * **Component:** Specifies the part of the system the issue is related to.
+
+    * `component:scaffold` – Related to scaffolding configuration or logic.
+    * `component:frontend` – Related to frontend components.
+    * `component:network` – Related to networking features or configurations.
+
+  * **Status:** Indicates the current status of the issue or PR.
+    * `status:needs-triage` – Needs to be reviewed and prioritized.
+    * `status:blocked` – Cannot proceed until the blocking matter is resolved.
+    * `status:help wanted` – Additional input or attention is needed.
+
+### Do Not Rebase After Opening a PR
+
+* Avoid rebasing commits once a PR is open for review. Instead, add additional commits as needed.
+* Force pushes are acceptable only when the PR is in draft mode and hasn't been reviewed yet.
+
+PRs will be squashed into a single commit when merged, so don't worry about having too many commits during the review process. The final PR title will be used as the commit message.
+
+## Contributing to Documentation
+
+Changes to the Ignite CLI codebase often require updates to the corresponding documentation. Please ensure that you update relevant documentation when making code changes.
+
+* For changes to the [Developer Guide](https://docs.ignite.com/guide) and tutorials, update content in the `/docs/docs/02-guide` folder.
+* For changes to the [Ignite CLI Reference](https://docs.ignite.com/references/cli), update the `./ignite/cmd` package where the command is defined. Do not edit auto-generated docs under `docs/docs/08-references/01-cli.md`.
+
+### Ask for Help
+
+If you start a PR but cannot complete it for any reason, don’t hesitate to ask for help. Another contributor can take over and finish the work.
+
+## Prioritizing Issues with Milestones
+
+We use Git Flow as our branch strategy, with each MAJOR release linked to a milestone. Core maintainers manage the prioritization of issues on the project board to ensure that the most critical work is addressed first.
+
+* **Priority Labels (P0-P3):**  
+  Issues are classified based on their urgency and impact, which helps guide the team’s focus during each release cycle:
+
+  * **P0:** Urgent ("drop everything"); requires immediate attention and resolution. These issues take precedence over all other work.
+  * **P1:** High priority ("important matter"); important and should be addressed promptly, though not as immediately critical as P0 issues.
+  * **P2:** Medium priority ("sometime soon"); should be addressed but can be scheduled after P0 and P1 issues are resolved.
+  * **P3:** Low priority ("nice to have"); nice to have but can be deferred or addressed as time permits.
+
+* **Milestones and Workflow:**  
+  Each milestone represents a MAJOR release. Issues are assigned to milestones based on their priority and relevance to the release goals. The project board is used to track and manage the progress of these issues. This structured workflow ensures that urgent tasks (P0) are addressed immediately, while lower-priority tasks (P3) are handled as resources allow.
+
+* **Next Milestone:**  
+  The **Next** milestone is used for issues or features that are not tied to a specific release but are still relevant to the project’s roadmap. These issues will be addressed when higher-priority work has been completed, or as part of future planning.
+
+## Issue Title Conventions and Labeling
+
+To maintain consistency across issues and PRs, follow these guidelines for issue titles:
+
+* **Standardized Prefixes:** Begin with one of the standardized prefixes:
+
+  * `FIX:` for resolving bugs.
+  * `INIT:` for new components or projects.
+  * `UPDATE:` for improving or modifying existing features.
+  * `META:` for meta tasks involving multiple sub-tasks or actions.
+
+* **Labels for Characteristics:** Use labels to classify the nature of the issue, such as its type, component, or status. Labels help describe the various elements of the issue or task, making it easier to manage and prioritize.
+
+By combining standardized prefixes with well-organized labels, we maintain clarity, avoid redundancy, and ensure that issues and PRs are properly categorized and actionable.
+
+## Go Code Style Guidelines
+
+All Ignite repositories should follow the same Go code style guidelines to ensure consistency and maintainability across the codebase. This document outlines the coding style guidelines for Go code in this project.
+
+### Foundation: Uber Go Style Guide
+
+Our code style is based on the [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) with additional project-specific requirements outlined below. The Uber guide should be considered the baseline for all code style decisions unless explicitly overridden in this document.
+
+Key aspects from the Uber Go Style Guide that we emphasize:
+
+* Error handling best practices
+* Package naming conventions
+* Interface design principles
+* Consistent formatting and naming
+
+### Package Structure
+
+#### Utility Packages
+
+* **Avoid generic package names like `utils`**
+  
+  Instead, use specific names that describe the functionality:
+
+  ```
+  ❌ ignite/pkg/utils          // Too generic
+  ✅ ignite/pkg/cosmosutil     // Good: describes the domain
+  ✅ ignite/pkg/cosmosanalysis // Good: describes the purpose
+  ```
+
+* **Keep utility functions separate from application-specific code**
+  
+  Don't add utility functions to application-specific packages like `services`, `cmd`, or `integration`.
+  Place all utility-like packages under the `pkg` directory:
+
+  ```
+  ❌ ignite/cmd/util.go                // Don't put utilities in app-specific packages
+  ✅ ignite/pkg/cosmosmetrics/metrics.go // Good: utilities in dedicated packages
+  ```
+
+  This helps reduce the size of application-specific packages and makes the code easier to maintain.
+
+### Code Organization
+
+#### Type Definitions
+
+* **Group related types, variables, and constants together**
+  
+  Only group definitions when they are logically related:
+
+  ```go
+  // ❌ Bad: Single block with unrelated definitions
+  const (
+    MaxRetries = 3
+    DefaultTimeout = 30
+    LogFileName = "app.log"
+    DatabaseName = "mydb"
+  )
+  
+  // ✅ Good: Related constants grouped together
+  // retry related constants
+  const (
+    MaxRetries = 3
+    DefaultTimeout = 30
+  )
+  
+  // file related constants
+  const (
+    LogFileName = "app.log"
+    DatabaseName = "mydb"
+  )
+  ```
+
+#### Encapsulation
+
+* **Use optional functions with getters for restricted field access**
+  
+  To prevent direct manipulation of fields, use getters and optional function parameters:
+  
+  ```go
+  // ❌ Bad: Exposed fields can be manipulated directly
+  type Metrics struct {
+    Count int
+    LastUpdated time.Time
+  }
+  
+  // ✅ Good: Fields are private with getter methods
+  type Metrics struct {
+    count int
+    lastUpdated time.Time
+  }
+  
+  // GetCount returns the current count
+  func (m *Metrics) GetCount() int {
+    return m.count
+  }
+  
+  // GetLastUpdated returns when metrics were last updated
+  func (m *Metrics) GetLastUpdated() time.Time {
+    return m.lastUpdated
+  }
+  
+  // Optional function pattern
+  type MetricsOption func(*Metrics)
+  
+  // WithInitialCount sets the initial count
+  func WithInitialCount(count int) MetricsOption {
+    return func(m *Metrics) {
+      m.count = count
+    }
+  }
+  
+  // NewMetrics creates a new metrics instance with options
+  func NewMetrics(opts ...MetricsOption) *Metrics {
+    m := &Metrics{
+      count: 0,
+      lastUpdated: time.Now(),
+    }
+    
+    for _, opt := range opts {
+      opt(m)
+    }
+    
+    return m
+  }
+  ```
+  
+  Example usage of the above pattern:
+
+  ```go
+  // Create with defaults
+  metrics := NewMetrics()
+  
+  // Or with options
+  metrics := NewMetrics(
+    WithInitialCount(10),
+  )
+  
+  // Access via getter
+  count := metrics.GetCount()
+  ```
+
+### Comments
+
+* Comments should be lowercase, except for Go docs
+* Go docs should always start with the function name, capitalize the first letter, and end with a period
+
+  ```go
+  // ❌ Bad: incorrect godoc format
+  // this function increments the counter
+  func IncrementCounter(count int) int {
+    return count + 1
+  }
+  
+  // ✅ Good: proper godoc format
+  // IncrementCounter adds one to the provided count and returns the result.
+  func IncrementCounter(count int) int {
+    return count + 1
+  }
+  
+  // ✅ Good: regular comment is lowercase
+  // increment the counter by one
+  count++
+  ```

docs/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

docs/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/docs.go

@@ -0,0 +1,8 @@
+package docs
+
+import "embed"
+
+// Docs are IGNITE® CLI docs.
+//
+//go:embed docs
+var Docs embed.FS

docs/docs/01-welcome/01-index.md

@@ -0,0 +1,52 @@
+---
+slug: /welcome
+---
+
+import ProjectsTable from '@site/src/components/ProjectsTable';
+
+# Introduction to IGNITE® CLI: Your Gateway to Blockchain Innovation
+
+[IGNITE® CLI](https://github.com/ignite/cli) is a powerful tool that simplifies the journey of building, testing, and launching diverse blockchain applications. Developed on top of the [Cosmos SDK](https://docs.cosmos.network), the leading framework for blockchain technology, IGNITE® CLI is pivotal in streamlining the development process. It enables developers to focus on the unique aspects of their projects, from DeFi and NFTs to supply chain solutions and smart contracts.
+Beyond these, IGNITE® has been instrumental in a wide array of blockchain applications, ranging from VPNs and gaming platforms to blogs, oracle systems, and innovative consensus mechanisms. This demonstrates its versatility in supporting a broad spectrum of blockchain-based solutions.
+
+## Key Features of IGNITE® CLI
+
+- **Simplified Blockchain Development:** IGNITE® CLI, leveraging Cosmos SDK, makes building sovereign application-specific blockchains intuitive and efficient.
+- **Comprehensive Scaffolding:** Easily scaffold modules, messages, CRUD operations, IBC packets, and more, expediting the development of complex functionalities.
+- **Development with Live Reloading:** Start and test your blockchain node with real-time updates, enhancing your development workflow.
+- **Frontend Flexibility:** Utilize pre-built templates for Vue.js, React, Typescript or Go, catering to diverse frontend development needs.
+- **Inter-Blockchain Communication (IBC):** Seamlessly connect and interact with other blockchains using an integrated IBC relayer, a key feature of the Cosmos SDK.
+- **CometBFT Integration:** Built with the CometBFT consensus engine (formerly Tendermint), ensuring robust consensus mechanisms in your blockchain solutions.
+- **Cross-Domain Applications:** IGNITE® is perfectly suited for developing a diverse array of use cases across various sectors. These include DeFi, NFTs, supply chain management, smart contracts (both EVM and WASM), and decentralized exchanges (DEXes).
+
+## Embracing the Cosmos Ecosystem
+
+IGNITE® CLI is your entry point into the vibrant Cosmos ecosystem, a hub of innovation where you can explore a range of applications, from wallets and explorers to smart contracts and DEXes, all powered by CometBFT and the Cosmos SDK.
+This ecosystem is home to over [$100 billion worth of blockchain projects](https://cosmos.network/ecosystem/tokens/), showcasing the scalability and versatility of the technologies at play.
+
+## Projects using Tendermint and Cosmos SDK
+
+Many projects already showcase the Tendermint BFT consensus engine and the Cosmos SDK. Explore
+the [Cosmos ecosystem](https://cosmos.network/ecosystem/apps) to discover a wide variety of apps, blockchains, wallets,
+and explorers that are built in the Cosmos ecosystem.
+
+## Projects building with IGNITE® CLI
+
+<ProjectsTable data={[
+  { name: "Stride Labs", logo: "img/logo/stride.svg"},
+  { name: "KYVE Network", logo: "img/logo/kyve.svg"},
+  { name: "Umee", logo: "img/logo/umee.svg"},
+  { name: "MediBloc Core", logo: "img/logo/medibloc.svg"},
+  { name: "Cudos", logo: "img/logo/cudos.svg"},
+  { name: "Firma Chain", logo: "img/logo/firmachain.svg"},
+  { name: "BitCanna", logo: "img/logo/bitcanna.svg"},
+  { name: "Source Protocol", logo: "img/logo/source.svg"},
+  { name: "Sonr", logo: "img/logo/sonr.svg"},
+  { name: "Neutron", logo: "img/logo/neutron.svg"},
+  { name: "OKP4 Blockchain", logo: "img/logo/okp4.svg"},
+  { name: "Dymension Hub", logo: "img/logo/dymension.svg"},
+  { name: "Electra Blockchain", logo: "img/logo/electra.svg"},
+  { name: "OLLO Station", logo: "img/logo/ollostation.svg"},
+  { name: "Mun", logo: "img/logo/mun.svg"},
+  { name: "Aura Network", logo: "img/logo/aura.svg"},
+]}/>

docs/docs/01-welcome/02-install.md

@@ -0,0 +1,119 @@
+---
+sidebar_position: 1
+description: Steps to install IGNITE® CLI on your local computer.
+---
+
+# Install IGNITE® CLI
+
+You can run [IGNITE® CLI](https://github.com/ignite/cli) in a web-based IDE or you can install IGNITE® CLI on your local computer.
+
+## Prerequisites
+
+Be sure you have met the prerequisites before you install and use IGNITE® CLI.
+
+### Operating systems
+
+IGNITE® CLI is supported for the following operating systems:
+
+- GNU/Linux
+- macOS
+- Windows Subsystem for Linux (WSL)
+
+### Go
+
+IGNITE® CLI is written in the Go programming language. To use IGNITE® CLI on a local system:
+
+- Install [Go](https://golang.org/doc/install) (**version 1.24.1** or higher)
+- Ensure the Go environment variables are [set properly](https://golang.org/doc/gopath_code#GOPATH) on your system
+
+## Verify your IGNITE® CLI version
+
+To verify the version of IGNITE® CLI you have installed, run the following command:
+
+```bash
+ignite version
+```
+
+## Installing IGNITE® CLI
+
+To install the latest version of IGNITE® use [HomeBrew](https://formulae.brew.sh/formula/ignite) on macOS and GNU/Linux:
+
+```sh
+brew install ignite
+```
+
+### Install manually
+
+Alternatively, you can install the latest version of the `ignite` binary use the following command:
+
+```bash
+curl https://get.ignite.com/cli! | bash
+```
+
+This command invokes `curl` to download the installation script and pipes the output to `bash` to perform the
+installation. The `ignite` binary is installed in `/usr/local/bin`.
+
+IGNITE® CLI installation requires write permission to the `/usr/local/bin/` directory. If the installation fails because
+you do not have write permission to `/usr/local/bin/`, run the following command:
+
+```bash
+curl https://get.ignite.com/cli | bash
+```
+
+Then run this command to move the `ignite` executable to `/usr/local/bin/`:
+
+```bash
+sudo mv ignite /usr/local/bin/
+```
+
+On some machines, a permissions error occurs:
+
+```bash
+mv: rename ./ignite to /usr/local/bin/ignite: Permission denied
+============
+Error: mv failed
+```
+
+In this case, use sudo before `curl` and before `bash`:
+
+```bash
+sudo curl https://get.ignite.com/cli | sudo bash
+```
+
+To learn more or customize the installation process, see the [installer docs](https://github.com/ignite/installer) on
+GitHub.
+
+## Upgrading your IGNITE® CLI installation {#upgrade}
+
+Before you install a new version of IGNITE® CLI, remove all existing IGNITE® CLI installations.
+
+To remove the current IGNITE® CLI installation:
+
+1. On your terminal window, press `Ctrl+C` to stop the chain that you started with `ignite chain serve`.
+2. Remove the IGNITE® CLI binary with `rm $(which ignite)`.
+   Depending on your user permissions, run the command with or without `sudo`.
+3. Repeat this step until all `ignite` installations are removed from your system.
+
+After all existing IGNITE® CLI installations are removed, follow the [Installing IGNITE® CLI](#installing-ignite-cli)
+instructions.
+
+For details on version features and changes, see
+the [changelog.md](https://github.com/ignite/cli/blob/main/changelog.md)
+in the repo.
+
+## Build from source
+
+To experiment with the source code, you can build from source:
+
+```bash
+git clone https://github.com/ignite/cli --depth=1
+cd cli && make install
+```
+
+## Summary
+
+- Verify the prerequisites.
+- To set up a local development environment, install IGNITE® CLI locally on your computer.
+- Install IGNITE® CLI by fetching the binary using cURL or by building from source.
+- The latest version is installed by default. You can install previous versions of the precompiled `ignite` binary.
+- Stop the chain and remove existing versions before installing a new version.

docs/docs/01-welcome/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Welcome",
+  "link": null
+}

docs/docs/02-guide/02-introduction.md

@@ -0,0 +1,154 @@
+---
+sidebar_position: 2
+---
+
+# Introduction
+
+In this guide, we will be using IGNITE® CLI to create a new blockchain. IGNITE®
+CLI is a command line interface that allows users to quickly and easily create
+blockchain networks. By using IGNITE® CLI, we can quickly create a new blockchain
+without having to manually set up all the necessary components.
+
+Once we have created our blockchain with IGNITE® CLI, we will take a look at the
+directory structure and files that were created. This will give us an
+understanding of how the blockchain is organized and how the different
+components of the blockchain interact with each other.
+
+By the end of this guide, you will have a basic understanding of how to use
+IGNITE® CLI to create a new blockchain, and you will have a high-level
+understanding of the directory structure and files that make up a blockchain.
+This knowledge will be useful as you continue to explore the world of blockchain
+development.
+
+If you are looking for more tutorials and hands-on experience, check out our tutorials website:
+
+[IGNITE® Tutorials](https://tutorials.ignite.com)
+
+## Creating a new blockchain
+
+To create a new blockchain project with IGNITE®, you will need to run the
+following command:
+
+```
+ignite scaffold chain example
+```
+
+The `ignite scaffold chain` command will create a new blockchain in a new
+directory `example`.
+
+The new blockchain is built using the Cosmos SDK framework and imports several
+standard modules to provide a range of functionality. These modules include
+`staking`, which enables a delegated Proof-of-Stake consensus mechanism, `bank`
+for facilitating fungible token transfers between accounts, and `gov` for
+on-chain governance. In addition to these modules, the blockchain also imports
+other modules from the Cosmos SDK framework.
+
+The `example` directory contains the generated files and directories that make
+up the structure of a Cosmos SDK blockchain. This directory includes files for
+the chain's configuration, application logic, and tests, among others. It
+provides a starting point for developers to quickly set up a new Cosmos SDK
+blockchain and build their desired functionality on top of it.
+
+By default, IGNITE® creates a new empty custom module with the same name as the
+blockchain being created (in this case, `example`) in the `x/` directory. This
+module doesn't have any functionality by itself, but can serve as a starting
+point for building out the features of your application. If you don't want to
+create this module, you can use the `--no-module` flag to skip it.
+
+## Directory structure
+
+In order to understand what the IGNITE® CLI has generated for your project, you
+can inspect the contents of the `example/` directory.
+
+The `app/` directory contains the files that connect the different parts of the
+blockchain together. The most important file in this directory is `app.go`,
+which includes the type definition of the blockchain and functions for creating
+and initializing it. This file is responsible for wiring together the various
+components of the blockchain and defining how they will interact with each
+other.
+
+The `cmd/` directory contains the main package responsible for the command-line
+interface (CLI) of the compiled binary. This package defines the commands that
+can be run from the CLI and how they should be executed. It is an important part
+of the blockchain project as it provides a way for developers and users to
+interact with the blockchain and perform various tasks, such as querying the
+blockchain state or sending transactions.
+
+The `docs/` directory is used for storing project documentation. By default,
+this directory includes an OpenAPI specification file, which is a
+machine-readable format for defining the API of a software project. The OpenAPI
+specification can be used to automatically generate human-readable documentation
+for the project, as well as provide a way for other tools and services to
+interact with the API. The `docs/` directory can be used to store any additional
+documentation that is relevant to the project.
+
+The `proto/` directory contains protocol buffer files, which are used to
+describe the data structure of the blockchain. Protocol buffers are a language-
+and platform-neutral mechanism for serializing structured data, and are often
+used in the development of distributed systems, such as blockchain networks. The
+protocol buffer files in the `proto/` directory define the data structures and
+messages that are used by the blockchain, and are used to generate code for
+various programming languages that can be used to interact with the blockchain.
+In the context of the Cosmos SDK, protocol buffer files are used to define the
+specific types of data that can be sent and received by the blockchain, as well
+as the specific RPC endpoints that can be used to access the blockchain's
+functionality.
+
+The `testutil/` directory contains helper functions that are used for testing.
+These functions provide a convenient way to perform common tasks that are needed
+when writing tests for the blockchain, such as creating test accounts,
+generating transactions, and checking the state of the blockchain. By using the
+helper functions in the `testutil/` directory, developers can write tests more
+quickly and efficiently, and can ensure that their tests are comprehensive and
+effective.
+
+The `x/` directory contains custom Cosmos SDK modules that have been added to
+the blockchain. Standard Cosmos SDK modules are pre-built components that
+provide common functionality for Cosmos SDK-based blockchains, such as support
+for staking and governance. Custom modules, on the other hand, are modules that
+have been developed specifically for the blockchain project and provide
+project-specific functionality.
+
+The `config.yml` file is a configuration file that can be used to customize the
+blockchain during development. This file includes settings that control various
+aspects of the blockchain, such as the network's ID, account balances, and the
+node parameters.
+
+The `.github` directory contains a GitHub Actions workflow that can be used to
+automatically build and release a blockchain binary. GitHub Actions is a tool
+that allows developers to automate their software development workflows,
+including building, testing, and deploying their projects. The workflow in the
+`.github` directory is used to automate the process of building the blockchain
+binary and releasing it, which can save time and effort for developers.
+
+The `readme.md` file is a readme file that provides an overview of the
+blockchain project. This file typically includes information such as the
+project's name and purpose, as well as instructions on how to build and run the
+blockchain. By reading the `readme.md` file, developers and users can quickly
+understand the purpose and capabilities of the blockchain project and get
+started using it.
+
+## Starting a blockchain node
+
+To start a blockchain node in development, you can run the following command:
+
+```
+ignite chain serve
+```
+
+The `ignite chain serve` command is used to start a blockchain node in
+development mode. It first compiles and installs the binary using the
+`ignite chain build` command, then initializes the blockchain's data directory
+for a single validator using the `ignite chain init` command. After that, it
+starts the node locally and enables automatic code reloading so that changes to
+the code can be reflected in the running blockchain without having to restart
+the node. This allows for faster development and testing of the blockchain.
+
+**Congratulations!** 🥳 You have successfully created a brand-new Cosmos blockchain
+using the IGNITE® CLI. This blockchain uses the delegated proof of stake (DPoS)
+consensus algorithm, and comes with a set of standard modules for token
+transfers, governance, and inflation. Now that you have a basic understanding of
+your Cosmos blockchain, it's time to start building custom functionality. In the
+following tutorials, you will learn how to build custom modules and add new
+features to your blockchain, allowing you to create a unique and powerful
+decentralized application.

docs/docs/02-guide/03-hello-world.md

@@ -0,0 +1,96 @@
+---
+description: Build your first blockchain and your first Cosmos SDK query.
+title: Hello World
+---
+
+# "Hello world!" Blockchain Tutorial with IGNITE® CLI
+
+**Introduction**
+
+In this tutorial, you'll build a simple blockchain using IGNITE® CLI that responds to a custom query with `Hello %s!`, where `%s` is a name passed in the query.
+This will enhance your understanding of creating custom queries in a Cosmos SDK blockchain.
+
+## Setup and Scaffold
+
+1. **Create a New Blockchain:**
+
+ ```bash
+ ignite scaffold chain hello
+ ```
+
+2. **Navigate to the Blockchain Directory:**
+
+ ```bash
+ cd hello
+ ```
+
+## Adding a Custom Query
+
+- **Scaffold the Query:**
+
+```bash
+ignite scaffold query say-hello name --response name
+```
+
+This command generates code for a new query, `say-hello`, which accepts a name, an input, and returns it in the response.
+
+- **Understanding the Scaffolded Code:**
+
+  - `proto/hello/hello/query.proto`: Defines the request and response structure.
+  - `x/hello/module/autocli.go`: Contains commands for the query, using [AutoCLI](../08-references/04-glossary.md#autocli).
+  - `x/hello/keeper/query_say_hello.go`: Houses the logic for the query response.
+
+## Customizing the Query Response
+
+In the Cosmos SDK, queries are requests for information from the blockchain, used to access data like the ledger's current state or transaction details. While the SDK offers several built-in query methods, developers can also craft custom queries for specific data retrieval or complex operations.
+
+- **Modify `query_say_hello.go`:**
+  
+Update the `SayHello` function in `x/hello/keeper/query_say_hello.go` to return a personalized greeting query.
+
+```go title="x/hello/keeper/query_say_hello.go"
+package keeper
+
+import (
+	"context"
+	"fmt"
+
+	"hello/x/hello/types"
+
+	"google.golang.org/grpc/codes"
+	"google.golang.org/grpc/status"
+)
+
+func (q queryServer) SayHello(ctx context.Context, req *types.QuerySayHelloRequest) (*types.QuerySayHelloResponse, error) {
+	if req == nil {
+		return nil, status.Error(codes.InvalidArgument, "invalid request")
+	}
+
+	// TODO: Process the query
+
+	// Custom Response
+	return &types.QuerySayHelloResponse{Name: fmt.Sprintf("Hello %s!", req.Name)}, nil
+}
+```
+
+## Running the Blockchain
+
+1. **Start the Blockchain:**
+
+```bash
+ignite chain serve
+```
+
+2. **Test the Query:**
+
+Use the command-line interface to submit a query.
+
+```
+hellod q hello say-hello world
+```
+
+Expect a response: `Hello world!`
+
+## Conclusion
+
+Congratulations! 🎉 You've successfully created a blockchain module with a custom query using IGNITE® CLI. Through this tutorial, you've learned how to scaffold a chain, add a custom query, and modify the logic for personalized responses. This experience illustrates the power of IGNITE® CLI in streamlining blockchain development and the importance of understanding the underlying code for customization.

docs/docs/02-guide/04-ibc.md

@@ -0,0 +1,669 @@
+---
+sidebar_position: 7
+description: Build an understanding of how to create and send packets across blockchains and navigate between blockchains.
+title: "Inter-Blockchain Communication: Basics"
+---
+
+# Inter-Blockchain Communication: Basics
+
+The Inter-Blockchain Communication protocol (IBC) is an important part of the
+Cosmos SDK ecosystem. The Hello World tutorial is a time-honored tradition in
+computer programming. This tutorial builds an understanding of how to create and
+send packets across blockchain. This foundational knowledge helps you navigate
+between blockchains with the Cosmos SDK.
+
+**You will learn how to**
+
+- Use IBC to create and send packets between blockchains.
+- Navigate between blockchains using the Cosmos SDK and the IGNITE® CLI Relayer.
+- Create a basic blog post and save the post on another blockchain.
+
+## What is IBC?
+
+The Inter-Blockchain Communication protocol (IBC) allows blockchains to talk to
+each other. IBC handles transport across different sovereign blockchains. This
+end-to-end, connection-oriented, stateful protocol provides reliable, ordered,
+and authenticated communication between heterogeneous blockchains.
+
+The [IBC protocol in the Cosmos
+SDK](https://ibc.cosmos.network/main/ibc/overview) is the standard for the
+interaction between two blockchains. The IBCmodule interface defines how packets
+and messages are constructed to be interpreted by the sending and the receiving
+blockchain.
+
+The IBC relayer lets you connect between sets of IBC-enabled chains. This
+tutorial teaches you how to create two blockchains and then start and use the
+relayer with IGNITE® CLI to connect two blockchains.
+
+This tutorial covers essentials like modules, IBC packets, relayer, and the
+lifecycle of packets routed through IBC.
+
+## Create a blockchain
+
+Create a blockchain app with a blog module to write posts on other blockchains
+that contain the Hello World message. For this tutorial, you can write posts for
+the Cosmos SDK universe that contain Hello Mars, Hello Cosmos, and Hello Earth
+messages.
+
+For this simple example, create an app that contains a blog module that has a
+post transaction with title and text.
+
+After you define the logic, run two blockchains that have this module installed.
+
+- The chains can send posts between each other using IBC.
+
+- On the sending chain, save the `acknowledged` and `timed out` posts.
+
+After the transaction is acknowledged by the receiving chain, you know that the
+post is saved on both blockchains.
+
+- The sending chain has the additional data `postID`.
+
+- Sent posts that are acknowledged and timed out contain the title and the
+  target chain of the post. These identifiers
+- are visible on the parameter `chain`. The following chart shows the lifecycle
+  of a packet that travels through IBC.
+
+![The Lifecycle of an IBC packet](./images/packet_sendpost.png)
+
+## Build your blockchain app
+
+Use IGNITE® CLI to scaffold the blockchain app and the blog module.
+
+### Build a new blockchain
+
+To scaffold a new blockchain named `planet`:
+
+```bash
+ignite scaffold chain planet --no-module
+cd planet
+```
+
+A new directory named `planet` is created in your home directory. The `planet`
+directory contains a working blockchain app.
+
+### Scaffold the blog module inside your blockchain
+
+Next, use IGNITE® CLI to scaffold a blog module with IBC capabilities. The blog
+module contains the logic for creating blog posts and routing them through IBC
+to the second blockchain.
+
+To scaffold a module named `blog`:
+
+```bash
+ignite scaffold module blog --ibc
+```
+
+A new directory with the code for an IBC module is created in `planet/x/blog`.
+Modules scaffolded with the `--ibc` flag include all the logic for the
+scaffolded IBC module.
+
+### Generate CRUD actions for types
+
+Next, create the CRUD actions for the blog module types.
+
+Use the `ignite scaffold list` command to scaffold the boilerplate code for the
+create, read, update, and delete (CRUD) actions.
+
+These `ignite scaffold list` commands create CRUD code for the following
+transactions:
+
+- Creating blog posts
+
+```bash
+ignite scaffold list post title content creator --no-message --module blog
+```
+
+- Processing acknowledgments for sent posts
+
+```bash
+ignite scaffold list sentPost postID:uint title chain creator --no-message --module blog
+```
+
+- Managing post timeouts
+
+```bash
+ignite scaffold list timeoutPost title chain creator --no-message --module blog
+```
+
+The scaffolded code includes proto files for defining data structures, messages,
+messages handlers, keepers for modifying the state, and CLI commands.
+
+### IGNITE® CLI Scaffold List Command Overview
+
+```
+ignite scaffold list [typeName] [field1] [field2] ... [flags]
+```
+
+The first argument of the `ignite scaffold list [typeName]` command specifies
+the name of the type being created. For the blog app, you created `post`,
+`sentPost`, and `timeoutPost` types.
+
+The next arguments define the fields that are associated with the type. For the
+blog app, you created `title`, `content`, `postID`, and `chain` fields.
+
+The `--module` flag defines which module the new transaction type is added to.
+This optional flag lets you manage multiple modules within your IGNITE® CLI app.
+When the flag is not present, the type is scaffolded in the module that matches
+the name of the repo.
+
+When a new type is scaffolded, the default behavior is to scaffold messages that
+can be sent by users for CRUD operations. The `--no-message` flag disables this
+feature. Disable the messages option for the app since you want the posts to be
+created upon reception of IBC packets and not directly created from a user's
+messages.
+
+### Scaffold a sendable and interpretable IBC packet
+
+You must generate code for a packet that contains the title and the content of
+the blog post.
+
+The `ignite packet` command creates the logic for an IBC packet that can be sent
+to another blockchain.
+
+- The `title` and `content` are stored on the target chain.
+
+- The `postID` is acknowledged on the sending chain.
+
+To scaffold a sendable and interpretable IBC packet:
+
+```bash
+ignite scaffold packet ibcPost title content --ack postID:uint --module blog
+```
+
+Notice the fields in the `ibcPost` packet match the fields in the `post` type
+that you created earlier.
+
+- The `--ack` flag defines which identifier is returned to the sending
+  blockchain.
+
+- The `--module` flag specifies to create the packet in a particular IBC module.
+
+The `ignite packet` command also scaffolds the CLI command that is capable of
+sending an IBC packet:
+
+```bash
+planetd tx blog send-ibcPost [portID] [channelID] [title] [content]
+```
+
+## Modify the source code
+
+After you create the types and transactions, you must manually insert the logic
+to manage updates in the database. Modify the source code to save the data as
+specified earlier in this tutorial.
+
+### Add creator to the blog post packet
+
+Start with the proto file that defines the structure of the IBC packet.
+
+To identify the creator of the post in the receiving blockchain, add the
+`creator` field inside the packet. This field was not specified directly in the
+command because it would automatically become a parameter in the `SendIbcPost`
+CLI command.
+
+```protobuf title="proto/planet/blog/v1/packet.proto"
+message IbcPostPacketData {
+  string title = 1;
+  string content = 2;
+  // highlight-next-line
+  string creator = 3;
+}
+```
+
+To make sure the receiving chain has content on the creator of a blog post, add
+the `msg.Creator` value to the IBC `packet`.
+
+- The content of the `sender` of the message is automatically included in
+  `SendIbcPost` message.
+- The sender is verified as the signer of the message, so you can add the
+  `msg.Sender` as the creator to the new packet
+- before it is sent over IBC.
+
+```go title="x/blog/keeper/msg_server_ibc_post.go"
+package keeper
+
+func (k msgServer) SendIbcPost(goCtx context.Context, msg *types.MsgSendIbcPost) (*types.MsgSendIbcPostResponse, error) {
+	// validate incoming message
+	if _, err := k.addressCodec.StringToBytes(msg.Creator); err != nil {
+		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidAddress, fmt.Sprintf("invalid address: %s", err))
+	}
+
+	if msg.Port == "" {
+		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet port")
+	}
+
+	if msg.ChannelID == "" {
+		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet channel")
+	}
+
+	if msg.TimeoutTimestamp == 0 {
+		return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "invalid packet timeout")
+	}
+
+	// TODO: logic before transmitting the packet
+
+	// Construct the packet
+	var packet types.IbcPostPacketData
+
+	packet.Title = msg.Title
+	packet.Content = msg.Content
+	// highlight-next-line
+	packet.Creator = msg.Creator
+
+	// Transmit the packet
+	ctx := sdk.UnwrapSDKContext(goCtx)
+	_, err := k.TransmitIbcPostPacket(
+		ctx,
+		packet,
+		msg.Port,
+		msg.ChannelID,
+		clienttypes.ZeroHeight(),
+		msg.TimeoutTimestamp,
+	)
+	if err != nil {
+		return nil, err
+	}
+
+	return &types.MsgSendIbcPostResponse{}, nil
+}
+```
+
+### Receive the post
+
+The methods for primary transaction logic are in the `x/blog/keeper/ibc_post.go`
+file. Use these methods to manage IBC packets:
+
+- `TransmitIbcPostPacket` is called manually to send the packet over IBC. This
+  method also defines the logic before the packet is sent over IBC to another
+  blockchain app.
+- `OnRecvIbcPostPacket` hook is automatically called when a packet is received
+  on the chain. This method defines the packet reception logic.
+- `OnAcknowledgementIbcPostPacket` hook is called when a sent packet is
+  acknowledged on the source chain. This method defines the logic when the
+  packet has been received.
+- `OnTimeoutIbcPostPacket` hook is called when a sent packet times out. This
+  method defines the logic when the packet is not received on the target chain
+
+You must modify the source code to add the logic inside those functions so that
+the data tables are modified accordingly.
+
+On reception of the post message, create a new post with the title and the
+content on the receiving chain.
+
+To identify the blockchain app that a message is originating from and who
+created the message, use an identifier in the following format:
+
+`<portID>-<channelID>-<creatorAddress>`
+
+Finally, the IGNITE® CLI-generated AppendPost function returns the ID of the new
+appended post. You can return this value to the source chain through
+acknowledgment.
+
+Append the type instance as `PostId` on receiving the packet:
+
+- The context `ctx` is an [immutable data
+  structure](https://docs.cosmos.network/main/core/context#go-context-package)
+  that has header data from the transaction. See [how the context is
+  initiated](https://github.com/cosmos/cosmos-sdk/blob/main/types/context.go#L71)
+- The identifier format that you defined earlier
+- The `title` is the Title of the blog post
+- The `content` is the Content of the blog post
+
+Then modify the `OnRecvIbcPostPacket` keeper function with the following code:
+
+```go title="x/blog/keeper/ibc_post.go"
+package keeper
+
+func (k Keeper) OnRecvIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData) (packetAck types.IbcPostPacketAck, err error) {
+	packetAck.PostId, err = k.PostSeq.Next(ctx)
+	if err != nil {
+		return packetAck, err
+	}
+	return packetAck, k.Post.Set(ctx, packetAck.PostId, types.Post{Title: data.Title, Content: data.Content})
+}
+```
+
+### Receive the post acknowledgement
+
+On the sending blockchain, store a `sentPost` so you know that the post has been
+received on the target chain.
+
+Store the title and the target to identify the post.
+
+When a packet is scaffolded, the default type for the received acknowledgment
+data is a type that identifies if the packet treatment has failed. The
+`Acknowledgement_Error` type is set if `OnRecvIbcPostPacket` returns an error
+from the packet.
+
+```go title="x/blog/keeper/ibc_post.go"
+package keeper
+
+import transfertypes "github.com/cosmos/ibc-go/v10/modules/apps/transfer/types"
+
+func (k Keeper) OnAcknowledgementIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData, ack channeltypes.Acknowledgement) error {
+	switch dispatchedAck := ack.Response.(type) {
+	case *channeltypes.Acknowledgement_Error:
+		// We will not treat acknowledgment error in this tutorial
+		return nil
+	case *channeltypes.Acknowledgement_Result:
+		// Decode the packet acknowledgment
+		var packetAck types.IbcPostPacketAck
+		if err := k.cdc.UnmarshalJSON(dispatchedAck.Result, &packetAck); err != nil {
+			// The counter-party module doesn't implement the correct acknowledgment format
+			return errors.New("cannot unmarshal acknowledgment")
+		}
+
+		seq, err := k.SentPostSeq.Next(ctx)
+		if err != nil {
+			return err
+		}
+
+		return k.SentPost.Set(ctx, seq,
+			types.SentPost{
+				PostId: packetAck.PostId,
+				Title:  data.Title,
+				Chain:  packet.DestinationPort + "-" + packet.DestinationChannel,
+			},
+		)
+	default:
+		return errors.New("the counter-party module does not implement the correct acknowledgment format")
+	}
+}
+```
+
+### Store information about the timed-out packet
+
+Store posts that have not been received by target chains in `timeoutPost`
+posts. This logic follows the same format as `sentPost`.
+
+```go title="x/blog/keeper/ibc_post.go"
+func (k Keeper) OnTimeoutIbcPostPacket(ctx sdk.Context, packet channeltypes.Packet, data types.IbcPostPacketData) error {
+	seq, err := k.TimeoutPostSeq.Next(ctx)
+	if err != nil {
+		return err
+	}
+
+	return k.TimeoutPost.Set(ctx, seq,
+		types.TimeoutPost{
+			Title: data.Title,
+			Chain: packet.DestinationPort + "-" + packet.DestinationChannel,
+		},
+	)
+}
+```
+
+This last step completes the basic `blog` module setup. The blockchain is now
+ready!
+
+## Use the IBC modules
+
+You can now spin up the blockchain and send a blog post from one blockchain app
+to the other. Multiple terminal windows are required to complete these next
+steps.
+
+### Test the IBC modules
+
+To test the IBC module, start two blockchain networks on the same machine. Both
+blockchains use the same source code. Each blockchain has a unique chain ID.
+
+One blockchain is named `earth` and the other blockchain is named `mars`.
+
+The `earth.yml` and `mars.yml` files are required in the project directory:
+
+```yaml title="earth.yml"
+version: 1
+validation: sovereign
+build:
+  proto:
+    path: proto
+accounts:
+- name: alice
+  coins:
+  - 1000token
+  - 100000000stake
+- name: bob
+  coins:
+  - 500token
+  - 100000000stake
+faucet:
+  name: bob
+  coins:
+  - 5token
+  - 100000stake
+  host: 0.0.0.0:4500
+genesis:
+  chain_id: earth
+validators:
+- name: alice
+  bonded: 100000000stake
+  home: $HOME/.earth
+```
+
+```yaml title="mars.yml"
+version: 1
+validation: sovereign
+build:
+  proto:
+    path: proto
+accounts:
+- name: alice
+  coins:
+  - 1000token
+  - 1000000000stake
+- name: bob
+  coins:
+  - 500token
+  - 100000000stake
+faucet:
+  name: bob
+  coins:
+  - 5token
+  - 100000stake
+  host: :4501
+genesis:
+  chain_id: mars
+validators:
+- name: alice
+  bonded: 100000000stake
+  app:
+    api:
+      address: :1318
+    grpc:
+      address: :9092
+    grpc-web:
+      address: :9093
+  config:
+    p2p:
+      laddr: :26658
+    rpc:
+      laddr: :26659
+      pprof_laddr: :6061
+  home: $HOME/.mars
+```
+
+Open a terminal window and run the following command to start the `earth`
+blockchain:
+
+```bash
+ignite chain serve -c earth.yml
+```
+
+Open a different terminal window and run the following command to start the
+`mars` blockchain:
+
+```bash
+ignite chain serve -c mars.yml
+```
+If existing relayer configurations do not exist, the command returns `no matches
+found` and no action is taken.
+
+### Configure and start the relayer
+
+First, add the Hermes relayer app.
+
+```bash
+ignite app install -g github.com/ignite/apps/hermes
+```
+
+If you previously used the relayer, follow these steps to remove exiting relayer
+and IGNITE® CLI configurations:
+
+- Stop your blockchains and delete previous configuration files:
+
+```bash
+ignite relayer hermes clear binaries
+ignite relayer hermes clear configs
+```
+
+and after configure the relayer.
+
+```bash
+ignite relayer hermes configure \
+"earth" "http://localhost:26657" "http://localhost:9090" \
+"mars" "http://localhost:26659" "http://localhost:9092" \
+--chain-a-faucet "http://0.0.0.0:4500" \
+--chain-b-faucet "http://0.0.0.0:4501" \
+--chain-a-port-id "blog" \
+--chain-b-port-id "blog" \
+--channel-version "blog-1"
+```
+
+When prompted, press Enter to accept the default values for `Chain A Account` and
+`Chain B Account`.
+
+The output looks like:
+
+```
+Hermes config created at /Users/danilopantani/.ignite/relayer/hermes/earth_mars
+? Chain earth doesn't have a default Hermes key. Type your mnemonic to continue or type enter to generate a new one: (optional) 
+New mnemonic generated: danger plate flavor twist chimney myself sketch assist copy expand core tattoo ignore ensure quote mean forum carbon enroll gadget immense grab early maze
+Chain earth key created
+Chain earth relayer wallet: cosmos1jk6wmyl880j6t9vw6umy9v8ex0yhrfwgx0vv2d
+New balance from faucet: 100000stake,5token
+? Chain mars doesn't have a default Hermes key. Type your mnemonic to continue or type enter to generate a new one: (optional) 
+New mnemonic generated: invest box icon session lens demise purse link boss dwarf give minimum jazz eye vocal seven sunset coach express want ask version anger ranch
+Chain mars key created
+Chain mars relayer wallet: cosmos1x9kt37c0sutanaqwy9gxpvq5990yt0qnpqntmp
+New balance from faucet: 100000stake,5token
+Client '07-tendermint-0' created (earth -> mars)
+Client 07-tendermint-0' created (mars -> earth)
+Connection 'earth (connection-0) <-> mars (connection-0)' created
+Channel 'earth (channel-0) <-> mars (channel-0)' created
+```
+
+Now start the relayer:
+
+```bash
+ignite relayer hermes start "earth" "mars"
+```
+
+### Send packets
+
+You can now send packets and verify the received posts:
+
+```bash
+planetd tx blog send-ibc-post blog channel-0 "Hello" "Hello Mars, I'm Alice from Earth" --from alice --chain-id earth --home ~/.earth
+```
+
+To verify that the post has been received on Mars:
+
+```bash
+planetd q blog list-post --node tcp://localhost:26659
+```
+
+The packet has been received:
+
+```yaml
+Post:
+  - content: Hello Mars, I'm Alice from Earth
+    creator: blog-channel-0-cosmos1aew8dk9cs3uzzgeldatgzvm5ca2k4m98xhy20x
+    id: "0"
+    title: Hello
+pagination:
+  next_key: null
+  total: "1"
+```
+
+To check if the packet has been acknowledged on Earth:
+
+```bash
+planetd q blog list-sent-post
+```
+
+Output:
+
+```yaml
+SentPost:
+  - chain: blog-channel-0
+    creator: cosmos1aew8dk9cs3uzzgeldatgzvm5ca2k4m98xhy20x
+    id: "0"
+    postID: "0"
+    title: Hello
+pagination:
+  next_key: null
+  total: "1"
+```
+
+To test timeout, set the timeout time of a packet to 1 nanosecond, verify that
+the packet is timed out, and check the timed-out posts:
+
+```bash
+planetd tx blog send-ibc-post blog channel-0 "Sorry" "Sorry Mars, you will never see this post" --from alice --chain-id earth --home ~/.earth --packet-timeout-timestamp 1
+```
+
+Check the timed-out posts:
+
+```bash
+planetd q blog list-timeout-post
+```
+
+Results:
+
+```yaml
+TimeoutPost:
+  - chain: blog-channel-0
+    creator: cosmos1fhpcsxn0g8uask73xpcgwxlfxtuunn3ey5ptjv
+    id: "0"
+    title: Sorry
+pagination:
+  next_key: null
+  total: "2"
+```
+
+You can also send a post from Mars:
+
+```bash
+planetd tx blog send-ibc-post blog channel-0 "Hello" "Hello Earth, I'm Alice from Mars" --from alice --chain-id mars --home ~/.mars --node tcp://localhost:26659
+```
+
+List post on Earth:
+
+```bash
+planetd q blog list-post
+```
+
+Results:
+
+```yaml
+Post:
+  - content: Hello Earth, I'm Alice from Mars
+    creator: blog-channel-0-cosmos1xtpx43l826348s59au24p22pxg6q248638q2tf
+    id: "0"
+    title: Hello
+pagination:
+  next_key: null
+  total: "1"
+```
+
+## Congratulations 🎉
+
+By completing this tutorial, you've learned to use the Inter-Blockchain
+Communication protocol (IBC).
+
+Here's what you accomplished in this tutorial:
+
+- Built two Hello blockchain apps as IBC modules
+- Modified the generated code to add CRUD action logic
+- Configured and used the IGNITE® CLI relayer to connect two blockchains with
+  each other
+- Transferred IBC packets from one blockchain to another

docs/docs/02-guide/05-debug.md

@@ -0,0 +1,208 @@
+---
+description: Debugging your Cosmos SDK blockchain
+---
+
+# Debugging a chain
+
+IGNITE® chain debug command can help you find issues during development. It uses
+[Delve](https://github.com/go-delve/delve) debugger which enables you to
+interact with your blockchain app by controlling the execution of the process,
+evaluating variables, and providing information of thread / goroutine state, CPU
+register state and more.
+
+## Debug Command
+
+The debug command requires that the blockchain app binary is build with
+debugging support by removing optimizations and inlining. A debug binary is
+built by default by the `ignite chain serve` command or can optionally be
+created using the `--debug` flag when running `ignite chain init` or `ignite
+chain build` sub-commands.
+
+To start a debugging session in the terminal run:
+
+```
+ignite chain debug
+```
+
+The command runs your blockchain app in the background, attaches to it and
+launches a terminal debugger shell:
+
+```
+Type 'help' for list of commands.
+(dlv)
+```
+
+At this point the blockchain app blocks execution, so you can set one or more
+breakpoints before continuing execution.
+
+Use the
+[break](https://github.com/go-delve/delve/blob/master/Documentation/cli/README.md#break)
+(alias `b`) command to set any number of breakpoints using, for example the
+`<filename>:<line>` notation:
+
+```
+(dlv) break x/hello/keeper/query_say_hello.go:13
+```
+
+This command adds a breakpoint to the `x/hello/keeper/query_say_hello.go`
+file at line 14.
+
+Once all breakpoints are set resume blockchain execution using the
+[continue](https://github.com/go-delve/delve/blob/master/Documentation/cli/README.md#continue)
+(alias `c`) command:
+
+```
+(dlv) continue
+```
+
+The debugger will launch the shell and stop blockchain execution again when a
+breakpoint is triggered.
+
+Within the debugger shell use the `quit` (alias `q`) or `exit` commands to stop
+the blockchain app and exit the debugger.
+
+## Debug Server
+
+A debug server can optionally be started in cases where the default terminal
+client is not desirable. When the server starts it first runs the blockchain
+app, attaches to it and finally waits for a client connection. The default
+server address is *tcp://127.0.0.1:30500* and it accepts both JSON-RPC or DAP
+client connections.
+
+To start a debug server use the following flag:
+
+```
+ignite chain debug --server
+```
+
+To start a debug server with a custom address use the following flags:
+
+```
+ignite chain debug --server --server-address 127.0.0.1:30500
+```
+
+The debug server stops automatically when the client connection is closed.
+
+## Debugging Clients
+
+### Gdlv: Multiplatform Delve UI
+
+[Gdlv](https://github.com/aarzilli/gdlv) is a graphical frontend to Delve for
+Linux, Windows and macOS.
+
+Using it as debugging client is straightforward as it doesn't require any
+configuration. Once the debug server is running and listening for client
+requests connect to it by running:
+
+```
+gdlv connect 127.0.0.1:30500
+```
+
+Setting breakpoints and continuing execution is done in the same way as Delve,
+by using the `break` and `continue` commands.
+
+### Visual Studio Code
+
+Using [Visual Studio Code](https://code.visualstudio.com/) as debugging client
+requires an initial configuration to allow it to connect to the debug server.
+
+Make sure that the [Go](https://code.visualstudio.com/docs/languages/go)
+extension is installed.
+
+VS Code debugging is configured using the `launch.json` file which is usually
+located inside the `.vscode` folder in your workspace.
+
+You can use the following launch configuration to set up VS Code as debugging
+client:
+
+```json title=launch.json
+{
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "name": "Connect to Debug Server",
+            "type": "go",
+            "request": "attach",
+            "mode": "remote",
+            "remotePath": "${workspaceFolder}",
+            "port": 30500,
+            "host": "127.0.0.1"
+        }
+    ]
+}
+```
+
+Alternatively it's possible to create a custom `launch.json` file from the "Run
+and Debug" panel. When prompted choose the Go debugger option labeled "Go:
+Connect to Server" and enter the debug host address and then the port number.
+
+## Example: Debugging a Blockchain App
+
+In this short example we will be using IGNITE® CLI to create a new blockchain and
+a query to be able to trigger a debugging breakpoint when the query is called.
+
+Create a new blockchain:
+
+```
+ignite scaffold chain hello
+```
+
+Scaffold a new query in the `hello` directory:
+
+```
+ignite scaffold query say-hello name --response name
+```
+
+The next step initializes the blockchain's data directory and compiles a debug
+binary:
+
+```
+ignite chain init --debug
+```
+
+Once the initialization finishes launch the debugger shell:
+
+```
+ignite chain debug
+```
+
+Within the debugger shell create a breakpoint that will be triggered when the
+`SayHello` function is called and then continue execution:
+
+```
+(dlv) break x/hello/keeper/query_say_hello.go:12
+(dlv) continue
+```
+
+From a different terminal use the `hellod` binary to call the query:
+
+```
+hellod query hello say-hello bob
+```
+
+A debugger shell will be launched when the breakpoint is triggered:
+
+```
+     7:  "google.golang.org/grpc/codes"
+     8:  "google.golang.org/grpc/status"
+     9:  "hello/x/hello/types"
+    10: )
+    11:
+=>  12: func (k Keeper) SayHello(ctx context.Context, req *types.QuerySayHelloRequest) (*types.QuerySayHelloResponse, error) {
+    13:  if req == nil {
+    14:   return nil, status.Error(codes.InvalidArgument, "invalid request")
+    15:  }
+    16:
+```
+
+From then on you can use Delve commands like `next` (alias `n`) or `print`
+(alias `p`) to control execution and print values. For example, to print the
+*name* argument value use the `print` command followed by "req.Name":
+
+```
+(dlv) print req.Name
+"bob"
+```
+
+Finally, use `quit` (alias `q`) to stop the blockchain app and finish the
+debugging session.

docs/docs/02-guide/06-docker.md

@@ -0,0 +1,142 @@
+---
+description: Run IGNITE® CLI using a Docker container.
+---
+
+# Running inside a Docker container
+
+You can run IGNITE® CLI inside a Docker container without installing the IGNITE®
+CLI binary directly on your machine.
+
+Running IGNITE® CLI in Docker can be useful for various reasons; isolating your
+test environment, running IGNITE® CLI on an unsupported operating system, or
+experimenting with a different version of IGNITE® CLI without installing it.
+
+Docker containers are like virtual machines because they provide an isolated
+environment to programs that runs inside them. In this case, you can run IGNITE®
+CLI in an isolated environment.
+
+Experimentation and file system impact is limited to the Docker instance. The
+host machine is not impacted by changes to the container.
+
+## Prerequisites
+
+Docker must be installed. See [Get Started with
+Docker](https://www.docker.com/get-started).
+
+## IGNITE® CLI Commands in Docker
+
+After you scaffold and start a chain in your Docker container, all IGNITE® CLI
+commands are available. Just type the commands after `docker run -ti
+ignite/cli`. For example:
+
+```bash
+docker run -ti ignitehq/cli -h
+docker run -ti ignitehq/cli scaffold chain planet
+docker run -ti ignitehq/cli chain serve
+```
+
+## Scaffolding a chain
+
+When Docker is installed, you can build a blockchain with a single command.
+
+IGNITE® CLI, and the chains you serve with IGNITE® CLI, persist some files. When
+using the CLI binary directly, those files are located in `$HOME/.ignite` and
+`$HOME/.cache`, but in the context of Docker it's better to use a directory
+different from `$HOME`, so we use `$HOME/sdh`. This folder should be created
+manually prior to the docker commands below, or else Docker creates it with the
+root user.
+
+```bash
+mkdir $HOME/sdh
+```
+
+To scaffold a blockchain `planet` in the `/apps` directory in the container, run
+this command in a terminal window:
+
+```bash
+docker run -ti -v $HOME/sdh:/home/tendermint -v $PWD:/apps ignitehq/cli:0.25.2 scaffold chain planet
+```
+
+Be patient, this command takes a minute or two to run because it does everything
+for you:
+
+- Creates a container that runs from the `ignitehq/cli:0.25.2` image.
+- Executes the IGNITE® CLI binary inside the image.
+- `-v $HOME/sdh:/home/tendermint` maps the `$HOME/sdh` directory in your local
+  computer (the host machine) to the home directory `/home/tendermint` inside
+  the container.
+- `-v $PWD:/apps` maps the current directory in the terminal window on the host
+  machine to the `/apps` directory in the container. You can optionally specify
+  an absolute path instead of `$PWD`.
+
+  Using `-w` and `-v` together provides file persistence on the host machine.
+  The application source code on the Docker container is mirrored to the file
+  system of the host machine.
+
+  **Note:** The directory name for the `-w` and `-v` flags can be a name other
+  than `/app`, but the same directory must be specified for both flags. If you
+  omit `-w` and `-v`, the changes are made in the container only and are lost
+  when that container is shut down.
+
+## Starting a blockchain
+
+To start the blockchain node in the Docker container you just created, run this
+command:
+
+```bash
+docker run -ti -v $HOME/sdh:/home/tendermint -v $PWD:/apps -p 1317:1317 -p 26657:26657 ignitehq/cli:0.25.2 chain serve -p planet
+```
+
+This command does the following:
+
+- `-v $HOME/sdh:/home/tendermint` maps the `$HOME/sdh` directory in your local
+  computer (the host machine) to the home directory `/home/tendermint` inside
+  the container.
+- `-v $PWD:/apps` persists the scaffolded app in the container to the host
+  machine at current working directory.
+- `serve -p planet` specifies to use the `planet` directory that contains the
+  source code of the blockchain.
+- `-p 1317:1317` maps the API server port (cosmos-sdk) to the host machine to
+  forward port 1317 listening inside the container to port 1317 on the host
+  machine.
+- `-p 26657:26657` maps RPC server port 26657 (tendermint) on the host machine
+  to port 26657 in Docker.
+- After the blockchain is started, open `http://localhost:26657` to see the
+  Tendermint API.
+- The `-v` flag specifies for the container to access the application's source
+  code from the host machine, so it can build and run it.
+
+## Versioning
+
+You can specify which version of IGNITE® CLI to install and run in your Docker
+container.
+
+### Latest version
+
+- By default, `ignite/cli` resolves to `ignite/cli:latest`.
+- The `latest` image tag is always the latest stable [IGNITE® CLI
+  release](https://github.com/ignite/cli/releases).
+
+For example, if latest release is
+[v0.25.2](https://github.com/ignite/cli/releases/tag/v0.25.2), the `latest` tag
+points to the `0.25.2` tag.
+
+### Specific version
+
+You can specify to use a specific version of IGNITE® CLI. All available tags are
+in the [ignite/cli
+image](https://hub.docker.com/r/ignitehq/cli/tags?page=1&ordering=last_updated) on
+Docker Hub.
+
+For example:
+
+- Use `ignitehq/cli:0.25.2` (without the `v` prefix) to use version `0.25.2`.
+- Use `ignitehq/cli` to use the latest version.
+- Use `ignitehq/cli:main` to use the `main` branch, so you can experiment with
+  the upcoming version.
+
+To get the latest image, run `docker pull`.
+
+```bash
+docker pull ignitehq/cli:main
+```

docs/docs/02-guide/07-simapp.md

@@ -0,0 +1,103 @@
+---
+sidebar_position: 10
+description: Test different scenarios for your chain.
+---
+
+# Chain simulation
+
+The IGNITE® CLI chain simulator can help you to run your chain based in
+randomized inputs for you can make fuzz testing and also benchmark test for your
+chain, simulating the messages, blocks, and accounts. You can scaffold a
+template to perform simulation testing in each module along with a boilerplate
+simulation methods for each scaffolded message.
+
+## Module simulation
+
+Every new module that is scaffolded with IGNITE® CLI implements the Cosmos SDK
+[Module
+Simulation](https://docs.cosmos.network/main/building-modules/simulator).
+
+- Each new message creates a file with the simulation methods required for the
+  tests.
+- Scaffolding a `CRUD` type like a `list` or `map` creates a simulation file
+  with `create`, `update`, and `delete` simulation methods in the
+  `x/<module>/simulation` folder and registers these methods in
+  `x/<module>/module_simulation.go`.
+- Scaffolding a single message creates an empty simulation method to be
+  implemented by the user.
+
+We recommend that you maintain the simulation methods for each new modification
+into the message keeper methods.
+
+Every simulation is weighted because the sender of the operation is assigned
+randomly. The weight defines how much the simulation calls the message.
+
+For better randomizations, you can define a random seed. The simulation with the
+same random seed is deterministic with the same output.
+
+## Scaffold a simulation
+
+To create a new chain:
+
+```
+ignite scaffold chain mars
+```
+
+Review the empty `x/mars/simulation` folder and the
+`x/mars/module_simulation.go` file to see that a simulation is not registered.
+
+Now, scaffold a new message:
+
+```
+ignite scaffold list user address balance:uint state
+```
+
+A new file `x/mars/simulation/user.go` is created and is registered with the
+weight in the `x/mars/module_simulation.go` file.
+
+Be sure to define the proper simulation weight with a minimum weight of 0 and a
+maximum weight of 100.
+
+For this example, change the `defaultWeightMsgDeleteUser` to 30 and the
+`defaultWeightMsgUpdateUser` to 50.
+
+Run the `BenchmarkSimulation` method into `app/simulation_test.go` to run
+simulation tests for all modules:
+
+```
+ignite chain simulate
+```
+
+You can also define flags that are provided by the simulation. Flags are defined
+by the method `simapp.GetSimulatorFlags()`:
+
+```
+ignite chain simulate -v --numBlocks 200 --blockSize 50 --seed 33
+```
+
+Wait for the entire simulation to finish and check the result of the messages.
+
+The default `go test` command works to run the simulation:
+
+```
+go test -v -benchmem -run=^$ -bench ^BenchmarkSimulation -cpuprofile cpu.out ./app -Commit=true
+```
+
+### Skip message
+
+Use logic to avoid sending a message without returning an error. Return only
+`simtypes.NoOpMsg(...)` into the simulation message handler.
+
+## Params
+
+Scaffolding a module with params automatically adds the module in the
+`module_simulaton.go` file:
+
+```
+ignite s module earth --params channel:string,minLaunch:uint,maxLaunch:int
+```
+
+After the parameters are scaffolded, change the
+`x/<module>/module_simulation.go` file to set the random parameters into the
+`RandomizedParams` method. The simulation will change the params randomly
+according to call the function.

docs/docs/02-guide/08-state.md

@@ -0,0 +1,230 @@
+---
+description: Learn how Cosmos SDK modules manage state with collections
+title: State Management
+---
+
+# State Management in Modules
+
+In blockchain applications, state refers to the current data stored on the blockchain at a specific point in time. Handling state is usually the core of any blockchain application. The Cosmos SDK provides powerful tools for state management, with the `collections` package being the recommended approach for modern applications.
+
+## Collections Package
+
+IGNITE® scaffolds using the [`collections`](https://pkg.go.dev/cosmossdk.io/collections) package for module code. This package provides a type-safe and efficient way to set and query values from the module store.
+
+### Key Features of Collections
+
+- **Type Safety**: Collections are type-safe, reducing the risk of runtime errors.
+- **Simplified API**: Easy-to-use methods for common operations like Get, Set, and Has.
+- **Performance**: Optimized for performance with minimal overhead.
+- **Integration**: Seamlessly integrates with the Cosmos SDK ecosystem.
+
+## Understand keeper field
+
+IGNITE® creates all the necessary boilerplate for collections in the `x/<module>/keeper/keeper.go` file. The `Keeper` struct contains fields for each collection you define in your module. Each field is an instance of a collection type, such as `collections.Map`, `collections.Item`, or `collections.List`.
+
+```go
+type Keeper struct {
+	// ...
+
+	Params   collections.Item[Params]
+	Counters collections.Map[string, uint64]
+	Profiles collections.Map[sdk.AccAddress, Profile]
+}
+```
+
+## Common State Operations
+
+### Reading State
+
+To read values from state, use the `Get` method:
+
+```go
+// getting a single item
+params, err := k.Params.Get(ctx)
+if err != nil {
+	// handle error
+	// collections.ErrNotFound is returned when an item doesn't exist
+}
+
+// getting a map entry
+counter, err := k.Counters.Get(ctx, "my-counter")
+if err != nil {
+	// handle error
+}
+```
+
+### Writing State
+
+To write values to state, use the `Set` method:
+
+```go
+// setting a single item
+err := k.Params.Set(ctx, params)
+if err != nil {
+	// handle error
+}
+
+// setting a map entry
+err = k.Counters.Set(ctx, "my-counter", 42)
+if err != nil {
+	// handle error
+}
+```
+
+### Checking Existence
+
+Use the `Has` method to check if a value exists without retrieving it:
+
+```go
+exists, err := k.Counters.Has(ctx, "my-counter")
+if err != nil {
+	// handle error
+}
+if exists {
+	// value exists
+}
+```
+
+### Removing State
+
+To remove values from state, use the `Remove` method:
+
+```go
+err := k.Counters.Remove(ctx, "my-counter")
+if err != nil {
+	// handle error
+}
+```
+
+## Implementing Business Logic in Messages
+
+Messages in Cosmos SDK modules modify state based on user transactions. Here's how to implement business logic in a message handler using collections:
+
+```go
+func (k msgServer) CreateProfile(ctx context.Context, msg *types.MsgCreateProfile) (*types.MsgCreateProfileResponse, error) {
+	// validate message
+	if err := msg.ValidateBasic(); err != nil {
+		return nil, err
+	}
+
+	// parse sender address
+	senderBz, err := k.addressCodec.StringToBytes(msg.Creator)
+	if err != nil {
+		return nil, err
+	}
+	sender := sdk.AccAddress(senderBz)
+
+	// check if profile already exists
+	exists, err := k.Profiles.Has(ctx, sender)
+	if err != nil {
+		return nil, err
+	}
+	if exists {
+		return nil, sdkerrors.Wrap(types.ErrProfileExists, "profile already exists")
+	}
+
+	// create new profile
+	sdkCtx := sdk.UnwrapSDKContext(ctx)
+	profile := types.Profile{
+		Name:      msg.Name,
+		Bio:       msg.Bio,
+		CreatedAt: sdkCtx.BlockTime().Unix(),
+	}
+
+	// store the profile
+	err = k.Profiles.Set(ctx, sender, profile)
+	if err != nil {
+		return nil, err
+	}
+
+	// increment profile counter
+	counter, err := k.Counters.Get(ctx, "profiles")
+	if err != nil && !errors.Is(err, collections.ErrNotFound) {
+		return nil, err
+	}
+	// set the counter (adding 1)
+	err = k.Counters.Set(ctx, "profiles", counter+1)
+	if err != nil {
+		return nil, err
+	}
+
+	return &types.MsgCreateProfileResponse{}, nil
+}
+```
+
+## Implementing Queries
+
+Queries allow users to read state without modifying it. Here's how to implement a query handler using collections:
+
+```go
+func (q queryServer) GetProfile(ctx context.Context, req *types.QueryGetProfileRequest) (*types.QueryGetProfileResponse, error) {
+	if req == nil {
+		return nil, status.Error(codes.InvalidArgument, "invalid request")
+	}
+
+	// parse address
+	addressBz, err := k.addressCodec.StringToBytes(req.Address)
+	if err != nil {
+		return nil, status.Error(codes.InvalidArgument, "invalid address")
+	}
+	address := sdk.AccAddress(addressBz)
+
+	// get profile
+	profile, err := q.k.Profiles.Get(ctx, address)
+	if err != nil {
+		if errors.Is(err, collections.ErrNotFound) {
+			return nil, status.Error(codes.NotFound, "profile not found")
+		}
+		return nil, status.Error(codes.Internal, "internal error")
+	}
+
+	return &types.QueryGetProfileResponse{Profile: profile}, nil
+}
+```
+
+## Error Handling with Collections
+
+When working with collections, proper error handling is essential:
+
+```go
+// example from a query function
+params, err := q.k.Params.Get(ctx)
+if err != nil && !errors.Is(err, collections.ErrNotFound) {
+	return nil, status.Error(codes.Internal, "internal error")
+}
+```
+
+In the snippet above, it uses the `Get` method to get a collection item. A `collections.ErrNotFound` can be a valid error when the collection is empty, whereas any other error is considered an internal error that should be handled appropriately.
+
+## Iterating Over Collections
+
+Collections also support iteration:
+
+```go
+// iterate over all profiles
+err := k.Profiles.Walk(ctx, nil, func(key sdk.AccAddress, value types.Profile) (bool, error) {
+	// process each profile
+	// return true to stop iteration, false to continue
+	return false, nil
+})
+if err != nil {
+	// handle error
+}
+
+// iterate over a range of counters
+startKey := "a"
+endKey := "z"
+err = k.Counters.Walk(ctx, collections.NewPrefixedPairRange[string, uint64](startKey, endKey), func(key string, value uint64) (bool, error) {
+	// process each counter in the range
+	return false, nil
+})
+if err != nil {
+	// handle error
+}
+```
+
+## Conclusion
+
+The `collections` package provides a powerful and type-safe way to manage state in Cosmos SDK modules. By understanding how to use collections effectively, you can build robust and efficient blockchain applications that handle state transitions reliably.
+
+When developing with IGNITE® CLI, you are already taking advantage of collections which significantly simplify the state management code and reduce the potential for errors.

docs/docs/02-guide/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Getting Started",
+  "link": null
+}

docs/docs/03-CLI-Commands/_category_.json

@@ -0,0 +1,4 @@
+{
+    "label": "CLI Commands",
+    "link": null
+  }

docs/docs/04-clients/01-go-client.md

@@ -0,0 +1,298 @@
+---
+description: Blockchain client in Go
+title: Go client
+---
+
+# A client in the Go programming language
+
+In this tutorial, we will show you how to create a standalone Go program that
+serves as a client for a blockchain. We will use the IGNITE® CLI to set up a
+standard blockchain. To communicate with the blockchain, we will utilize the
+`cosmosclient` package, which provides an easy-to-use interface for interacting
+with the blockchain. You will learn how to use the `cosmosclient` package to
+send transactions and query the blockchain. By the end of this tutorial, you
+will have a good understanding of how to build a client for a blockchain using
+Go and the `cosmosclient` package.
+
+## Create a blockchain
+
+To create a blockchain using the IGNITE® CLI, use the following command:
+
+```
+ignite scaffold chain blog
+```
+
+This will create a new Cosmos SDK blockchain called "blog".
+
+Once the blockchain has been created, you can generate code for a "blog" model
+that will enable you to perform create, read, update, and delete (CRUD)
+operations on blog posts. To do this, you can use the following command:
+
+```
+cd blog
+ignite scaffold list post title body
+```
+
+This will generate the necessary code for the "blog" model, including functions
+for creating, reading, updating, and deleting blog posts. With this code in
+place, you can now use your blockchain to perform CRUD operations on blog posts.
+You can use the generated code to create new blog posts, retrieve existing ones,
+update their content, and delete them as needed. This will give you a fully
+functional Cosmos SDK blockchain with the ability to manage blog posts.
+
+Start your blockchain node with the following command:
+
+```
+ignite chain serve
+```
+
+## Creating a blockchain client
+
+Create a new directory called `blogclient` on the same level as `blog`
+directory. As the name suggests, `blogclient` will contain a standalone Go
+program that acts as a client to your `blog` blockchain.
+
+```bash
+mkdir blogclient
+```
+
+This command will create a new directory called `blogclient` in your current
+location. If you type `ls` in your terminal window, you should see both the
+`blog` and `blogclient` directories listed.
+
+To initialize a new Go package inside the `blogclient` directory, you can use
+the following command:
+
+```
+cd blogclient
+go mod init blogclient
+```
+
+This will create a `go.mod` file in the `blogclient` directory, which contains
+information about the package and the Go version being used.
+
+To import dependencies for your package, you can add the following code to the
+`go.mod` file:
+
+```text title="blogclient/go.mod"
+module blogclient
+
+go 1.24.1
+
+require (
+ blog v0.0.0-00010101000000-000000000000
+ github.com/ignite/cli/v28 v28.8.2
+)
+
+replace blog => ../blog
+```
+
+Your package will import two dependencies:
+
+* `blog`, which contains `types` of messages and a query client
+* `ignite` for the `cosmosclient` package
+
+The `replace` directive uses the package from the local `blog` directory and is
+specified as a relative path to the `blogclient` directory.
+
+Cosmos SDK uses a custom version of the `protobuf` package, so use the `replace`
+
+Finally, install dependencies for your `blogclient`:
+
+```bash
+go mod tidy
+```
+
+### Main logic of the client in `main.go`
+
+Create a `main.go` file inside the `blogclient` directory and add the following
+code:
+
+```go title="blogclient/main.go"
+package main
+
+import (
+	"context"
+	"fmt"
+	"log"
+
+	// Importing the general purpose Cosmos blockchain client
+	"github.com/ignite/cli/v29/ignite/pkg/cosmosclient"
+
+	// Importing the types package of your blog blockchain
+	"blog/x/blog/types"
+)
+
+func main() {
+	ctx := context.Background()
+	addressPrefix := "cosmos"
+
+	// Create a Cosmos client instance
+	client, err := cosmosclient.New(ctx, cosmosclient.WithAddressPrefix(addressPrefix))
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	// Account `alice` was initialized during `ignite chain serve`
+	accountName := "alice"
+
+	// Get account from the keyring
+	account, err := client.Account(accountName)
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	addr, err := account.Address(addressPrefix)
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	// Define a message to create a post
+	msg := &types.MsgCreatePost{
+		Creator: addr,
+		Title:   "Hello!",
+		Body:    "This is the first post",
+	}
+
+	// Broadcast a transaction from account `alice` with the message
+	// to create a post store response in txResp
+	txResp, err := client.BroadcastTx(ctx, account, msg)
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	// Print response from broadcasting a transaction
+	fmt.Print("MsgCreatePost:\n\n")
+	fmt.Println(txResp)
+
+	// Instantiate a query client for your `blog` blockchain
+	queryClient := types.NewQueryClient(client.Context())
+
+	// Query the blockchain using the client's `PostAll` method
+	// to get all posts store all posts in queryResp
+	queryResp, err := queryClient.PostAll(ctx, &types.QueryAllPostRequest{})
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	// Print response from querying all the posts
+	fmt.Print("\n\nAll posts:\n\n")
+	fmt.Println(queryResp)
+}
+```
+
+The code above creates a standalone Go program that acts as a client to the
+`blog` blockchain. It begins by importing the required packages, including the
+general purpose Cosmos blockchain client and the `types` package of the `blog`
+blockchain.
+
+In the `main` function, the code creates a Cosmos client instance and sets the
+address prefix to "cosmos". It then retrieves an account named `"alice"` from
+the keyring and gets the address of the account using the address prefix.
+
+Next, the code defines a message to create a blog post with the title "Hello!"
+and body "This is the first post". It then broadcasts a transaction from the
+account "alice" with the message to create the post, and stores the response in
+the variable `txResp`.
+
+The code then instantiates a query client for the blog blockchain and uses it to
+query the blockchain to retrieve all the posts. It stores the response in the
+variable `queryResp` and prints it to the console.
+
+Finally, the code prints the response from broadcasting the transaction to the
+console. This allows the user to see the results of creating and querying a blog
+post on the `blog` blockchain using the client.
+
+To find out more about the `cosmosclient` package, you can refer to the Go
+package documentation for
+[`cosmosclient`](https://pkg.go.dev/github.com/ignite/cli/ignite/pkg/cosmosclient).
+This documentation provides information on how to use the `Client` type with
+`Options` and `KeyringBackend`.
+
+## Run the blockchain and the client
+
+Make sure your blog blockchain is still running with `ignite chain serve`.
+
+Run the blockchain client:
+
+```bash
+go run main.go
+```
+
+If the command is successful, the results of running the command will be printed
+to the terminal. The output may include some warnings, which can be ignored.
+
+```yml
+MsgCreatePost:
+
+code: 0
+codespace: ""
+data: 12220A202F626C6F672E626C6F672E4D7367437265617465506F7374526573706F6E7365
+events:
+- attributes:
+  - index: true
+    key: ZmVl
+    value: null
+  - index: true
+    key: ZmVlX3BheWVy
+    value: Y29zbW9zMWR6ZW13NzZ3enQ3cDBnajd3MzQyN2E0eHg3MjRkejAzd3hnOGhk
+  type: tx
+- attributes:
+  - index: true
+    key: YWNjX3NlcQ==
+    value: Y29zbW9zMWR6ZW13NzZ3enQ3cDBnajd3MzQyN2E0eHg3MjRkejAzd3hnOGhkLzE=
+  type: tx
+- attributes:
+  - index: true
+    key: c2lnbmF0dXJl
+    value: UWZncUJCUFQvaWxWVzJwNUJNTngzcDlvRzVpSXp0elhXdE9yMHcwVE00OEtlSkRqR0FEdU9VNjJiY1ZRNVkxTHdEbXNuYUlsTmc3VE9uMnJ2ZWRHSlE9PQ==
+  type: tx
+- attributes:
+  - index: true
+    key: YWN0aW9u
+    value: L2Jsb2cuYmxvZy5Nc2dDcmVhdGVQb3N0
+  type: message
+gas_used: "52085"
+gas_wanted: "300000"
+height: "20"
+info: ""
+logs:
+- events:
+  - attributes:
+    - key: action
+      value: /blog.blog.MsgCreatePost
+    type: message
+  log: ""
+  msg_index: 0
+raw_log: '[{"msg_index":0,"events":[{"type":"message","attributes":[{"key":"action","value":"/blog.blog.MsgCreatePost"}]}]}]'
+timestamp: ""
+tx: null
+txhash: 4F53B75C18254F96EF159821DDD665E965DBB576A5AC2B94CE863EB62E33156A
+
+All posts:
+
+Post:<title:"Hello!" body:"This is the first post" creator:"cosmos1dzemw76wzt7p0gj7w3427a4xx724dz03wxg8hd" > pagination:<total:1 >
+```
+
+As you can see the client has successfully broadcasted a transaction and queried
+the chain for blog posts.
+
+Please note, that some values in the output on your terminal (like transaction
+hash and block height) might be different from the output above.
+
+You can confirm the new post with using the `blogd q blog list-post` command:
+
+```yaml
+Post:
+- body: This is the first post
+  creator: cosmos1dzemw76wzt7p0gj7w3427a4xx724dz03wxg8hd
+  id: "0"
+  title: Hello!
+pagination:
+  next_key: null
+  total: "0"
+```
+
+Great job! You have successfully completed the process of creating a Go client
+for your Cosmos SDK blockchain, submitting a transaction, and querying the
+chain.

docs/docs/04-clients/02-typescript.md

@@ -0,0 +1,441 @@
+---
+description: Information about the generated TypeScript client code.
+---
+
+# TypeScript library
+
+IGNITE® offers powerful functionality for generating client-side code for your
+blockchain. Think of this as a one-click client SDK generation tailored
+specifically for your blockchain.
+
+See `ignite generate ts-client --help` learn more on how to use TypeScript code generation.
+
+## Starting a node
+
+Create a new blockchain with `ignite scaffold chain`. You can use an existing
+blockchain project if you have one, instead.
+
+```
+ignite scaffold chain example
+```
+
+For testing purposes add a new account to `config.yml` with a mnemonic:
+
+```yml title="config.yml"
+accounts:
+  - name: frank
+    coins: ["1000token", "100000000stake"]
+    mnemonic: play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint
+```
+
+Run a command to generate TypeScript clients for both standard and custom Cosmos
+SDK modules:
+
+```
+ignite generate ts-client --clear-cache
+```
+
+:::tip
+In order to not rely on the remote `buf.build` service, you can install the
+`protoc-gen-ts_proto` binary locally and IGNITE® will use it instead of the remote plugin.
+
+```sh
+npm install -g ts-proto
+```
+
+Learn more at <https://github.com/stephenh/ts-proto>
+:::
+
+Run a command to start your blockchain node:
+
+```
+ignite chain serve -r
+```
+
+## Setting up a TypeScript frontend client
+
+The best way to get started building with the TypeScript client is by using
+[Vite](https://vitejs.dev). Vite provides boilerplate code for
+vanilla TS projects as well as React, Vue, Lit, Svelte and Preact frameworks.
+You can find additional information at the [Vite Getting Started
+guide](https://vitejs.dev/guide).
+
+You will also need to [polyfill](https://developer.mozilla.org/en-US/docs/Glossary/Polyfill) the client's dependencies. The following is an
+example of setting up a vanilla TS project with the necessary polyfills:
+
+```bash
+npm create vite@latest my-frontend-app -- --template vanilla-ts
+cd my-frontend-app
+npm install --save-dev @esbuild-plugins/node-globals-polyfill @rollup/plugin-node-resolve
+```
+
+You must then create the necessary `vite.config.ts` file.
+
+```typescript title="my-frontend-app/vite.config.ts"
+import { nodeResolve } from "@rollup/plugin-node-resolve";
+import { NodeGlobalsPolyfillPlugin } from "@esbuild-plugins/node-globals-polyfill";
+import { defineConfig } from "vite";
+
+export default defineConfig({
+  plugins: [nodeResolve()],
+
+  optimizeDeps: {
+    esbuildOptions: {
+      define: {
+        global: "globalThis",
+      },
+      plugins: [
+        NodeGlobalsPolyfillPlugin({
+          buffer: true,
+        }),
+      ],
+    },
+  },
+});
+```
+
+You are then ready to use the generated client code inside this project directly
+or by publishing the client and installing it like any other `npm` package.
+
+After the chain starts, you will see Frank's address is
+`cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7`. We'll be using Frank's account
+for querying data and broadcasting transactions in the next section.
+
+## Querying
+
+The code generated in `ts-client` comes with a `package.json` file ready to
+publish which you can modify to suit your needs. To use`ts-client` install the
+required dependencies:
+
+```
+cd ts-client
+npm install
+```
+
+The client is based on a modular architecture where you can configure a client
+class to support the modules you need and instantiate it.
+
+By default, the generated client exports a client class that includes all the
+Cosmos SDK, custom and 3rd party modules in use in your project.
+
+To instantiate the client you need to provide environment information (endpoints
+and chain prefix). For querying that's all you need:
+
+```typescript title="my-frontend-app/src/main.ts"
+import { Client } from "../../ts-client";
+
+const client = new Client(
+  {
+    apiURL: "http://localhost:1317",
+    rpcURL: "http://localhost:26657",
+    prefix: "cosmos",
+  }
+);
+```
+
+The example above uses `ts-client` from a local directory. If you have published
+your `ts-client` on `npm` replace `../../ts-client` with a package name.
+
+The resulting client instance contains namespaces for each module, each with a
+`query` and `tx` namespace containing the module's relevant querying and
+transacting methods with full type and auto-completion support.
+
+To query for a balance of an address:
+
+```typescript
+const balances = await client.CosmosBankV1Beta1.query.queryAllBalances(
+  'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7'
+);
+```
+
+## Broadcasting a transaction
+
+Add signing capabilities to the client by creating a wallet from a mnemonic
+(we're using the Frank's mnemonic added to `config.yml` earlier) and passing it
+as an optional argument to `Client()`. The wallet implements the CosmJS
+OfflineSigner` interface.
+
+```typescript title="my-frontend-app/src/main.ts"
+import { Client } from "../../ts-client";
+// highlight-start
+import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";
+
+const mnemonic =
+  "play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint";
+const wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic);
+// highlight-end
+
+const client = new Client(
+  {
+    apiURL: "http://localhost:1317",
+    rpcURL: "http://localhost:26657",
+    prefix: "cosmos",
+  },
+  // highlight-next-line
+  wallet
+);
+```
+
+Broadcasting a transaction:
+
+```typescript title="my-frontend-app/src/main.ts"
+const tx_result = await client.CosmosBankV1Beta1.tx.sendMsgSend({
+  value: {
+    amount: [
+      {
+        amount: '200',
+        denom: 'token',
+      },
+    ],
+    fromAddress: 'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7',
+    toAddress: 'cosmos15uw6qpxqs6zqh0zp3ty2ac29cvnnzd3qwjntnc',
+  },
+  fee: {
+    amount: [{ amount: '0', denom: 'stake' }],
+    gas: '200000',
+  },
+  memo: '',
+})
+```
+
+## Broadcasting a transaction with a custom message
+
+If your chain already has custom messages defined, you can use those. If not,
+we'll be using IGNITE®'s scaffolded code as an example. Create a post with CRUD
+messages:
+
+```
+ignite scaffold list post title body
+```
+
+After adding messages to your chain you may need to re-generate the TypeScript
+client:
+
+```
+ignite generate ts-client --clear-cache
+```
+
+Broadcast a transaction containing the custom `MsgCreatePost`:
+
+```typescript title="my-frontend-app/src/main.ts"
+import { Client } from "../../ts-client";
+import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";
+
+const mnemonic =
+  "play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint";
+const wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic);
+
+const client = new Client(
+  {
+    apiURL: "http://localhost:1317",
+    rpcURL: "http://localhost:26657",
+    prefix: "cosmos",
+  },
+  wallet
+);
+// highlight-start
+const tx_result = await client.ExampleExample.tx.sendMsgCreatePost({
+  value: {
+    title: 'foo',
+    body: 'bar',
+    creator: 'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7',
+  },
+  fee: {
+    amount: [{ amount: '0', denom: 'stake' }],
+    gas: '200000',
+  },
+  memo: '',
+})
+// highlight-end
+```
+
+## Lightweight client
+
+If you prefer, you can construct a lighter client using only the modules you are
+interested in by importing the generic client class and expanding it with the
+modules you need:
+
+```typescript title="my-frontend-app/src/main.ts"
+// highlight-start
+import { IgniteClient } from '../../ts-client/client'
+import { Module as CosmosBankV1Beta1 } from '../../ts-client/cosmos.bank.v1beta1'
+import { Module as CosmosStakingV1Beta1 } from '../../ts-client/cosmos.staking.v1beta1'
+// highlight-end
+import { DirectSecp256k1HdWallet } from '@cosmjs/proto-signing'
+
+const mnemonic =
+  'play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint'
+const wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic)
+// highlight-next-line
+const Client = IgniteClient.plugin([CosmosBankV1Beta1, CosmosStakingV1Beta1])
+
+const client = new Client(
+  {
+    apiURL: 'http://localhost:1317',
+    rpcURL: 'http://localhost:26657',
+    prefix: 'cosmos',
+  },
+  wallet,
+)
+```
+
+## Broadcasting a multi-message transaction
+
+You can also construct TX messages separately and send them in a single TX using
+a global signing client like so:
+
+```typescript title="my-frontend-app/src/main.ts"
+const msg1 = await client.CosmosBankV1Beta1.tx.msgSend({
+  value: {
+    amount: [
+      {
+        amount: '200',
+        denom: 'token',
+      },
+    ],
+    fromAddress: 'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7',
+    toAddress: 'cosmos15uw6qpxqs6zqh0zp3ty2ac29cvnnzd3qwjntnc',
+  },
+})
+
+const msg2 = await client.CosmosBankV1Beta1.tx.msgSend({
+  value: {
+    amount: [
+      {
+        amount: '200',
+        denom: 'token',
+      },
+    ],
+    fromAddress: 'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7',
+    toAddress: 'cosmos15uw6qpxqs6zqh0zp3ty2ac29cvnnzd3qwjntnc',
+  },
+})
+
+const tx_result = await client.signAndBroadcast(
+  [msg1, msg2],
+  {
+    amount: [{ amount: '0', denom: 'stake' }],
+    gas: '200000',
+  },
+  '',
+)
+```
+
+Finally, for additional ease-of-use, apart from the modular client mentioned
+above, each generated module is usable on its own in a stripped-down way by
+exposing a separate txClient and queryClient.
+
+```typescript title="my-frontend-app/src/main.ts"
+import { txClient } from '../../ts-client/cosmos.bank.v1beta1'
+import { DirectSecp256k1HdWallet } from '@cosmjs/proto-signing'
+
+const mnemonic =
+  'play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint'
+const wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic)
+
+const client = txClient({
+  signer: wallet,
+  prefix: 'cosmos',
+  addr: 'http://localhost:26657',
+})
+
+const tx_result = await client.sendMsgSend({
+  value: {
+    amount: [
+      {
+        amount: '200',
+        denom: 'token',
+      },
+    ],
+    fromAddress: 'cosmos13xkhcx2dquhqdml0k37sr7yndquwteuvt2cml7',
+    toAddress: 'cosmos15uw6qpxqs6zqh0zp3ty2ac29cvnnzd3qwjntnc',
+  },
+  fee: {
+    amount: [{ amount: '0', denom: 'stake' }],
+    gas: '200000',
+  },
+  memo: '',
+})
+```
+
+## Usage with Keplr
+
+Normally, Keplr provides a wallet object implementing the `OfflineSigner`
+interface, so you can simply replace the `wallet` argument in client
+instantiation with `window.keplr.getOfflineSigner(chainId)`. However, Keplr
+requires information about your chain, like chain ID, denoms, fees, etc.
+[`experimentalSuggestChain()`](https://docs.keplr.app/api/guide/suggest-chain) is
+a method Keplr provides to pass this information to the Keplr extension.
+
+The generated client makes this easier by offering a `useKeplr()` method that
+automatically discovers the chain information and sets it up for you. Thus, you
+can instantiate the client without a wallet and then call `useKeplr()` to enable
+transacting via Keplr like so:
+
+```typescript title="my-frontend-app/src/main.ts"
+import { Client } from '../../ts-client';
+
+const client = new Client({ 
+  apiURL: "http://localhost:1317",
+  rpcURL: "http://localhost:26657",
+  prefix: "cosmos"
+ }
+);
+await client.useKeplr();
+```
+
+`useKeplr()` optionally accepts an object argument that contains one or more of
+the same keys as the `ChainInfo` type argument of `experimentalSuggestChain()`
+allowing you to override the auto-discovered values.
+
+For example, the default chain name and token precision (which are not recorded
+on-chain) are set to `<chainId> Network` and `0` while the ticker for the denom
+is set to the denom name in uppercase. If you want to override these, you can do
+something like:
+
+```typescript title="my-frontend-app/src/main.ts"
+import { Client } from '../../ts-client';
+
+const client = new Client({ 
+  apiURL: "http://localhost:1317",
+  rpcURL: "http://localhost:26657",
+  prefix: "cosmos"
+ }
+);
+await client.useKeplr({
+  chainName: 'My Great Chain',
+  stakeCurrency: {
+    coinDenom: 'TOKEN',
+    coinMinimalDenom: 'utoken',
+    coinDecimals: '6',
+  },
+})
+```
+
+## Wallet switching
+
+The client also allows you to switch out the wallet for a different one on an
+already instantiated client like so:
+
+```typescript
+import { Client } from '../../ts-client';
+import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";
+
+const mnemonic =
+  'play butter frown city voyage pupil rabbit wheat thrive mind skate turkey helmet thrive door either differ gate exhibit impose city swallow goat faint'
+const wallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic);
+
+const client = new Client({ 
+  apiURL: "http://localhost:1317",
+  rpcURL: "http://localhost:26657",
+  prefix: "cosmos"
+ }
+);
+await client.useKeplr();
+
+// broadcast transactions using the Keplr wallet
+
+client.useSigner(wallet);
+
+// broadcast transactions using the CosmJS wallet
+```

docs/docs/04-clients/03-vue.md

@@ -0,0 +1,181 @@
+# Vue frontend
+
+:::warning
+The Vue frontend is being reworked and is not yet stable.  
+In the meantime, refer to the [IGNITE® CCA App](https://ignite.com/marketplace/cca).
+:::
+
+Welcome to this tutorial on using IGNITE® to develop a web application for your
+blockchain with Vue 3. IGNITE® is a tool that simplifies the process of building
+a blockchain application by providing a set of templates and generators that can
+be used to get up and running quickly.
+
+One of the features of IGNITE® is its support for [Vue 3](https://vuejs.org/), a
+popular JavaScript framework for building user interfaces. In this tutorial, you
+will learn how to use IGNITE® to create a new blockchain and scaffold a Vue
+frontend template. This will give you a basic foundation for your web
+application and make it easier to get started building out the rest of your
+application.
+
+Once you have your blockchain and Vue template set up, the next step is to
+generate an API client. This will allow you to easily interact with your
+blockchain from your web application, enabling you to retrieve data and make
+transactions. By the end of this tutorial, you will have a fully functional web
+application that is connected to your own blockchain.
+
+Prerequisites:
+
+* [Node.js](https://nodejs.org/en/)
+* [Keplr](https://www.keplr.app/) Chrome extension
+
+## Create a blockchain and a Vue app
+
+Create a new blockchain project:
+
+```
+ignite scaffold chain example
+```
+
+To create a Vue frontend template, go to the `example` directory and run the
+following command:
+
+```
+ignite scaffold vue
+```
+
+This will create a new Vue project in the `vue` directory. This project can be
+used with any blockchain, but it depends on an API client to interact with the
+blockchain. To generate an API client, run the following command in the
+`example` directory:
+
+```
+ignite generate composables
+```
+
+This command generates two directories:
+
+* `ts-client`: a framework-agnostic TypeScript client that can be used to
+  interact with your blockchain. You can learn more about how to use this client
+  in the [TypeScript client tutorial](/clients/typescript).
+* `vue/src/composables`: a collection of Vue 3
+  [composables](https://vuejs.org/guide/reusability/composables.html) that wrap
+  the TypeScript client and make it easier to interact with your blockchain from
+  your Vue application.
+
+## Set up Keplr and an account
+
+Open your browser with the Keplr wallet extension installed. Follow [the
+instructions](https://keplr.crunch.help/en/getting-started/creating-a-new-keplr-account)
+to create a new account or use an existing one. Make sure to save the mnemonic
+phrase as you will need it in the next step.
+
+Do not use a mnemonic phrase that is associated with an account that holds
+assets you care about. If you do, you risk losing those assets. It's a good
+practice to create a new account for development purposes.
+
+Add the account you're using in Keplr to your blockchain's `config.yml` file:
+
+```yml
+accounts:
+  - name: alice
+    coins: [20000token, 200000000stake]
+  - name: bob
+    coins: [10000token, 100000000stake]
+    # highlight-start
+  - name: frank
+    coins: [10000token, 100000000stake]
+    mnemonic: struggle since inmate safe logic kite tag web win stay security wonder
+    # highlight-end
+```
+
+Replace the `struggle since...` mnemonic with the one you saved in the previous
+step.
+
+Adding an account with a mnemonic to the config file will tell IGNITE® CLI to add
+the account to the blockchain when you start it. This is useful for development
+purposes, but you should not do this in production.
+
+## Start a blockchain and a Vue app
+
+In the `example` directory run the following command to start your blockchain:
+
+```bash
+ignite chain serve
+```
+
+To start your Vue application, go to the `vue` directory and run the following
+command in a separate terminal window:
+
+:::note
+Make sure you have [pnpm](https://pnpm.io/) installed.
+:::
+
+```bash
+pnpm install && pnpm dev
+```
+
+It is recommended to run `pnpm install` before starting your app with `pnpm dev` to ensure that all dependencies are installed (including the ones that the API client has, see `vue/postinstall.js`).
+
+Open your browser and navigate to
+[http://localhost:5173/](http://localhost:5173/).
+
+![Web app](/img/web-1.png)
+
+Press "Connect wallet", enter your password into Keplr and press "Approve" to
+add your blockchain to Keplr.
+
+<img src="/img/web-4.png" width="300"/>
+
+Make sure to select the account you're using for development purposes and the
+"Example Network" in Keplr's blockchain dropdown. You should see a list of
+assets in your Vue app.
+
+![Web app](/img/web-5.png)
+
+Congratulations! You have successfully created a client-side Vue application and
+connected it to your blockchain. You can modify the source code of your Vue
+application to build out the rest of your project.
+
+## Setting the address prefix
+
+It is necessary to set the correct address prefix in order for the Vue app to
+properly interact with a Cosmos chain. The address prefix is used to identify
+the chain that the app is connected to, and must match the prefix used by the
+chain.
+
+By default, IGNITE® creates a chain with the `cosmos` prefix. If you have
+created your chain with `ignite scaffold chain ... --address-prefix foo` or
+manually changed the prefix in the source code of the chain, you need to set the
+prefix in the Vue app.
+
+There are two ways to set the address prefix in a Vue app.
+
+### Using an environment variable
+
+You can set the `VITE_ADDRESS_PREFIX` environment variable to the correct
+address prefix for your chain. This will override the default prefix used by the
+app.
+
+To set the `VITE_ADDRESS_PREFIX` environment variable, you can use the following
+command:
+
+```bash
+export VITE_ADDRESS_PREFIX=your-prefix
+```
+
+Replace `your-prefix` with the actual address prefix for your chain.
+
+### Setting address prefix in the code
+
+Alternatively, you can manually set the correct address prefix by replacing the
+fallback value of the `prefix` variable in the file `./vue/src/env.ts`.
+
+To do this, open the file `./vue/src/env.ts` and find the following line:
+
+```ts title="./vue/src/env.ts"
+const prefix = process.env.VITE_ADDRESS_PREFIX || 'your-prefix';
+```
+
+Replace `your-prefix` with the actual address prefix for your chain.
+
+Save the file and restart the Vue app to apply the changes.

docs/docs/04-clients/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Create an Interface",
+  "link": null
+}

docs/docs/05-contributing/01-docs.md

@@ -0,0 +1,105 @@
+---
+sidebar_position: 1
+slug: /contributing
+---
+
+# Improving documentation
+
+Thank you for visiting our repository and considering making contributions. We
+appreciate your interest in helping us to create and maintain awesome tutorials
+and documentation.
+
+## Using this repo
+
+Review existing [IGNITE® CLI issues](https://github.com/ignite/cli/issues) to see
+if your question has already been asked and answered.
+
+- To provide feedback, file an issue and provide generous details to help us
+  understand how we can make it better.
+- To provide a fix, make a direct contribution. If you're not a member or
+  maintainer, fork the repo and then submit a pull request (PR) from your forked
+  repo to the `main` branch.
+- Start by creating a draft pull request. Create your draft PR early, even if
+  your work is just beginning or incomplete. Your draft PR indicates to the
+  community that you're working on something and provides a space for
+  conversations early in the development process. Merging is blocked for `Draft`
+  PRs, so they provide a safe place to experiment and invite comments.
+
+## Reviewing technical content PRs
+
+Some of the best content contributions come during the PR review cycles. Follow
+best practices for technical content PR reviews just like you do for code
+reviews.
+
+- For in-line suggestions, use the [GitHub suggesting
+  feature](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)
+  .
+- The PR owner can merge in your suggested commits one at a time or in batch
+  (preferred).
+- When you are providing a more granular extensive review that results in more
+  than 20 in-line suggestions, go ahead and check out the branch and make the
+  changes yourself.
+
+## Writing and contributing
+
+We welcome contributions to the docs and tutorials.
+
+Our technical content follows the [Google developer documentation style
+guide](https://developers.google.com/style). Highlights to help you get started:
+
+- [Highlights](https://developers.google.com/style/highlights)
+- [Word list](https://developers.google.com/style/word-list)
+- [Style and tone](https://developers.google.com/style/tone)
+- [Writing for a global
+  audience](https://developers.google.com/style/translation)
+- [Cross-references](https://developers.google.com/style/cross-references)
+- [Present tense](https://developers.google.com/style/tense)
+
+The Google guidelines include more material than is listed here and are used as
+a guide that enables easy decision-making about proposed content changes.
+
+Other useful resources:
+
+- [Google Technical Writing Courses](https://developers.google.com/tech-writing)
+- [GitHub Guides Mastering
+  Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)
+
+## Where can I find the tutorials and docs?
+
+Technical content includes knowledge base articles and interactive tutorials.
+
+- The IGNITE® CLI Developer Tutorials content is in the `docs/guide` folder.
+- The Knowledge Base content is in the `docs/kb` folder.
+- Upgrade information is in the `docs/migration` folder.
+
+Note: The CLI docs are auto-generated and do not support doc updates.
+
+Locations and folders for other content can vary. Explore the self-describing
+folders for the content that you are interested in. Some articles and tutorials
+reside in a single Markdown file while sub-folders might be present for other
+tutorials.
+
+As always, work-in-progress content might be happening in other locations and
+repos.
+
+## Who works on the tutorials?
+
+The IGNITE® product team developers are focused on building IGNITE® CLI and
+improving the developer experience. The IGNITE® Ecosystem Development team owns
+the technical content and tutorials and manages developer onboarding.
+
+Meet the [people behind IGNITE® CLI and our
+contributors](https://github.com/ignite/cli/graphs/contributors).
+
+## Viewing docs builds
+
+Use a preview to see what your changes will look like in production before the
+updated pages are published.
+
+- While a PR is in draft mode, you can rely on using the preview feature in
+  Markdown.
+- After the PR moves from **Draft** to **Ready for review**, the CI status
+  checks generate a deployment preview. This preview stays up to date as you
+  continue to work and commit new changes to the same branch. A `Docs Deploy
+  Preview / build_and_deploy (pull_request)` preview on a GitHub actions URL is
+  unique for that PR.

docs/docs/05-contributing/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Contribute to IGNITE®",
+  "link": null
+}

docs/docs/06-migration/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Migration",
+  "link": null
+}

docs/docs/06-migration/readme.md

@@ -0,0 +1,74 @@
+---
+sidebar_position: 0
+---
+
+# Migration Guides
+
+Welcome to the section on upgrading to a newer version of IGNITE® CLI! If you're
+looking to update to the latest version, you'll want to start by checking the
+documentation to see if there are any special considerations or instructions you
+need to follow.
+
+If there is no documentation for the latest version of IGNITE® CLI, it's
+generally safe to assume that there were no breaking changes, and you can
+proceed with using the latest version with your project.
+
+## Create your own Migration Guide
+
+The `gen-mig-diffs` tool helps developers manage and visualize code changes across multiple major versions of IGNITE®. With each major upgrade, the codebase might undergo significant changes, making it challenging for developers to track these differences after several updates. The `gen-mig-diffs` tool simplifies this process by scaffolding blockchains with both the old and new versions and displaying the differences.
+
+It is located in the [IGNITE® CLI GitHub repository](https://github.com/ignite/cli/tree/main/ignite/internal/tools/gen-mig-diffs)
+directory and has been made into a standalone project.
+
+To set up this tool in your development environment:
+
+```shell
+gen-mig-diffs [flags]
+```
+
+This tool generates migration diff files for each of IGNITE®'s scaffold commands. It compares two specified versions of IGNITE® and provides a clear, organized view of the changes.
+
+## How to Get Started
+
+1. Clone the IGNITE® CLI repository:
+
+```shell
+git clone https://github.com/ignite/cli.git --depth=1 && \
+cd cli/ignite/internal/tools/gen-mig-diffs
+```
+
+2. Install and show usage:
+
+```shell
+go install . && gen-mig-diffs -h
+```
+
+### Example Migration
+
+As an example, to generate migration diffs between versions 0.27.2 and 28.3.0, use the following command:
+
+```shell
+gen-mig-diffs --output temp/migration --from v0.27.2 --to v28.3.0
+```
+
+This command scaffolds blockchains with the specified versions and shows the differences, making it easier for developers to understand and apply necessary changes when upgrading their projects.
+
+## Usage
+
+```bash
+This tool is used to generate migration diff files for each of ignites scaffold commands
+
+Usage:
+  gen-mig-diffs [flags]
+
+Flags:
+  -f, --from string              Version of IGNITE® or path to IGNITE® source code to generate the diff from
+  -h, --help                     help for gen-mig-diffs
+  -o, --output string            Output directory to save the migration document (default "docs/docs/06-migration")
+      --repo-output string       Output path to clone the IGNITE® repository
+  -s, --repo-source string       Path to IGNITE® source code repository. Set the source automatically set the cleanup to false
+      --repo-url string          Git URL for the IGNITE® repository (default "https://github.com/ignite/cli.git")
+      --scaffold-cache string    Path to cache directory
+      --scaffold-output string   Output path to clone the IGNITE® repository
+  -t, --to string                Version of IGNITE® or path to IGNITE® source code to generate the diff to
+```

docs/docs/06-migration/v0.18.md

@@ -0,0 +1,458 @@
+---
+sidebar_position: 999
+title: v0.18.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.18, changes are required to use IGNITE® CLI v0.18.
+---
+
+# Upgrading a Blockchain to use IGNITE® CLI v0.18
+
+IGNITE® CLI v0.18 comes with Cosmos SDK v0.44. This version of Cosmos SDK introduced changes that are not compatible with
+chains that were scaffolded with IGNITE® CLI versions lower than v0.18.
+
+**Important:** After upgrading from IGNITE® CLI v0.17.3 to IGNITE® CLI v0.18, you must update the default blockchain
+template to use blockchains that were scaffolded with earlier versions.
+
+These instructions are written for a blockchain that was scaffolded with the following command:
+
+```
+ignite scaffold chain github.com/username/mars
+```
+
+If you used a different module path, replace `username` and `mars` with the correct values for your blockchain.
+
+## Blockchain
+
+For each file listed, make the required changes to the source code of the blockchain template.
+
+### go.mod
+
+```
+module github.com/username/mars
+
+go 1.16
+
+require (
+ github.com/cosmos/cosmos-sdk v0.44.0
+ github.com/cosmos/ibc-go v1.2.0
+ github.com/gogo/protobuf v1.3.3
+ github.com/google/go-cmp v0.5.6 // indirect
+ github.com/gorilla/mux v1.8.0
+ github.com/grpc-ecosystem/grpc-gateway v1.16.0
+ github.com/spf13/cast v1.3.1
+ github.com/spf13/cobra v1.1.3
+ github.com/stretchr/testify v1.7.0
+ github.com/tendermint/spm v0.1.6
+ github.com/tendermint/tendermint v0.34.13
+ github.com/tendermint/tm-db v0.6.4
+ google.golang.org/genproto v0.0.0-20210903162649-d08c68adba83
+ google.golang.org/grpc v1.40.0
+)
+
+replace (
+ github.com/99designs/keyring => github.com/cosmos/keyring v1.1.7-0.20210622111912-ef00f8ac3d76
+ github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1
+ google.golang.org/grpc => google.golang.org/grpc v1.33.2
+)
+```
+
+### app/app.go
+
+```go
+package app
+
+import (
+	//...
+	// Add the following packages:
+	"github.com/cosmos/cosmos-sdk/x/feegrant"
+	feegrantkeeper "github.com/cosmos/cosmos-sdk/x/feegrant/keeper"
+	feegrantmodule "github.com/cosmos/cosmos-sdk/x/feegrant/module"
+
+	"github.com/cosmos/ibc-go/modules/apps/transfer"
+	ibctransferkeeper "github.com/cosmos/ibc-go/modules/apps/transfer/keeper"
+	ibctransfertypes "github.com/cosmos/ibc-go/modules/apps/transfer/types"
+	ibc "github.com/cosmos/ibc-go/modules/core"
+	ibcclient "github.com/cosmos/ibc-go/modules/core/02-client"
+	ibcporttypes "github.com/cosmos/ibc-go/modules/core/05-port/types"
+	ibchost "github.com/cosmos/ibc-go/modules/core/24-host"
+	ibckeeper "github.com/cosmos/ibc-go/modules/core/keeper"
+	// Remove the following packages:
+	// transfer "github.com/cosmos/cosmos-sdk/x/ibc/applications/transfer"
+	// ibctransferkeeper "github.com/cosmos/cosmos-sdk/x/ibc/applications/transfer/keeper"
+	// ibctransfertypes "github.com/cosmos/cosmos-sdk/x/ibc/applications/transfer/types"
+	// ibc "github.com/cosmos/cosmos-sdk/x/ibc/core"
+	// ibcclient "github.com/cosmos/cosmos-sdk/x/ibc/core/02-client"
+	// porttypes "github.com/cosmos/cosmos-sdk/x/ibc/core/05-port/types"
+	// ibchost "github.com/cosmos/cosmos-sdk/x/ibc/core/24-host"
+	// ibckeeper "github.com/cosmos/cosmos-sdk/x/ibc/core/keeper"
+)
+
+var (
+	//...
+	ModuleBasics = module.NewBasicManager(
+		//...
+		slashing.AppModuleBasic{},
+		// Add feegrantmodule.AppModuleBasic{},
+		feegrantmodule.AppModuleBasic{}, // <--
+		ibc.AppModuleBasic{},
+		//...
+	)
+	//...
+)
+
+type App struct {
+	//...
+	// Replace codec.Marshaler with codec.Codec
+	appCodec codec.Codec // <--
+	// Add FeeGrantKeeper
+	FeeGrantKeeper feegrantkeeper.Keeper // <--
+}
+
+func New( /*...*/ ) {
+	//bApp.SetAppVersion(version.Version)
+	bApp.SetVersion(version.Version) // <--
+
+	keys := sdk.NewKVStoreKeys(
+		//...
+		upgradetypes.StoreKey,
+		// Add feegrant.StoreKey
+		feegrant.StoreKey, // <--
+		evidencetypes.StoreKey,
+		//...
+	)
+
+	app.FeeGrantKeeper = feegrantkeeper.NewKeeper(appCodec, keys[feegrant.StoreKey], app.AccountKeeper) // <--
+	// Add app.BaseApp as the last argument to upgradekeeper.NewKeeper
+	app.UpgradeKeeper = upgradekeeper.NewKeeper(skipUpgradeHeights, keys[upgradetypes.StoreKey], appCodec, homePath, app.BaseApp)
+
+	app.IBCKeeper = ibckeeper.NewKeeper(
+		// Add app.UpgradeKeeper
+		appCodec, keys[ibchost.StoreKey], app.GetSubspace(ibchost.ModuleName), app.StakingKeeper, app.UpgradeKeeper, scopedIBCKeeper,
+	)
+
+	govRouter.AddRoute(govtypes.RouterKey, govtypes.ProposalHandler).
+		//...
+		// Replace NewClientUpdateProposalHandler with NewClientProposalHandler
+		AddRoute(ibchost.RouterKey, ibcclient.NewClientProposalHandler(app.IBCKeeper.ClientKeeper))
+
+	// Replace porttypes with ibcporttypes
+	ibcRouter := ibcporttypes.NewRouter()
+
+	app.mm.SetOrderBeginBlockers(
+		upgradetypes.ModuleName,
+		// Add capabilitytypes.ModuleName,
+		capabilitytypes.ModuleName,
+		minttypes.ModuleName,
+		//...
+		// Add feegrant.ModuleName,
+		feegrant.ModuleName,
+	)
+
+	// Add app.appCodec as an argument to module.NewConfigurator:
+	app.mm.RegisterServices(module.NewConfigurator(app.appCodec, app.MsgServiceRouter(), app.GRPCQueryRouter()))
+
+	// Replace:
+	// app.SetAnteHandler(
+	//  ante.NewAnteHandler(
+	//   app.AccountKeeper, app.BankKeeper, ante.DefaultSigVerificationGasConsumer,
+	//   encodingConfig.TxConfig.SignModeHandler(),
+	//  ),
+	// )
+
+	// With the following:
+	anteHandler, err := ante.NewAnteHandler(
+		ante.HandlerOptions{
+			AccountKeeper:   app.AccountKeeper,
+			BankKeeper:      app.BankKeeper,
+			SignModeHandler: encodingConfig.TxConfig.SignModeHandler(),
+			FeegrantKeeper:  app.FeeGrantKeeper,
+			SigGasConsumer:  ante.DefaultSigVerificationGasConsumer,
+		},
+	)
+	if err != nil {
+		panic(err)
+	}
+	app.SetAnteHandler(anteHandler)
+
+	// Remove the following:
+	// ctx := app.BaseApp.NewUncachedContext(true, tmproto.Header{})
+	// app.CapabilityKeeper.InitializeAndSeal(ctx)
+}
+
+func (app *App) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.ResponseInitChain {
+	var genesisState GenesisState
+	if err := tmjson.Unmarshal(req.AppStateBytes, &genesisState); err != nil {
+		panic(err)
+	}
+	// Add the following:
+	app.UpgradeKeeper.SetModuleVersionMap(ctx, app.mm.GetVersionMap())
+	return app.mm.InitGenesis(ctx, app.appCodec, genesisState)
+}
+
+// Replace Marshaler with Codec
+func (app *App) AppCodec() codec.Codec {
+	return app.appCodec
+}
+
+// Replace BinaryMarshaler with BinaryCodec
+func initParamsKeeper(appCodec codec.BinaryCodec, legacyAmino *codec.LegacyAmino, key, tkey sdk.StoreKey) paramskeeper.Keeper {
+	//...
+}
+```
+
+### app/genesis.go
+
+```go
+// Replace codec.JSONMarshaler with codec.JSONCodec
+func NewDefaultGenesisState(cdc codec.JSONCodec) GenesisState {
+	// ...
+}
+```
+
+### testutil/keeper/mars.go
+
+Add the following code:
+
+```go
+package keeper
+
+import (
+	"testing"
+
+	"github.com/cosmos/cosmos-sdk/codec"
+	codectypes "github.com/cosmos/cosmos-sdk/codec/types"
+	"github.com/cosmos/cosmos-sdk/store"
+	storetypes "github.com/cosmos/cosmos-sdk/store/types"
+	sdk "github.com/cosmos/cosmos-sdk/types"
+	"github.com/stretchr/testify/require"
+	"github.com/tendermint/tendermint/libs/log"
+	tmproto "github.com/tendermint/tendermint/proto/tendermint/types"
+	tmdb "github.com/tendermint/tm-db"
+	"github.com/username/mars/x/mars/keeper"
+	"github.com/username/mars/x/mars/types"
+)
+
+func MarsKeeper(t testing.TB) (*keeper.Keeper, sdk.Context) {
+	storeKey := sdk.NewKVStoreKey(types.StoreKey)
+	memStoreKey := storetypes.NewMemoryStoreKey(types.MemStoreKey)
+
+	db := tmdb.NewMemDB()
+	stateStore := store.NewCommitMultiStore(db)
+	stateStore.MountStoreWithDB(storeKey, sdk.StoreTypeIAVL, db)
+	stateStore.MountStoreWithDB(memStoreKey, sdk.StoreTypeMemory, nil)
+	require.NoError(t, stateStore.LoadLatestVersion())
+
+	registry := codectypes.NewInterfaceRegistry()
+	k := keeper.NewKeeper(
+		codec.NewProtoCodec(registry),
+		storeKey,
+		memStoreKey,
+	)
+
+	ctx := sdk.NewContext(stateStore, tmproto.Header{}, false, log.NewNopLogger())
+	return k, ctx
+}
+```
+
+If `mars` is an IBC-enabled module, add the following code, instead:
+
+```go
+package keeper
+
+import (
+	"testing"
+
+	"github.com/cosmos/cosmos-sdk/codec"
+	codectypes "github.com/cosmos/cosmos-sdk/codec/types"
+	"github.com/cosmos/cosmos-sdk/store"
+	storetypes "github.com/cosmos/cosmos-sdk/store/types"
+	sdk "github.com/cosmos/cosmos-sdk/types"
+	capabilitykeeper "github.com/cosmos/cosmos-sdk/x/capability/keeper"
+	typesparams "github.com/cosmos/cosmos-sdk/x/params/types"
+	ibckeeper "github.com/cosmos/ibc-go/modules/core/keeper"
+	"github.com/stretchr/testify/require"
+	"github.com/tendermint/tendermint/libs/log"
+	tmproto "github.com/tendermint/tendermint/proto/tendermint/types"
+	tmdb "github.com/tendermint/tm-db"
+	"github.com/username/test/x/mars/keeper"
+	"github.com/username/test/x/mars/types"
+)
+
+func MarsKeeper(t testing.TB) (*keeper.Keeper, sdk.Context) {
+	logger := log.NewNopLogger()
+
+	storeKey := sdk.NewKVStoreKey(types.StoreKey)
+	memStoreKey := storetypes.NewMemoryStoreKey(types.MemStoreKey)
+
+	db := tmdb.NewMemDB()
+	stateStore := store.NewCommitMultiStore(db)
+	stateStore.MountStoreWithDB(storeKey, sdk.StoreTypeIAVL, db)
+	stateStore.MountStoreWithDB(memStoreKey, sdk.StoreTypeMemory, nil)
+	require.NoError(t, stateStore.LoadLatestVersion())
+
+	registry := codectypes.NewInterfaceRegistry()
+	appCodec := codec.NewProtoCodec(registry)
+	capabilityKeeper := capabilitykeeper.NewKeeper(appCodec, storeKey, memStoreKey)
+
+	amino := codec.NewLegacyAmino()
+	ss := typesparams.NewSubspace(appCodec,
+		amino,
+		storeKey,
+		memStoreKey,
+		"MarsSubSpace",
+	)
+	IBCKeeper := ibckeeper.NewKeeper(
+		appCodec,
+		storeKey,
+		ss,
+		nil,
+		nil,
+		capabilityKeeper.ScopeToModule("MarsIBCKeeper"),
+	)
+
+	k := keeper.NewKeeper(
+		codec.NewProtoCodec(registry),
+		storeKey,
+		memStoreKey,
+		IBCKeeper.ChannelKeeper,
+		&IBCKeeper.PortKeeper,
+		capabilityKeeper.ScopeToModule("MarsScopedKeeper"),
+	)
+
+	ctx := sdk.NewContext(stateStore, tmproto.Header{}, false, logger)
+	return k, ctx
+}
+```
+
+### testutil/network/network.go
+
+```go
+func DefaultConfig() network.Config {
+	// ...
+	return network.Config{
+		// ...
+		// Add sdk.DefaultPowerReduction
+		AccountTokens: sdk.TokensFromConsensusPower(1000, sdk.DefaultPowerReduction),
+		StakingTokens: sdk.TokensFromConsensusPower(500, sdk.DefaultPowerReduction),
+		BondedTokens:  sdk.TokensFromConsensusPower(100, sdk.DefaultPowerReduction),
+		// ...
+	}
+}
+```
+
+### testutil/sample/sample.go
+
+Add the following code:
+
+```go
+package sample
+
+import (
+	"github.com/cosmos/cosmos-sdk/crypto/keys/ed25519"
+	sdk "github.com/cosmos/cosmos-sdk/types"
+)
+
+// AccAddress returns a sample account address
+func AccAddress() string {
+	pk := ed25519.GenPrivKey().PubKey()
+	addr := pk.Address()
+	return sdk.AccAddress(addr).String()
+}
+```
+
+### BandChain Support
+
+If your module includes integration with BandChain, added manually or scaffolded with `ignite scaffold band`, upgrade
+the `github.com/bandprotocol/bandchain-packet` package to `v0.0.2` in `go.mod`.
+
+## Module
+
+### x/mars/keeper/keeper.go
+
+```go
+package keeper
+
+// ...
+
+type (
+	Keeper struct {
+		// Replace Marshaler with BinaryCodec
+		cdc codec.BinaryCodec
+		//...
+	}
+)
+
+func NewKeeper(
+	// Replace Marshaler with BinaryCodec
+	cdc codec.BinaryCodec,
+	// ...
+) *Keeper {
+	// ...
+}
+```
+
+### x/mars/keeper/msg_server_test.go
+
+```go
+package keeper_test
+
+import (
+	//...
+	// Add the following:
+	keepertest "github.com/username/mars/testutil/keeper"
+	"github.com/username/mars/x/mars/keeper"
+)
+
+func setupMsgServer(t testing.TB) (types.MsgServer, context.Context) {
+	// Replace
+	// keeper, ctx := setupKeeper(t)
+	// return NewMsgServerImpl(*keeper), sdk.WrapSDKContext(ctx)
+
+	// With the following:
+	k, ctx := keepertest.MarsKeeper(t)
+	return keeper.NewMsgServerImpl(*k), sdk.WrapSDKContext(ctx)
+}
+```
+
+### x/mars/module.go
+
+```go
+package mars
+
+type AppModuleBasic struct {
+	// Replace Marshaler with BinaryCodec
+	cdc codec.BinaryCodec
+}
+
+// Replace Marshaler with BinaryCodec
+func NewAppModuleBasic(cdc codec.BinaryCodec) AppModuleBasic {
+	return AppModuleBasic{cdc: cdc}
+}
+
+// Replace JSONMarshaler with JSONCodec
+func (AppModuleBasic) DefaultGenesis(cdc codec.JSONCodec) json.RawMessage {
+	return cdc.MustMarshalJSON(types.DefaultGenesis())
+}
+
+// Replace JSONMarshaler with JSONCodec
+func (AppModuleBasic) ValidateGenesis(cdc codec.JSONCodec, config client.TxEncodingConfig, bz json.RawMessage) error {
+	//...
+}
+
+// Replace codec.Marshaller with codec.Codec
+func NewAppModule(cdc codec.Codec, keeper keeper.Keeper) AppModule {
+	//...
+}
+
+// Replace JSONMarshaler with JSONCodec
+func (am AppModule) InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, gs json.RawMessage) []abci.ValidatorUpdate {
+	//...
+}
+
+// Replace JSONMarshaler with JSONCodec
+func (am AppModule) ExportGenesis(ctx sdk.Context, cdc codec.JSONCodec) json.RawMessage {
+	//...
+}
+
+// Add the following
+func (AppModule) ConsensusVersion() uint64 { return 2 }
+```

docs/docs/06-migration/v0.19.2.md

@@ -0,0 +1,26 @@
+---
+sidebar_position: 998
+title: v0.19.2
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.19.2, changes are required to use IGNITE® CLI v0.19.2.
+---
+
+# Upgrading a blockchain to use IGNITE® CLI v0.19.2
+
+IGNITE® CLI v0.19.2 comes with IBC v2.0.2.
+
+With IGNITE® CLI v0.19.2, the contents of the deprecated IGNITE® CLI Modules `tendermint/spm` repo are moved to the
+official IGNITE® CLI repo which introduces breaking changes.
+
+To migrate your chain that was scaffolded with IGNITE® CLI versions lower than v0.19.2:
+
+1. IBC upgrade: Use
+   the [IBC migration documents](https://github.com/cosmos/ibc-go/blob/v6.2.0/docs/migrations/v1-to-v2.md)
+
+2. In your chain's `go.mod` file, remove `tendermint/spm` and add the v0.19.2 version of `tendermint/starport`. If your
+   chain uses these packages, change the import paths as shown:
+
+    - `github.com/tendermint/spm/ibckeeper` moved to `github.com/tendermint/starport/starport/pkg/cosmosibckeeper`
+    - `github.com/tendermint/spm/cosmoscmd` moved to `github.com/tendermint/starport/starport/pkg/cosmoscmd`
+    - `github.com/tendermint/spm/openapiconsole` moved to `github.com/tendermint/starport/starport/pkg/openapiconsole`
+    - `github.com/tendermint/spm/testutil/sample` moved
+      to `github.com/tendermint/starport/starport/pkg/cosmostestutil/sample`

docs/docs/06-migration/v0.20.0.md

@@ -0,0 +1,12 @@
+---
+sidebar_position: 997
+title: v0.20.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.20.0, changes are required to use IGNITE® CLI v0.20.0.
+---
+
+# Upgrading a blockchain to use IGNITE® CLI v0.20.2
+
+1. Upgrade your Cosmos SDK version to [v0.45.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.45.3).
+
+2. Update your `SetOrderBeginBlockers` and `SetOrderEndBlockers` in your `app/app.go` to explicitly add entries for all
+   the modules you use in your chain.

docs/docs/06-migration/v0.22.0.md

@@ -0,0 +1,36 @@
+---
+sidebar_position: 996
+title: v0.22.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.22.0, changes are required to use IGNITE® CLI v0.22.0.
+---
+
+# Upgrading a blockchain to use IGNITE® CLI v0.22.0
+
+IGNITE® CLI v0.22.2 changed the GitHub username from "ignite-hq" to "ignite", which means the imports must be fixed to
+reflect this change.
+
+1. In your `go.mod` file find the require line for IGNITE® CLI that starts with `github.com/ignite-hq/cli` and is
+   followed by a version.
+   It looks something like `github.com/ignite-hq/cli v0.22.0`, and replace it by `github.com/ignite/cli v0.22.2`.
+
+2. Make a bulk find and replace in the import statements for `github.com/ignite-hq/cli` to be replaced
+   by `github.com/ignite/cli`.
+
+3. Finally, run `go mod tidy` and ensure there's no mention if `ignite-hq/cli` in your `go.sum` file.
+
+This update includes an upgrade to the `ibc-go` packages. Please make the according changes:
+
+1. Upgrade your IBC version to [v3](https://github.com/cosmos/ibc-go/releases/tag/v3.0.0).
+
+    1. Search for `github.com/cosmos/ibc-go/v2` in the import statements of your `.go` files and replace `v2` in the end
+       with `v3`
+
+    1. Open your `app.go`,
+
+        - Update your transfer keeper by adding another `app.IBCKeeper.ChannelKeeper` as an argument
+          after `app.IBCKeeper.ChannelKeeper`
+
+        - Define `var transferIBCModule = transfer.NewIBCModule(app.TransferKeeper)` in your `New()` func, and update
+          your existent IBC router to use it: `ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferIBCModule)`
+
+    3. Open your `go.mod` and change the IBC line with `github.com/cosmos/ibc-go/v3 v3.0.0`

docs/docs/06-migration/v0.24.0.md

@@ -0,0 +1,330 @@
+---
+sidebar_position: 995
+title: v0.24.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.24, changes are required to use IGNITE® CLI v0.24.0.
+---
+
+## Cosmos SDK v0.46 upgrade notes
+
+### Update dependencies
+
+Cosmos SDK v0.46 is compatible with the latest version of IBC Go v5. If you have a chain that is using an older version,
+update the dependencies in your project.
+
+Throughout the code you might see the following dependencies:
+
+```go
+package pkg_name
+
+import (
+	"github.com/cosmos/ibc-go/v3/..."
+)
+```
+
+Where `v3` is the version of IBC Go and `...` are different IBC Go packages.
+
+To upgrade the version to `v5`, a global find-and-replace should work. Replace `cosmos/ibc-go/v3` (or whicherver version
+you're using) with `cosmos/ibc-go/v5` only in `*.go` files (to exclude unwated changes to files like `go,sum`).
+
+### Module keeper
+
+Add an import:
+
+```go
+// x/{moduleName}/keeper/keeper.go
+
+package keeper
+
+// ...
+
+import (
+	//...
+	storetypes "github.com/cosmos/cosmos-sdk/store/types"
+)
+```
+
+In the `Keeper` struct replace `sdk.StoreKey` with `storetypes.StoreKey`:
+
+```go
+// x/{moduleName}/keeper/keeper.go
+
+package keeper
+
+// ...
+
+type (
+	Keeper struct {
+		cdc        codec.BinaryCodec
+		storeKey   storetypes.StoreKey
+		memKey     storetypes.StoreKey
+		paramstore paramtypes.Subspace
+	}
+)
+```
+
+In the argument list of the `NewKeeper` function definition:
+
+```go
+package keeper
+
+// ...
+
+// x/{moduleName}/keeper/keeper.go
+
+func NewKeeper(
+	//...
+	memKey storetypes.StoreKey,
+)
+```
+
+Store type aliases have been removed from the Cosmos SDK `types` package and now have to be imported from `store/types`,
+instead.
+
+In the `testutil/keeper/{moduleName}.go` replace `types.StoreKey` with `storetypes.StoreKey` and `types.MemStoreKey`
+with `storetypes.MemStoreKey`.
+
+```go
+// testutil/keeper/{moduleName}.go
+
+package keeper
+
+// ...
+
+func {moduleName}Keeper(t testing.TB) (*keeper.Keeper, sdk.Context) {
+	storeKey := sdk.NewKVStoreKey(storetypes.StoreKey)
+	memStoreKey := storetypes.NewMemoryStoreKey(storetypes.MemStoreKey)
+	//...
+}
+```
+
+### Testutil network package
+
+Add the `require` package for testing and `pruningtypes` and remove `storetypes`:
+
+```go
+// testutil/network/network.go
+
+package network
+
+// ...
+
+import (
+	pruningtypes "github.com/cosmos/cosmos-sdk/pruning/types"
+	"github.com/stretchr/testify/require"
+	// storetypes "github.com/cosmos/cosmos-sdk/store/types" <-- remove this line
+)
+```
+
+In the `DefaultConfig` function replace `storetypes.NewPruningOptionsFromString`
+with `pruningtypes.NewPruningOptionsFromString`
+
+```go
+// testutil/network/network.go
+
+package network
+
+// ...
+
+func DefaultConfig() network.Config {
+	//...
+	return network.Config{
+		AppConstructor: func(val network.Validator) servertypes.Application {
+			return app.New(
+				baseapp.SetPruning(pruningtypes.NewPruningOptionsFromString(val.AppConfig.Pruning)),
+				//...
+			)
+		},
+		//...
+	}
+}
+```
+
+The `New` function in the Cosmos SDK `testutil/network` package now
+accepts [three arguments](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/testutil/network/network.go#L206) instead of
+two.
+
+In the `New` function add `t.TempDir()` as the second argument to `network.New()` and test that no error is thrown
+with `require.NoError(t, err)`:
+
+```go
+// testutil/network/network.go
+
+package network
+
+// ...
+
+func New(t *testing.T, configs ...network.Config) *network.Network {
+	//...
+	net, err := network.New(t, t.TempDir(), cfg)
+	require.NoError(t, err)
+	//...
+}
+```
+
+### Testutil keeper package
+
+In the `{moduleName}Keeper` function make the following replacements:
+
+- `storetypes.StoreKey` → `types.StoreKey`
+- `storetypes.MemStoreKey` → `types.MemStoreKey`
+- `sdk.StoreTypeIAVL` → `storetypes.StoreTypeIAVL`
+- `sdk.StoreTypeMemory` → `storetypes.StoreTypeMemory`
+
+```go
+// testutil/keeper/{moduleName}.go
+
+package keeper
+
+// ...
+
+func {moduleName}Keeper(t testing.TB) (*keeper.Keeper, sdk.Context) {
+	storeKey := sdk.NewKVStoreKey(types.StoreKey)
+	memStoreKey := storetypes.NewMemoryStoreKey(types.MemStoreKey)
+	//...
+	stateStore.MountStoreWithDB(storeKey, storetypes.StoreTypeIAVL, db)
+	stateStore.MountStoreWithDB(memStoreKey, storetypes.StoreTypeMemory, nil)
+	//...
+}
+```
+
+### IBC modules
+
+If you have IBC-enabled modules (for example, added with `ignite scaffold module ... --ibc` or created manually), make
+the following changes to the source code.
+
+Cosmos SDK expects IBC modules
+to [implement the `IBCModule` interface](https://ibc.cosmos.network/main/ibc/apps/ibcmodule/). Create a `IBCModule`
+type that embeds the module's keeper and a method that returns a new `IBCModule`. Methods in this file will be defined
+on this type.
+
+```go
+// x/{moduleName}/module_ibc.go
+
+package module_name
+
+// ...
+
+type IBCModule struct {
+	keeper keeper.Keeper
+}
+
+func NewIBCModule(k keeper.Keeper) IBCModule {
+	return IBCModule{
+		keeper: k,
+	}
+}
+```
+
+Replace receivers for all methods in this file from `(am AppModule)` to `(im IBCModule)`. Replace all instances of `am.`
+with `im.` to fix the errors.
+
+`OnChanOpenInit` now returns to values: a `string` and an `error`:
+
+```go
+// x/{moduleName}/module_ibc.go
+
+package module_name
+
+// ...
+
+func (im IBCModule) OnChanOpenInit( /*...*/ ) (string, error)
+```
+
+Ensure that all return statements (five, in the default template) in `OnChanOpenInit` return two values. For example:
+
+```go
+// x/{moduleName}/module_ibc.go
+
+package module_name
+
+// ...
+
+func (im IBCModule) OnChanOpenInit( /*...*/ ) (string, error) {
+	//...
+	return "", errorsmod.Wrapf(porttypes.ErrInvalidPort, "invalid port: %s, expected %s", portID, boundPort)
+	//...
+}
+```
+
+Error acknowledgments returned from Transfer `OnRecvPacket` now include a deterministic ABCI code and error message.
+Remove the `.Error()` call:
+
+```go
+// x/{moduleName}/module_ibc.go
+
+package module_name
+
+// ...
+
+func (im IBCModule) OnRecvPacket( /*...*/ ) {
+	//...
+	if err := modulePacketData.Unmarshal(modulePacket.GetData()); err != nil {
+		// return channeltypes.NewErrorAcknowledgement(errorsmod.Wrapf(sdkerrors.ErrUnknownRequest, "cannot unmarshal packet data: %s", err.Error()).Error())
+		return channeltypes.NewErrorAcknowledgement(errorsmod.Wrapf(sdkerrors.ErrUnknownRequest, "cannot unmarshal packet data: %s", err.Error()))
+	}
+
+	// ...
+
+	// Dispatch packet
+	switch packet := modulePacketData.Packet.(type) {
+	// ...
+	default:
+		// errMsg := fmt.Sprintf("unrecognized %s packet type: %T", types.ModuleName, packet)
+		// return channeltypes.NewErrorAcknowledgement(errMsg)
+		err := fmt.Errorf("unrecognized %s packet type: %T", types.ModuleName, packet)
+		return channeltypes.NewErrorAcknowledgement(err)
+	}
+}
+```
+
+After switching to using both `AppModule` and `IBCModule`, modifying the following line:
+
+```go
+// x/{moduleName}/module.go
+
+package module_name
+
+// ...
+
+var (
+	//...
+	_ porttypes.IBCModule = IBCModule{} // instead of "= AppModule{}"
+)
+```
+
+### Main
+
+The `Execute` function in Cosmos SDK `server/cmd` package now
+accepts [three arguments](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/cmd/execute.go#L20) instead of two.
+
+```go
+// cmd/{{projectName}}d/main.go
+
+package projectNamed
+
+// ...
+
+func main() {
+	//...
+	if err := svrcmd.Execute(rootCmd, "", app.DefaultNodeHome); err != nil {
+		os.Exit(1)
+	}
+}
+```
+
+### Handler
+
+Cosmos SDK v0.46 no longer needs a `NewHandler` function that was used to handle messages and call appropriate keeper
+methods based on message types. Feel free to remove `x/{moduleName}/handler.go` file.
+
+Since there is no `NewHandler` now, modify the deprecated `Route` function to return `sdk.Route{}`:
+
+```go
+// x/{moduleName}/module.go
+
+package module_name
+
+// ...
+
+func (am AppModule) Route() sdk.Route { return sdk.Route{} }
+```

docs/docs/06-migration/v0.25.1.md

@@ -0,0 +1,67 @@
+---
+sidebar_position: 993
+title: v0.25.1
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.25.1. changes are required to use IGNITE® CLI v0.25.1.
+---
+
+## Drabonberry fix
+
+`v0.25.1` contains the Dragonberry fix, update your `go.mod` as :
+
+```sh
+require (
+	// remove-next-line
+  github.com/ignite/cli v0.24.0
+	// highlight-next-line
+  github.com/ignite/cli v0.25.1
+)
+
+// highlight-next-line
+replace github.com/confio/ics23/go => github.com/cosmos/cosmos-sdk/ics23/go v0.8.0
+```
+
+Then run:
+
+```
+$ go mod tidy
+```
+
+As a result, you should see `cosmos-sdk` and `ibc-go` upgraded as well.
+
+Finally, apply the following change to `app/app.go`:
+
+```go
+package app
+
+// New returns a reference to an initialized blockchain app
+func New(
+	logger log.Logger,
+	db dbm.DB,
+	traceStore io.Writer,
+	loadLatest bool,
+	skipUpgradeHeights map[int64]bool,
+	homePath string,
+	invCheckPeriod uint,
+	encodingConfig appparams.EncodingConfig,
+	appOpts servertypes.AppOptions,
+	baseAppOptions ...func(*baseapp.BaseApp),
+) *App {
+
+	// ...
+
+	app.ICAHostKeeper = icahostkeeper.NewKeeper(
+		appCodec, keys[icahosttypes.StoreKey],
+		app.GetSubspace(icahosttypes.SubModuleName),
+		app.IBCKeeper.ChannelKeeper,
+		// highlight-next-line
+		app.IBCKeeper.ChannelKeeper,
+		&app.IBCKeeper.PortKeeper,
+		app.AccountKeeper,
+		scopedICAHostKeeper,
+		app.MsgServiceRouter(),
+	)
+
+	// ...
+
+}
+```

docs/docs/06-migration/v0.26.0.md

@@ -0,0 +1,263 @@
+---
+sidebar_position: 992
+title: v0.26.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v0.26.0. changes are required to use IGNITE® CLI v0.26.0.
+---
+
+IGNITE® CLI `v0.26.0` is fully compatible with chains that are compatible with `v0.25.1`.  Please follow the existing
+migration guides if your chain is not upgraded to `v0.25.1` support.
+
+## Go Version
+
+Chains that are newly scaffolded with IGNITE® CLI `v0.26.0` now require `go 1.19` in their `go.mod` files.  It is 
+recommended that chains scaffolded with an older version of IGNITE® CLI also bump their required `go` version and update 
+their tooling to the latest version.
+
+## ibc-go v6
+
+Chains that are newly scaffolded with IGNITE® CLI `v0.26.0` now use `ibc-go/v6` for ibc functionality.  It is not 
+necessary, but recommended to upgrade to the newest version of `ibc-go`.  Most migrations can be done by following the 
+`ibc-go` [migration guide](https://github.com/cosmos/ibc-go/blob/v6.2.0/docs/migrations/v5-to-v6.md), but there are some 
+specific changes that will need to be followed for IGNITE® scaffolded chains.
+
+### Removing `cosmosibckeeper`
+
+IGNITE® CLI `v0.26.0` has deprecated [pkg/cosmosibckeeper](https://github.com/ignite/cli/tree/v0.26.0/ignite/pkg/cosmosibckeeper).
+This package contained interfaces for ibc-related keepers.  Newly scaffolded chains now include the interface files in their
+`./x/{moduleName}/types` directory in a new `expected_ibc_keeper.go` file. To migrate, create the following file for
+each module:
+
+```go title="x/{moduleName}/types/expected_ibc_keeper.go"
+package types
+
+import (
+	sdk "github.com/cosmos/cosmos-sdk/types"
+	capabilitytypes "github.com/cosmos/cosmos-sdk/x/capability/types"
+	clienttypes "github.com/cosmos/ibc-go/v6/modules/core/02-client/types"
+	channeltypes "github.com/cosmos/ibc-go/v6/modules/core/04-channel/types"
+)
+
+// ChannelKeeper defines the expected IBC channel keeper.
+type ChannelKeeper interface {
+	GetChannel(ctx sdk.Context, portID, channelID string) (channeltypes.Channel, bool)
+	GetNextSequenceSend(ctx sdk.Context, portID, channelID string) (uint64, bool)
+	SendPacket(
+		ctx sdk.Context,
+		channelCap *capabilitytypes.Capability,
+		sourcePort string,
+		sourceChannel string,
+		timeoutHeight clienttypes.Height,
+		timeoutTimestamp uint64,
+		data []byte,
+	) (uint64, error)
+	ChanCloseInit(ctx sdk.Context, portID, channelID string, chanCap *capabilitytypes.Capability) error
+}
+
+// PortKeeper defines the expected IBC port keeper.
+type PortKeeper interface {
+	BindPort(ctx sdk.Context, portID string) *capabilitytypes.Capability
+}
+
+// ScopedKeeper defines the expected IBC scoped keeper.
+type ScopedKeeper interface {
+	GetCapability(ctx sdk.Context, name string) (*capabilitytypes.Capability, bool)
+	AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool
+	ClaimCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) error
+}
+```
+
+Next, make the following updates to each `x/{moduleName}/keeper/keeper.go` file for each ibc-enabled
+module in your project:
+
+```go title="x/{moduleName}/keeper/keeper.go"
+package keeper
+
+import (
+	"fmt"
+
+	// remove-start
+	"blogibc/x/testibc/types"
+	"github.com/cosmos/cosmos-sdk/codec"
+	storetypes "github.com/cosmos/cosmos-sdk/store/types"
+	sdk "github.com/cosmos/cosmos-sdk/types"
+	paramtypes "github.com/cosmos/cosmos-sdk/x/params/types"
+	"github.com/ignite/cli/ignite/pkg/cosmosibckeeper"
+	"github.com/tendermint/tendermint/libs/log"
+	// remove-end
+	// highlight-start
+	"github.com/cosmos/cosmos-sdk/codec"
+	storetypes "github.com/cosmos/cosmos-sdk/store/types"
+	sdk "github.com/cosmos/cosmos-sdk/types"
+	sdkerrors "github.com/cosmos/cosmos-sdk/types/errors"
+	capabilitytypes "github.com/cosmos/cosmos-sdk/x/capability/types"
+	paramtypes "github.com/cosmos/cosmos-sdk/x/params/types"
+	channeltypes "github.com/cosmos/ibc-go/v6/modules/core/04-channel/types"
+	host "github.com/cosmos/ibc-go/v6/modules/core/24-host"
+	"github.com/cosmos/ibc-go/v6/modules/core/exported"
+	"github.com/tendermint/tendermint/libs/log"
+
+	"{appName}/x/{moduleName}/types"
+	// highlight-end
+)
+
+type (
+	Keeper struct {
+		// remove-line-next
+		*cosmosibckeeper.Keeper
+		cdc        codec.BinaryCodec
+		storeKey   storetypes.StoreKey
+		memKey     storetypes.StoreKey
+		paramstore paramtypes.Subspace
+
+		// highlight-start
+		channelKeeper types.ChannelKeeper
+		portKeeper    types.PortKeeper
+		scopedKeeper  exported.ScopedKeeper
+		// highlight-end
+	}
+)
+
+func NewKeeper(
+	cdc codec.BinaryCodec,
+	storeKey,
+	memKey storetypes.StoreKey,
+	ps paramtypes.Subspace,
+	// highlight-start
+	channelKeeper types.ChannelKeeper,
+	portKeeper types.PortKeeper,
+	scopedKeeper types.ScopedKeeper,
+	// highlight-end
+) *Keeper {
+	// set KeyTable if it has not already been set
+	if !ps.HasKeyTable() {
+		ps = ps.WithKeyTable(types.ParamKeyTable())
+	}
+
+	return &Keeper{
+		// remove-start
+		Keeper: cosmosibckeeper.NewKeeper(
+			types.PortKey,
+			storeKey,
+			channelKeeper,
+			portKeeper,
+			scopedKeeper,
+		),
+		// remove-end
+		cdc:        cdc,
+		storeKey:   storeKey,
+		memKey:     memKey,
+		paramstore: ps,
+		// highlight-start
+		channelKeeper: channelKeeper,
+		portKeeper:    portKeeper,
+		scopedKeeper:  scopedKeeper,
+		// highlight-end
+	}
+}
+
+// highlight-start
+// ----------------------------------------------------------------------------
+// IBC Keeper Logic
+// ----------------------------------------------------------------------------
+
+// ChanCloseInit defines a wrapper function for the channel Keeper's function.
+func (k Keeper) ChanCloseInit(ctx sdk.Context, portID, channelID string) error {
+	capName := host.ChannelCapabilityPath(portID, channelID)
+	chanCap, ok := k.scopedKeeper.GetCapability(ctx, capName)
+	if !ok {
+		return errorsmod.Wrapf(channeltypes.ErrChannelCapabilityNotFound, "could not retrieve channel capability at: %s", capName)
+	}
+	return k.channelKeeper.ChanCloseInit(ctx, portID, channelID, chanCap)
+}
+
+// IsBound checks if the IBC app module is already bound to the desired port
+func (k Keeper) IsBound(ctx sdk.Context, portID string) bool {
+	_, ok := k.scopedKeeper.GetCapability(ctx, host.PortPath(portID))
+	return ok
+}
+
+// BindPort defines a wrapper function for the port Keeper's function in
+// order to expose it to module's InitGenesis function
+func (k Keeper) BindPort(ctx sdk.Context, portID string) error {
+	cap := k.portKeeper.BindPort(ctx, portID)
+	return k.ClaimCapability(ctx, cap, host.PortPath(portID))
+}
+
+// GetPort returns the portID for the IBC app module. Used in ExportGenesis
+func (k Keeper) GetPort(ctx sdk.Context) string {
+	store := ctx.KVStore(k.storeKey)
+	return string(store.Get(types.PortKey))
+}
+
+// SetPort sets the portID for the IBC app module. Used in InitGenesis
+func (k Keeper) SetPort(ctx sdk.Context, portID string) {
+	store := ctx.KVStore(k.storeKey)
+	store.Set(types.PortKey, []byte(portID))
+}
+
+// AuthenticateCapability wraps the scopedKeeper's AuthenticateCapability function
+func (k Keeper) AuthenticateCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) bool {
+	return k.scopedKeeper.AuthenticateCapability(ctx, cap, name)
+}
+
+// ClaimCapability allows the IBC app module to claim a capability that core IBC
+// passes to it
+func (k Keeper) ClaimCapability(ctx sdk.Context, cap *capabilitytypes.Capability, name string) error {
+	return k.scopedKeeper.ClaimCapability(ctx, cap, name)
+}
+
+//highlight-end
+
+func (k Keeper) Logger(ctx sdk.Context) log.Logger {
+	return ctx.Logger().With("module", fmt.Sprintf("x/%s", types.ModuleName))
+}
+```
+
+### Remaining migration
+
+After all uses of `cosmosibckeeper` have been removed, you can follow any remaining steps in the`ibc-go`[migration guide](https://github.com/cosmos/ibc-go/blob/v6.2.0/docs/migrations/v5-to-v6.md).
+
+## Scaffolded Release Workflow
+
+The develop branch of the CLI has been deprecated. To continue using the release workflow that uses the CLI to 
+automatically build and release your chain's binaries, replace develop with main in the following lines:
+
+```yaml title=".github/workflows/release.yml"
+...
+
+jobs:
+  might_release:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 0
+      - name: Prepare Release Variables 
+        id: vars
+        // highlight-next-line
+        uses: ignite/cli/actions/release/vars@main
+      - name: Issue Release Assets
+        // highlight-next-line
+        uses: ignite/cli/actions/cli@main
+        if: ${{ steps.vars.outputs.should_release == 'true' }}
+        with:
+          args: chain build --release --release.prefix ${{ steps.vars.outputs.tarball_prefix }} -t linux:amd64 -t darwin:amd64 -t darwin:arm64
+      - name: Delete the "latest" Release
+        uses: dev-drprasad/delete-tag-and-release@v0.2.0
+        if: ${{ steps.vars.outputs.is_release_type_latest == 'true' }}
+        with:
+          tag_name: ${{ steps.vars.outputs.tag_name }}
+          delete_release: true
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Publish the Release
+        uses: softprops/action-gh-release@v1
+        if: ${{ steps.vars.outputs.should_release == 'true' }}
+        with:
+          tag_name: ${{ steps.vars.outputs.tag_name }}
+          files: release/*
+          prerelease: true 
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```

docs/docs/06-migration/v28.0.0.md

@@ -0,0 +1,124 @@
+---
+sidebar_position: 990
+title: v28.0.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v28.0.0 changes are required to use IGNITE® CLI v28.0.0
+---
+
+## **Upgrade to v28.0.0 - New Versioning Scheme in IGNITE®**
+
+With the latest update, IGNITE® has transitioned its versioning format from a leading-zero release system to a full number release system. This change marks a significant shift in how we communicate updates and stability in our software. Where the previous version was denoted as v0.27.0, it will now be upgraded to v28.0.0.
+
+This new versioning approach enhances our version control by clearly indicating major, minor, and patch releases. 
+From now on first number indicates a major release with breaking API changes, second number indicates minor release that might include new features while the last number is typically focused on bug fixes and minor improvements.
+[Learn more about semantic versioning](https://semver.org/).
+
+## **Plugins are now called Apps. Upgrade Configuration Files**
+
+IGNITE® `v28.0.0` changes the plugin system which is now called IGNITE® Apps. This version includes changes
+to the CLI command names and the plugin configuration file.
+
+The plugins configuration file is now called `igniteapps.yml` and "plugins" are now called "apps".
+
+The plugins configuration home directory is now `$HOME/.ignite/apps` instead `$HOME/.ignite/plugins`.
+
+Updates can be automatically applied by running `ignite doctor` in your blockchain application directory.
+Running the command outside your blockchain application directory will only update the global plugins.
+
+## **IGNITE® and Cosmos SDK Upgrade Guide: From IGNITE® v0.27.0 to v28.0.0 and Cosmos SDK v0.47 to v0.50**
+
+### **Introduction**
+
+This guide provides a step-by-step process for developers to upgrade their applications from IGNITE® version 0.27.0 to 28.0.0, along with an upgrade in the Cosmos SDK from version 0.47 to v0.50. It covers essential changes, new features, and adjustments required for a smooth transition.
+
+### **Prerequisites**
+
+- Backup your current project.
+- Ensure you have IGNITE® v0.27.0 and Cosmos SDK v0.47 installed.
+- Basic familiarity with command line operations and the existing project structure.
+
+### **Step 1: Update IGNITE® CLI to Version 28.0.0**
+
+- **Command**: Run **`curl https://get.ignite.com/cli@v28.0.0 | bash`** in your terminal.
+- **Note**: This command updates the IGNITE® CLI to the latest version. Ensure you have the necessary permissions to execute it.
+
+### **Step 2: Update Scaffold Chain Command**
+
+- **Old Command**: **`ignite scaffold chain github.com/alice/blog`**
+- **New Command**: **`ignite scaffold chain blog`**
+- **Explanation**: The command format has been simplified in the new version for ease of use.
+
+### **Step 3: Docker Version Upgrades**
+
+- **Action**: Upgrade the IGNITE® version for the Docker container to match the CLI version.
+- **Note**: Ensure Docker compatibility with the new IGNITE® CLI version.
+
+### **Step 4: Change in Module Path**
+
+- **Old Path**: **`x/blog/module.go`**
+- **New Path**: **`x/blog/module/module.go`**
+- **Explanation**: The module path structure has been updated for better organization.
+
+### **Step 5: Frontend Scaffolding Options**
+
+- **Action**: Choose between Vue, React, Go, or TypeScript for frontend scaffolding.
+- **Commands**:
+    - **`ignite scaffold react`**
+    - **`ignite scaffold vue`**
+- **Note**: Vue is no longer the default option for frontend scaffolding.
+
+### **Step 6: Update Scaffold Message for CreatePost Command**
+
+- **Action**: Review and update the output for the scaffolded createPost command as per the new format.
+
+### **Step 7: AutoCLI Path Change**
+
+- **Old Path**: **`x/blog/client/cli/tx_create_post.go`**
+- **New Path**: **`x/blog/module/autocli.go`**
+- **Explanation**: AutoCLI is now integrated at a different path to streamline command-line interactions.
+
+### **Step 8: Adjustment in Stored Game**
+
+- **Old Code**:
+    
+    ```go
+	store := prefix.NewStore(ctx.KVStore(k.storeKey), types.KeyPrefix(types.PostKey))
+    
+    ```
+    
+- **New Code**:
+    
+    ```go
+	storeAdapter := runtime.KVStoreAdapter(k.storeService.OpenKVStore(ctx))
+	store := prefix.NewStore(storeAdapter, types.KeyPrefix(types.PostKey))
+    
+    ```
+    
+- **Explanation**: The way the KVStore is accessed has changed, requiring an update in the code for stored games.
+
+### **Step 9: Chain-ID Requirements in CLI Transaction Commands**
+
+- **Action**: Add **`-chain-id`** flag to CLI transaction commands.
+- **Example**:
+    - **Old Command**: **`blogd tx blog create-post 'Hello, World!' 'This is a blog post' --from alice`**
+    - **New Command**: **`blogd tx blog create-post 'Hello, World!' 'This is a blog post' --from alice --chain-id blog`**
+- **Explanation**: The **`chain-id`** flag is now required for transaction commands for identification purposes.
+
+### **Troubleshooting Common Issues**
+
+- **Dependency Conflicts**: Ensure compatibility of all dependencies with IGNITE® v28.0.0 and Cosmos SDK v0.50.
+- **Docker Image Compatibility**: Align Docker image versions with the CLI for seamless operations.
+- **Frontend Scaffolding**: For older projects, ensure correct scaffolding as per the new commands.
+- **AutoCLI Integration**: Address discrepancies due to the new AutoCLI integration path.
+
+### **Additional Resources**
+
+- [IGNITE® Documentation](https://docs.ignite.com/)
+- [Cosmos SDK Release Notes](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.1)
+
+### **Feedback**
+
+We value your feedback on this guide. Please share your experiences and suggestions for improvements.
+
+### **Updates Log**
+
+- **[01/15/24]**: Guide created for IGNITE® v28.0.0 and Cosmos SDK v0.50.1

docs/docs/06-migration/v29.0.0.md

@@ -0,0 +1,98 @@
+---
+sidebar_position: 989
+title: v29.0.0
+description: For chains that were scaffolded with IGNITE® CLI versions lower than v29.0.0 changes are required to use IGNITE® CLI v29.0.0
+---
+
+## Upgrade to v29.0.0
+
+The changes between v28.0.0 and v29.0.0 are not as significant as the changes between v0.27.0 and v28.0.0.
+
+In v29.0.0, the Cosmos SDK version has been upgraded to 0.53.0 and IBC to v10.
+
+Please see the [Changelog](https://github.com/ignite/cli/commit/1b7f19f08d0fa91e3ae71b4b37b8bb4171a9e320#diff-b027e7b11ff55b21dd50b32abcbdd35d95be87a889f0f6562417fbf0995d402a) for more details.
+
+:::tip
+If you wish to keep using a chain scaffolded with IGNITE® v28, simply run the doctor command:
+
+```bash
+ignite doctor
+```
+
+Note that some scaffolding commands may not work as expected, and you may need to manually adjust your code, unless you follow the migration steps below.
+:::
+
+## Upgrade Cosmos SDK to v0.53.0
+
+In order to upgrade, please navigate to the `go.mod` file in your blockchain directory and replace an earlier Cosmos-SDK version with v0.53.0.
+
+```diff
+-github.com/cosmos/cosmos-sdk v0.50.0
++github.com/cosmos/cosmos-sdk v0.53.0
+```
+
+Review the [Cosmos SDK v0.53.0 release notes](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.53.0) for changes like updated x/auth vesting or sdk.Context APIs.
+
+If you have custom modules, test for deprecated APIs and update as needed.
+
+## Add Auth to PreBlockers
+
+v29 configures preblockers to include the `auth` module (`authtypes.ModuleName`) for transaction processing. Ensure this is set in your v28 scaffold.
+
+**Edit PreBlockers**:
+
+- Open `mychain/app/app_config.go`.
+
+- Find or add the `preBlockers` slice. Ensure it includes `authtypes.ModuleName`, matching v29’s configuration:
+
+```go
+import (
+	"github.com/cosmos/cosmos-sdk/x/auth/types"
+	"github.com/cosmos/cosmos-sdk/x/upgrade/types"
+)
+
+var preBlockers = []string{
+	upgradetypes.ModuleName,
+	authtypes.ModuleName,
+	// this line is used by starport scaffolding # stargate/app/preBlockers
+}
+```
+
+## Upgrade to IBC v10
+
+```diff
+-github.com/cosmos/ibc-go/v8 v8.5.2
++github.com/cosmos/ibc-go/v10 v10.0.0
+```
+
+The easiest path is copy the relevant files in the `app` directory from a chain scaffolded with v29 into your old v28 project, in case you did not modify anything in there.
+
+In case you want to see the entire difference with scaffolded chains, use our "Generate Migration Difference" Tool.
+
+[Checkout the Guide To use the Gen-Mig-Diff Tool](https://tutorials.ignite.com/guide-to-use-gen-mig-diffs-for/).
+
+Then run the command
+
+`gen-mig-diffs --output temp/migration --from v28 --to v29`
+
+Now, test if your blockchain runs using IGNITE® v29:
+
+Update the dependencies with:
+
+```bash
+go mod tidy
+```
+
+Then run the IGNITE® doctor to update configuration files.
+
+```bash
+ignite doctor
+```
+
+Now start your chain.
+
+```bash
+ignite chain serve
+```
+
+If you need our help and support, do not hesitate to visit our [Discord](https://discord.com/invite/ignitecli).

docs/docs/07-packages/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Packages",
+  "link": null
+}

docs/docs/07-packages/chaincmd.md

@@ -0,0 +1,51 @@
+---
+sidebar_position: 7
+title: Chain Command Builder (chaincmd)
+slug: /packages/chaincmd
+---
+
+# Chain Command Builder (chaincmd)
+
+The `chaincmd` package builds `step.Option` command definitions for Cosmos SDK daemon binaries (`simd`, `gaiad`, and others). It does not execute commands directly.
+
+For full API details, see the
+[`chaincmd` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/chaincmd).
+
+## When to use
+
+- Build consistent daemon command lines from typed options.
+- Reuse command composition across services and tests.
+- Keep chain binary-specific flags centralized.
+
+## Key APIs
+
+- `New(appCmd string, options ...Option) ChainCmd`
+- `WithHome(home string) Option`
+- `WithChainID(chainID string) Option`
+- `InitCommand(moniker string, options ...string) step.Option`
+- `BankSendCommand(fromAddress, toAddress, amount string, options ...BankSendOption) step.Option`
+
+## Example
+
+```go
+package main
+
+import (
+	"fmt"
+
+	"github.com/ignite/cli/v29/ignite/pkg/chaincmd"
+	"github.com/ignite/cli/v29/ignite/pkg/cmdrunner/step"
+)
+
+func main() {
+	cmd := chaincmd.New(
+		"simd",
+		chaincmd.WithHome("./.simapp"),
+		chaincmd.WithChainID("demo-1"),
+	)
+
+	initStep := step.New(cmd.InitCommand("validator"))
+	fmt.Println(initStep.Exec.Command)
+	fmt.Println(initStep.Exec.Args)
+}
+```

docs/docs/07-packages/chaincmdrunner.md

@@ -0,0 +1,40 @@
+---
+sidebar_position: 4
+title: Chain Command Runner (chaincmd/runner)
+slug: /packages/chaincmdrunner
+---
+
+# Chain Command Runner (chaincmd/runner)
+
+The `chaincmdrunner` package wraps chain binary commands into typed, higher-level operations (accounts, genesis setup, tx queries, node control).
+
+For full API details, see the
+[`chaincmdrunner` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/chaincmd/runner).
+
+## When to use
+
+- Execute chain lifecycle commands without manually assembling CLI arguments.
+- Manage accounts and genesis setup from automation/test flows.
+- Query transaction events using typed selectors instead of raw command output parsing.
+
+## Key APIs
+
+- `New(ctx context.Context, chainCmd chaincmd.ChainCmd, options ...Option) (Runner, error)`
+- `(Runner) Init(ctx context.Context, moniker string, args ...string) error`
+- `(Runner) Start(ctx context.Context, args ...string) error`
+- `(Runner) AddAccount(ctx context.Context, name, mnemonic, coinType, accountNumber, addressIndex string) (Account, error)`
+- `(Runner) AddGenesisAccount(ctx context.Context, address, coins string) error`
+- `(Runner) QueryTxByEvents(ctx context.Context, selectors ...EventSelector) ([]Event, error)`
+- `(Runner) WaitTx(ctx context.Context, txHash string, retryDelay time.Duration, maxRetry int) error`
+
+## Common Tasks
+
+- Build a `Runner` from a configured `chaincmd.ChainCmd` and then call `Init`/`Start` for local node workflows.
+- Use `AddAccount`, `ListAccounts`, and `ShowAccount` to manage keyring state in scripted flows.
+- Query and filter tx events with `NewEventSelector` plus `QueryTxByEvents`.
+
+## Basic import
+
+```go
+import chaincmdrunner "github.com/ignite/cli/v29/ignite/pkg/chaincmd/runner"
+```

docs/docs/07-packages/chainregistry.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 3
+title: Chain Registry Types (chainregistry)
+slug: /packages/chainregistry
+---
+
+# Chain Registry Types (chainregistry)
+
+The `chainregistry` package defines strongly-typed Go structs for Cosmos chain-registry data (`chain.json` and `assetlist.json`).
+
+For full API details, see the
+[`chainregistry` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/chainregistry).
+
+## When to use
+
+- Parse chain-registry JSON into typed values.
+- Build tooling that reads chain metadata (APIs, fees, staking tokens, assets).
+- Validate or transform registry documents before writing them back.
+
+## Key APIs
+
+- `type Chain struct{ ... }`
+- `type APIs struct{ ... }`
+- `type APIProvider struct{ ... }`
+- `type AssetList struct{ ... }`
+- `type Asset struct{ ... }`
+- `type Fees struct{ ... }`
+- `type Staking struct{ ... }`
+- `type Codebase struct{ ... }`
+- `type ChainStatus string`
+- `type ChainType string`
+
+## Common Tasks
+
+- Decode `chain.json` data into a `Chain` value and inspect RPC/REST metadata.
+- Decode `assetlist.json` into `AssetList` to access denom units and logo URIs.
+- Use enum-like types (`ChainStatus`, `NetworkType`, `ChainType`) to keep metadata checks explicit.
+
+## Basic import
+
+```go
+import "github.com/ignite/cli/v29/ignite/pkg/chainregistry"
+```

docs/docs/07-packages/cosmosaccount.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 2
+title: Account Registry (cosmosaccount)
+slug: /packages/cosmosaccount
+---
+
+# Account Registry (cosmosaccount)
+
+The `cosmosaccount` package manages Cosmos keyring accounts (create/import/export/list/delete) with configurable backend and Bech32 settings.
+
+For full API details, see the
+[`cosmosaccount` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/cosmosaccount).
+
+## When to use
+
+- Manage CLI account keys in Ignite services and commands.
+- Switch between `test`, `os`, and `memory` keyring backends.
+- Resolve addresses/public keys from named keyring entries.
+
+## Key APIs
+
+- `New(options ...Option) (Registry, error)`
+- `NewInMemory(options ...Option) (Registry, error)`
+- `WithKeyringBackend(backend KeyringBackend) Option`
+- `WithHome(path string) Option`
+- `(Registry) Create(name string) (Account, mnemonic string, err error)`
+- `(Registry) Import(name, secret, passphrase string) (Account, error)`
+- `(Registry) Export(name, passphrase string) (key string, err error)`
+- `(Registry) GetByName(name string) (Account, error)`
+- `(Registry) List() ([]Account, error)`
+- `(Account) Address(accPrefix string) (string, error)`
+
+## Common Tasks
+
+- Instantiate one `Registry` with backend/home options and reuse it for all key operations.
+- Call `EnsureDefaultAccount` in setup paths that require a predictable signer account.
+- Resolve addresses with `Account.Address(prefix)` when your app uses non-default Bech32 prefixes.
+
+## Basic import
+
+```go
+import "github.com/ignite/cli/v29/ignite/pkg/cosmosaccount"
+```

docs/docs/07-packages/cosmosanalysis.md

@@ -0,0 +1,40 @@
+---
+sidebar_position: 13
+title: Cosmos Source Analysis (cosmosanalysis)
+slug: /packages/cosmosanalysis
+---
+
+# Cosmos Source Analysis (cosmosanalysis)
+
+The `cosmosanalysis` package provides static analysis helpers for Cosmos SDK-based projects, especially for app structure and interface/embed discovery.
+
+For full API details, see the
+[`cosmosanalysis` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/cosmosanalysis).
+
+## When to use
+
+- Validate that a directory is a Cosmos chain project before running codegen.
+- Locate key app files and embedded types in Cosmos app sources.
+- Detect interface implementations across module files.
+
+## Key APIs
+
+- `IsChainPath(path string) error`
+- `FindAppFilePath(chainRoot string) (path string, err error)`
+- `ValidateGoMod(module *modfile.File) error`
+- `FindImplementation(modulePath string, interfaceList []string) (found []string, err error)`
+- `DeepFindImplementation(modulePath string, interfaceList []string) (found []string, err error)`
+- `FindEmbed(modulePath string, targetEmbeddedTypes []string) (found []string, err error)`
+- `FindEmbedInFile(n ast.Node, targetEmbeddedTypes []string) (found []string)`
+
+## Common Tasks
+
+- Call `IsChainPath` early to fail fast on unsupported project layouts.
+- Use `FindAppFilePath` before AST transformations that require the chain app entrypoint.
+- Use `FindImplementation`/`DeepFindImplementation` to verify generated modules are wired as expected.
+
+## Basic import
+
+```go
+import "github.com/ignite/cli/v29/ignite/pkg/cosmosanalysis"
+```

docs/docs/07-packages/cosmosbuf.md

@@ -0,0 +1,58 @@
+---
+sidebar_position: 14
+title: Buf Integration (cosmosbuf)
+slug: /packages/cosmosbuf
+---
+
+# Buf Integration (cosmosbuf)
+
+The `cosmosbuf` package wraps Buf workflows (`generate`, `export`, `format`, `migrate`, `dep update`) used by Ignite's protobuf pipelines.
+
+For full API details, see the
+[`cosmosbuf` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/cosmosbuf).
+
+## When to use
+
+- Trigger Buf code generation from Go services.
+- Keep Buf invocation flags and error handling consistent.
+- Reuse cache-aware generation behavior.
+
+## Key APIs
+
+- `New(cacheStorage cache.Storage, goModPath string) (Buf, error)`
+- `(Buf) Generate(ctx, protoPath, output, template, options...)`
+- `(Buf) Format(ctx, path)`
+- `(Buf) Export(ctx, protoDir, output)`
+- `Version(ctx context.Context) (string, error)`
+
+## Example
+
+```go
+package main
+
+import (
+	"context"
+	"log"
+	"os"
+	"path/filepath"
+
+	"github.com/ignite/cli/v29/ignite/pkg/cache"
+	"github.com/ignite/cli/v29/ignite/pkg/cosmosbuf"
+)
+
+func main() {
+	storage, err := cache.NewStorage(filepath.Join(os.TempDir(), "ignite-cache.db"))
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	buf, err := cosmosbuf.New(storage, "github.com/acme/my-chain")
+	if err != nil {
+		log.Fatal(err)
+	}
+
+	if err := buf.Format(context.Background(), "./proto"); err != nil {
+		log.Fatal(err)
+	}
+}
+```

docs/docs/07-packages/cosmosclient.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 1
+title: Blockchain Client (cosmosclient)
+slug: /packages/cosmosclient
+---
+
+# Blockchain Client (cosmosclient)
+
+The `cosmosclient` package provides a high-level client for querying Cosmos SDK chains and building/signing/broadcasting transactions.
+
+For full API details, see the
+[`cosmosclient` Go package documentation](https://pkg.go.dev/github.com/ignite/cli/v29/ignite/pkg/cosmosclient).
+
+## When to use
+
+- Connect Ignite tooling to a running node for status and block queries.
+- Build and broadcast SDK messages with shared gas/fees/keyring settings.
+- Wait for transaction inclusion and inspect block transactions/events.
+
+## Key APIs
+
+- `New(ctx context.Context, options ...Option) (Client, error)`
+- `WithNodeAddress(addr string) Option`
+- `WithHome(path string) Option`
+- `WithKeyringBackend(backend cosmosaccount.KeyringBackend) Option`
+- `WithGas(gas string) Option`
+- `WithGasPrices(gasPrices string) Option`
+- `(Client) BroadcastTx(ctx, account, msgs...) (Response, error)`
+- `(Client) WaitForTx(ctx context.Context, hash string) (*ctypes.ResultTx, error)`
+- `(Client) Status(ctx context.Context) (*ctypes.ResultStatus, error)`
+- `(Client) LatestBlockHeight(ctx context.Context) (int64, error)`
+
+## Common Tasks
+
+- Initialize one `Client` instance with node and keyring options, then reuse it across operations.
+- Call `CreateTxWithOptions` or `BroadcastTx` depending on whether you need fine-grained tx overrides.
+- Use `WaitForTx`, `WaitForNextBlock`, or `WaitForBlockHeight` for deterministic flows in tests/automation.
+
+## Basic import
+
+```go
+import "github.com/ignite/cli/v29/ignite/pkg/cosmosclient"
+```