feat: release cherry pick simulated messages

.github/CODEOWNERS

@@ -2,13 +2,14 @@
 
 # NOTE: Order is important; the last matching pattern takes the most precedence
 
-# Primary repo maintainers
+# Cosmos SDK Codeowners
 
-*       @cosmos/sdk-core-dev
+# Core team as default owners
 
-# CODEOWNERS for docs configuration
+* @cosmos/sdk-core-dev
 
-/docs/docusaurus.config.js @julienrbrt @tac0turtle
-/docs/sidebars.js @julienrbrt @tac0turtle
-/docs/pre.sh @julienrbrt @tac0turtle
-/docs/post.sh @julienrbrt @tac0turtle
+# Components
+
+# docs configuration
+
+/docs/ @cosmos/sdk-core-dev

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -0,0 +1,49 @@
+name: 🐛 Bug report
+description: Create a report to help us squash bugs!
+title: "[Bug]: "
+labels: ["T:Bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+        Before smashing the submit button please review the template.
+
+  - type: checkboxes
+    attributes:
+      label: Is there an existing issue for this?
+      description: Please search existing issues to avoid creating duplicates.
+      options:
+        - label: I have searched the existing issues
+          required: true
+
+  - type: markdown
+    attributes:
+      value: |
+        IMPORTANT: Prior to opening a bug report, check if it affects one of the core modules
+        and if its eligible for a bug bounty on `SECURITY.md`. Bugs that are not submitted
+        through the appropriate channels won't receive any bounty.
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+      value: "A bug happened!"
+    validations:
+      required: true
+  - type: input
+    attributes:
+      label: Cosmos SDK Version
+      description: If applicable, specify the version you're using
+      placeholder: 0.46, 0.47, main, etc.
+    validations:
+      required: true
+  - type: textarea
+    id: reproduce
+    attributes:
+      label: How to reproduce?
+      description: If applicable could you describe how we could reproduce the bug
+      placeholder: Tell us what how to reproduce the bug!
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/documentation.yml

@@ -0,0 +1,18 @@
+name: Documentation Request
+description: Create an issue for missing or incorrect documentation
+title: "[Documentation]: "
+labels: ["T:Docs"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ✰  Thanks for opening an issue! ✰    
+        Tell us where what you would like to see get added to the documentation or if there is an error in the documentation?
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: Summary
+      placeholder: Description of what you would like to see
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/epics.yml

@@ -0,0 +1,43 @@
+
+name: Epic
+description: Create an epic/user
+title: "[Epic]: "
+labels: ["T:Epic"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for opening this issue, this template is meant for long lived work scopes, if this is what you're looking for please continue
+
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: |
+        What are the user needs?
+        How could this solution fix the user facing problem? 
+      placeholder: Short, concise description of the proposed feature/changes to the repository
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Definition
+      description: |
+        Why do we need this feature? 
+        What problems may be addressed by introducing this feature?
+        What benefits does the SDK stand to gain by including this feature?
+        Are there any disadvantages of including this feature?
+      placeholder: Description of the issue being faced
+    validations:
+      required: true
+  - type: textarea
+    id: work
+    attributes:
+      label: Work Breakdown
+      description: |
+        Break the work into many bullet points that will later be turned into issues that can be assigned to developers to work on 
+        This work may been to be broken up into phases of work in order to better organize when and how things get done.
+      placeholder: Description of the steps needed to deliver this feature
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -0,0 +1,41 @@
+name: Feature Request
+description: Create a proposal to request a feature
+title: "[Feature]: "
+labels: ["T:feature-request"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+       ✰  Thanks for opening an issue! ✰  
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: |
+        What are the user needs?
+        How could this solution fix the user facing problem? 
+      placeholder: Short, concise description of the proposed feature/changes to the repository
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Definition
+      description: |
+        If applicable please answer the below questions
+        Why do we need this feature? 
+        What problems may be addressed by introducing this feature?
+        What benefits does the SDK stand to gain by including this feature?
+        Are there any disadvantages of including this feature?
+      placeholder: Description of the issue being faced
+    validations:
+      required: false
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed Feature
+      description: |
+        Description of the proposed features or changes to an existing feature to meet your needs
+      placeholder: Description of the proposed feature(s)
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/module-readiness-checklist.md

@@ -16,7 +16,7 @@ The module **should not** be included in any Release Candidate tag until it has
 
 - [ ] API audit (at least 1 person) (@assignee)
   - [ ] Are Msg and Query methods and types well-named and organized?
-  - [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/SPEC-SPEC.md) in module directory)
+  - [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/README.md) in module directory)
 - [ ] State machine audit (at least 2 people) (@assignee1, @assignee2)
   - [ ] Read through MsgServer code and verify correctness upon visual inspection
   - [ ] Ensure all state machine code which could be confusing is properly commented

.github/ISSUE_TEMPLATE/qa.md

@@ -0,0 +1,87 @@
+<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ 
+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 
+☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
+
+## Summary
+
+<!-- In a few short sentences summarize the release -->
+
+## Major Changes
+
+<!-- Describe the major changes associated to this release -->
+
+## Gotchas
+
+<!-- Gotchas is an area which changes could of been made that the auditors should be aware of -->
+
+## QA Breakdown
+
+* Audit
+    * [ ] Audit BaseApp
+    * [ ] Audit Types
+    * [ ] Audit x/auth 
+    * [ ] Audit x/authz
+    * [ ] Audit x/bank
+    * [ ] Audit x/circuit
+    * [ ] Audit x/consensus 
+    * [ ] Audit x/distribution 
+    * [ ] Audit x/evidence 
+    * [ ] Audit x/epochs
+    * [ ] Audit x/feegrant
+    * [ ] Audit x/genutil 
+    * [ ] Audit x/gov 
+    * [ ] Audit x/group 
+    * [ ] Audit x/mint 
+    * [ ] Audit x/nft 
+    * [ ] Audit x/protocolpool
+    * [ ] Audit x/slashing 
+    * [ ] Audit x/staking
+    * [ ] Audit x/tx 
+    * [ ] Audit x/upgrade 
+    * [ ] Audit client
+    * [ ] Audit server
+    * [ ] Audit store 
+    * [ ] Audit runtime
+    * [ ] Audit simapp
+* [ ] Release alpha
+* [ ] Cosmos-SDK testnet
+* [ ] Public testnet (IBC, WASM, SDK)
+* [ ] Upgrade a chain with data from vX
+* Release documentation
+    * [ ] Audit UPGRADING.md
+    * [ ] Update all codeblock to the appropriate version number
+
+
+### Audit checklist
+
+* please copy to a markdown to follow while you walk through the code
+* 2 people should be assigned to each section 
+
+* [ ] API audit 
+    * spec audit: check if the spec is complete.
+    * Are Msg and Query methods and types well-named and organized?
+    * Is everything well documented (inline godoc as well as package [`README.md`](https://docs.cosmos.network/main/spec/SPEC_MODULE#common-layout) in module directory)
+    * check the proto definition - make sure everything is in accordance to ADR-30 (at least 1 person, TODO assignee)
+        * Check new fields and endpoints have the `Since: cosmos-sdk X` comment
+* [ ] Completeness audit, fully implemented with tests
+    * [ ] Genesis import and export of all state
+    * [ ] Query services
+    * [ ] CLI methods
+    * [ ] All necessary migration scripts are present (if this is an upgrade of existing module)
+* [ ] State machine audit
+    * [ ] Read through MsgServer code and verify correctness upon visual inspection
+    * [ ] Ensure all state machine code which could be confusing is properly commented
+    * [ ] Make sure state machine logic matches Msg method documentation
+    * [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
+    * [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to: 
+        * [ ] algorithmic complexity and places this could be exploited (ex. nested `for` loops)
+        * [ ] charging gas complex computation (ex. `for` loops)
+        * [ ] storage is safe (we don't pollute the state).
+    * [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
+    * [ ] Check correctness of simulation implementation if any
+* [ ] Audit Changelog against commit log, ensuring all breaking changes, bug fixes, and improvements are properly documented.
+
+If any changes are needed, please make them against main and backport them to release/vX.X.x

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,4 @@
-<!--
-The default pull request template is for types feat, fix, or refactor.
-For other templates, add one of the following parameters to the url:
-- template=docs.md
-- template=other.md
--->
-
-## Description
+# Description
 
 Closes: #XXXX
 
@@ -14,37 +7,43 @@ are the most critical to review. -->
 
 ---
 
-### Author Checklist
+## Author Checklist
 
 *All items are required. Please add a note to the item if the item is not applicable and
 please add links to any relevant follow up issues.*
 
 I have...
 
-* [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
-* [ ] added `!` to the type prefix if API or client breaking change
+* [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title, you can find examples of the prefixes below:
+    <!-- * `feat`: A new feature
+    * `fix`: A bug fix
+    * `docs`: Documentation only changes
+    * `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+    * `refactor`: A code change that neither fixes a bug nor adds a feature
+    * `perf`: A code change that improves performance
+    * `test`: Adding missing tests or correcting existing tests
+    * `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+    * `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+    * `chore`: Other changes that don't modify src or test files
+    * `revert`: Reverts a previous commit -->
+* [ ] confirmed `!` in the type prefix if API or client breaking change
 * [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting))
 * [ ] provided a link to the relevant issue or specification
-* [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules)
+* [ ] reviewed "Files changed" and left comments if necessary
 * [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing)
 * [ ] added a changelog entry to `CHANGELOG.md`
-* [ ] included comments for [documenting Go code](https://blog.golang.org/godoc)
-* [ ] updated the relevant documentation or specification
-* [ ] reviewed "Files changed" and left comments if necessary
+* [ ] updated the relevant documentation or specification, including comments for [documenting Go code](https://blog.golang.org/godoc)
 * [ ] confirmed all CI checks have passed
 
-### Reviewers Checklist
+## Reviewers Checklist
 
 *All items are required. Please add a note if the item is not applicable and please add
 your handle next to the items reviewed if you only reviewed selected items.*
 
+Please see [Pull Request Reviewer section in the contributing guide](../CONTRIBUTING.md#reviewer) for more information on how to review a pull request.
+
 I have...
 
 * [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
-* [ ] confirmed `!` in the type prefix if API or client breaking change
-* [ ] confirmed all author checklist items have been addressed 
-* [ ] reviewed state machine logic
-* [ ] reviewed API design and naming
-* [ ] reviewed documentation is accurate
-* [ ] reviewed tests and test coverage
-* [ ] manually tested (if applicable)
+* [ ] confirmed all author checklist items have been addressed
+* [ ] reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

.github/codeql/config.yml

@@ -0,0 +1,11 @@
+packs:
+  - crypto-com/cosmos-sdk-codeql
+queries:
+  - uses: security-and-quality
+  - uses: security-experimental
+  - uses: security-extended
+paths-ignore:
+  - api
+  - '**/*_test.go'
+  - '**/*.pulsar.go'
+  - '**/*.pb.gp'