.md - replace references to TM (celestiaorg#148)

* Replace references to tm

* Fix bft name

* Applied PR comments

* replace tag

* Apply suggestions from code review

Co-authored-by: Daniel <[email protected]>

* Removed Core after cometbft

* removed amino mentioning from doc

* Apply suggestions from code review

Co-authored-by: Thane Thomson <[email protected]>
Co-authored-by: Daniel <[email protected]>

* Updated files based on PR review

Co-authored-by: Daniel <[email protected]>
Co-authored-by: Thane Thomson <[email protected]>

Author: 3 people

CODE_OF_CONDUCT.md

@@ -1,13 +1,13 @@
-# The Tendermint Code of Conduct
+# The CometBFT Code of Conduct
 
-This code of conduct applies to all projects run by the Tendermint/COSMOS team
-and hence to Tendermint.
+This code of conduct applies to all projects run by the CometBFT/COSMOS team
+and hence to CometBFT.
 
 ----
 
 # Conduct
 
-## Contact: conduct@tendermint.com
+## Contact: conduct@cometbft.com
 
 * We are committed to providing a friendly, safe and welcoming environment for
   all, regardless of level of experience, gender, gender identity and
@@ -50,7 +50,7 @@ These are the policies for upholding our community’s standards of conduct. If
 you feel that a thread needs moderation, please contact the above mentioned
 person.
 
-1. Remarks that violate the Tendermint/COSMOS standards of conduct, including
+1. Remarks that violate the CometBFT/COSMOS standards of conduct, including
    hateful, hurtful, oppressive, or exclusionary remarks, are not allowed.
    (Cursing is allowed, but never targeting another user, and never in a hateful
    manner.)
@@ -77,7 +77,7 @@ person.
    moderator creates an inappropriate situation, they should expect less leeway
    than others.
 
-In the Tendermint/COSMOS community we strive to go the extra step to look out
+In the CometBFT/COSMOS community we strive to go the extra step to look out
 for each other. Don’t just aim to be technically unimpeachable, try to be your
 best self. In particular, avoid flirting with offensive or sensitive issues,
 particularly if they’re off-topic; this all too often leads to unnecessary
@@ -93,8 +93,8 @@ get along and we are all here first and foremost because we want to talk
 about cool technology. You will find that people will be eager to assume
 good intent and forgive as long as you earn their trust.
 
-The enforcement policies listed above apply to all official Tendermint/COSMOS
-venues. For other projects adopting the Tendermint/COSMOS Code of Conduct,
+The enforcement policies listed above apply to all official CometBFT/COSMOS
+venues. For other projects adopting the CometBFT/COSMOS Code of Conduct,
 please contact the maintainers of those projects for enforcement. If you wish to
 use this code of conduct for your own project, consider explicitly mentioning
 your moderation policy or making a copy with your own moderation policy so as to

CONTRIBUTING.md

@@ -1,23 +1,23 @@
 # Contributing
 
-Thank you for your interest in contributing to Tendermint! Before
+Thank you for your interest in contributing to CometBFT! Before
 contributing, it may be helpful to understand the goal of the project. The goal
-of Tendermint is to develop a BFT consensus engine robust enough to
+of CometBFT is to develop a BFT consensus engine robust enough to
 support permissionless value-carrying networks. While all contributions are
 welcome, contributors should bear this goal in mind in deciding if they should
-target the main Tendermint project or a potential fork. When targeting the
-main Tendermint project, the following process leads to the best chance of
+target the main CometBFT project or a potential fork. When targeting the
+main CometBFT project, the following process leads to the best chance of
 landing changes in `main`.
 
 All work on the code base should be motivated by a [Github
-Issue](https://github.com/tendermint/tendermint/issues).
-[Search](https://github.com/tendermint/tendermint/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
+Issue](https://github.com/cometbft/cometbft/issues).
+[Search](https://github.com/cometbft/cometbft/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
 is a good place to start when looking for places to contribute. If you
 would like to work on an issue which already exists, please indicate so
 by leaving a comment.
 
 All new contributions should start with a [Github
-Issue](https://github.com/tendermint/tendermint/issues/new/choose). The
+Issue](https://github.com/cometbft/cometbft/issues/new/choose). The
 issue helps capture the problem you're trying to solve and allows for
 early feedback. Once the issue is created the process can proceed in different
 directions depending on how well defined the problem and potential
@@ -26,8 +26,8 @@ will indicate their support with a heartfelt emoji.
 
 If the issue would benefit from thorough discussion, maintainers may
 request that you create a [Request For
-Comment](https://github.com/tendermint/tendermint/tree/main/docs/rfc)
-in the Tendermint spec repo. Discussion
+Comment](https://github.com/cometbft/cometbft/tree/main/docs/rfc)
+in the CometBFT spec repo. Discussion
 at the RFC stage will build collective understanding of the dimensions
 of the problems and help structure conversations around trade-offs.
 
@@ -57,23 +57,24 @@ Each stage of the process is aimed at creating feedback cycles which align contr
 - Contributors don’t waste their time implementing/proposing features which won’t land in `main`.
 - Maintainers have the necessary context in order to support and review contributions.
 
+
 ## Forking
 
 Please note that Go requires code to live under absolute paths, which complicates forking.
-While my fork lives at `https://github.com/ebuchman/tendermint`,
-the code should never exist at `$GOPATH/src/github.com/ebuchman/tendermint`.
+While my fork lives at `https://github.com/ebuchman/cometbft`,
+the code should never exist at `$GOPATH/src/github.com/ebuchman/cometbft`.
 Instead, we use `git remote` to add the fork as a new remote for the original repo,
-`$GOPATH/src/github.com/tendermint/tendermint`, and do all the work there.
+`$GOPATH/src/github.com/cometbft/cometbft`, and do all the work there.
 
 For instance, to create a fork and work on a branch of it, I would:
 
 - Create the fork on GitHub, using the fork button.
-- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/tendermint/tendermint`)
+- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/cometbft/cometbft`)
 - `git remote rename origin upstream`
 - `git remote add origin git@github.com:ebuchman/basecoin.git`
 
-Now `origin` refers to my fork and `upstream` refers to the Tendermint version.
-So I can `git push -u origin main` to update my fork, and make pull requests to tendermint from there.
+Now `origin` refers to my fork and `upstream` refers to the CometBFT version.
+So I can `git push -u origin main` to update my fork, and make pull requests to CometBFT from there.
 Of course, replace `ebuchman` with your git handle.
 
 To pull in updates from the origin repo, run
@@ -85,7 +86,7 @@ To pull in updates from the origin repo, run
 
 We use [go modules](https://github.com/golang/go/wiki/Modules) to manage dependencies.
 
-That said, the `main` branch of every Tendermint repository should just build
+That said, the `main` branch of every CometBFT repository should just build
 with `go get`, which means they should be kept up-to-date with their
 dependencies so we can get away with telling people they can just `go get` our
 software.
@@ -100,28 +101,27 @@ up-to-date.
 
 When updating dependencies, please only update the particular dependencies you
 need. Instead of running `go get -u=patch`, which will update anything,
-specify exactly the dependency you want to update, eg.
-`GO111MODULE=on go get -u github.com/tendermint/go-amino@master`.
+specify exactly the dependency you want to update.
 
 ## Protobuf
 
 We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along
 with [`gogoproto`](https://github.com/cosmos/gogoproto) to generate code for use
-across Tendermint Core.
+across CometBFT.
 
 To generate proto stubs, lint, and check protos for breaking changes, you will
 need to install [buf](https://buf.build/) and `gogoproto`. Then, from the root
 of the repository, run:
 
 ```bash
-# Lint all of the .proto files in proto/tendermint
+# Lint all of the .proto files
 make proto-lint
 
 # Check if any of your local changes (prior to committing to the Git repository)
 # are breaking
 make proto-check-breaking
 
-# Generate Go code from the .proto files in proto/tendermint
+# Generate Go code from the .proto files
 make proto-gen
 ```
 
@@ -149,8 +149,15 @@ If you are a VS Code user, you may want to add the following to your `.vscode/se
 
 ## Changelog
 
+To manage and generate our changelog, we currently use [unclog](https://github.com/informalsystems/unclog).
+
 Every fix, improvement, feature, or breaking change should be made in a
-pull-request that includes an update to the `CHANGELOG_PENDING.md` file.
+pull-request that includes a file `.changelog/unreleased/${category}/${issue-or-pr-number}-${description}.md`, where:
+- `category` is one of `improvements`, `breaking-changes`, `bug-fixes`, `features` and if multiple apply, create multiple files;
+- `description` is a short (4 to 6 word), hiphen separated description of the fix, starting the component changed; and, 
+- `issue or PR number' is the CometBFT issue number, if one exists, or the PR number, otherwise.
+
+For examples, see the [.changelog](.changelog) folder.
 
 A feature can also be worked on a feature branch, if its size and/or risk
 justifies it (see #branching-model-and-release) below.
@@ -168,7 +175,7 @@ Some good examples of changelog entry descriptions:
 - [consensus] \#1111 Small transaction throughput improvement (approximately
   3-5\% from preliminary tests) through refactoring the way we use channels
 - [mempool] \#1112 Refactor Go API to be able to easily swap out the current
-  mempool implementation in Tendermint forks
+  mempool implementation in CometBFT forks
 - [p2p] \#1113 Automatically ban peers when their messages are unsolicited or
   are received too frequently
 ```
@@ -242,13 +249,13 @@ easy to reference the pull request where a change was introduced.
 
 The latest state of development is on `main`, which must never fail `make test`. _Never_ force push `main`, unless fixing broken git history (which we rarely do anyways).
 
-To begin contributing, create a development branch either on `github.com/tendermint/tendermint`, or your fork (using `git remote add origin`).
+To begin contributing, create a development branch either on `github.com/cometbft/cometbft`, or your fork (using `git remote add origin`).
 
-Make changes, and before submitting a pull request, update the `CHANGELOG_PENDING.md` to record your change. Also, run either `git rebase` or `git merge` on top of the latest `main`. (Since pull requests are squash-merged, either is fine!)
+Make changes, and before submitting a pull request, update the changelog to record your change. Also, run either `git rebase` or `git merge` on top of the latest `main`. (Since pull requests are squash-merged, either is fine!)
 
 Update the `UPGRADING.md` if the change you've made is breaking and the
 instructions should be in place for a user on how he/she can upgrade its
-software (ABCI application, Tendermint-based blockchain, light client, wallet).
+software (ABCI application, CometBFT blockchain, light client, wallet).
 
 Once you have submitted a pull request label the pull request with either `R:minor`, if the change should be included in the next minor release, or `R:major`, if the change is meant for a major release.
 
@@ -282,7 +289,8 @@ After this, you can open a PR. Please note in the PR body if there were merge co
 
 ### Git Commit Style
 
-We follow the [Go style guide on commit messages](https://tip.golang.org/doc/contribute.html#commit_messages). Write concise commits that start with the package name and have a description that finishes the sentence "This change modifies Tendermint to...". For example,
+We follow the [Go style guide on commit messages](https://tip.golang.org/doc/contribute.html#commit_messages). Write concise commits that start with the package
+ name and have a description that finishes the sentence "This change modifies CometBFT to...". For example,
 
 ```sh
 cmd/debug: execute p.Signal only when p is not nil
@@ -314,7 +322,7 @@ Run: `make test_integrations`
 
 ### End-to-end tests
 
-End-to-end tests are used to verify a fully integrated Tendermint network.
+End-to-end tests are used to verify a fully integrated CometBFT network.
 
 See [README](./test/e2e/README.md) for details.
 
@@ -356,18 +364,6 @@ most probably (99.9%)*.
 `./test/fuzz` directory. See [README.md](./test/fuzz/README.md) for details.
 
 Run: `cd test/fuzz && make fuzz-{PACKAGE-COMPONENT}`
-
-### Jepsen tests (ADVANCED)
-
-*NOTE: if you're just submitting your first PR, you won't need to touch these
-most probably (99.9%)*.
-
-[Jepsen](http://jepsen.io/) tests are used to verify the
-[linearizability](https://jepsen.io/consistency/models/linearizable) property
-of the Tendermint consensus. They are located in a separate repository
--> <https://github.com/tendermint/jepsen>. Please refer to its README for more
-information.
-
 ### RPC Testing
 
 **If you contribute to the RPC endpoints it's important to document your

PHILOSOPHY.md

@@ -1,7 +1,7 @@
 # Releases
 
-Tendermint uses modified [semantic versioning](https://semver.org/) with each
-release following a `vX.Y.Z` format. Tendermint is currently on major version 0
+CometBFT uses modified [semantic versioning](https://semver.org/) with each
+release following a `vX.Y.Z` format. CometBFT is currently on major version 0
 and uses the minor version to signal breaking changes. The `main` branch is
 used for active development and thus it is not advisable to build against it.
 
@@ -10,7 +10,7 @@ specified using tags and are built from long-lived "backport" branches that are
 cut from `main` when the release process begins. Each release "line" (e.g.
 0.34 or 0.33) has its own long-lived backport branch, and the backport branches
 have names like `v0.34.x` or `v0.33.x` (literally, `x`; it is not a placeholder
-in this case). Tendermint only maintains the last two releases at a time (the
+in this case). CometBFT only maintains the last two releases at a time (the
 oldest release is predominantly just security patches).
 
 ## Backporting
@@ -36,8 +36,8 @@ v0.25.0, you get to have the honor of creating the backport branch!
 Note that, after creating the backport branch, you'll also need to update the
 tags on `main` so that `go mod` is able to order the branches correctly. You
 should tag `main` with a "dev" tag that is "greater than" the backport
-branches tags. See [#6072](https://github.com/tendermint/tendermint/pull/6072)
-for more context.
+branches tags. Otherwise, `go mod` does not 'know' whether commits on `main`
+come before or after the release.
 
 In the following example, we'll assume that we're making a backport branch for
 the 0.38.x line.
@@ -70,16 +70,16 @@ the 0.38.x line.
    The following links are to always point to `main`, regardless of where they
    occur in the codebase:
 
-   * `https://github.com/tendermint/tendermint/blob/main/LICENSE`
+   * `https://github.com/cometbft/cometbft/blob/main/LICENSE`
 
    Be sure to search for all of the following links and replace `main` with your
    corresponding branch label or version (e.g. `v0.38.x` or `v0.38`):
 
-   * `github.com/tendermint/tendermint/blob/main` ->
-     `github.com/tendermint/tendermint/blob/v0.38.x`
-   * `github.com/tendermint/tendermint/tree/main` ->
-     `github.com/tendermint/tendermint/tree/v0.38.x`
-   * `docs.tendermint.com/main` -> `docs.tendermint.com/v0.38`
+   * `github.com/cometbft/cometbft/blob/main` ->
+     `github.com/cometbft/cometbft/blob/v0.38.x`
+   * `github.com/cometbft/cometbft/tree/main` ->
+     `github.com/cometbft/cometbft/tree/v0.38.x`
+   * `docs.cometbft.com/main` -> `docs.cometbft.com/v0.38`
 
    Once you have updated all of the relevant documentation:
 
@@ -99,14 +99,14 @@ After doing these steps, go back to `main` and do the following:
    [e2e-nightly-main.yml][e2e] for an example.)
 
 2. Add a new section to the Mergify config (`.github/mergify.yml`) to enable the
-   backport bot to work on this branch, and add a corresponding `S:backport-to-v0.38.x`
-   [label](https://github.com/tendermint/tendermint/labels) so the bot can be triggered.
+   backport bot to work on this branch, and add a corresponding `backport-to-v0.38.x`
+   [label](https://github.com/cometbft/cometbft/labels) so the bot can be triggered.
 
 3. Add a new section to the Dependabot config (`.github/dependabot.yml`) to
    enable automatic update of Go dependencies on this branch. Copy and edit one
    of the existing branch configurations to set the correct `target-branch`.
 
-[e2e]: https://github.com/tendermint/tendermint/blob/main/.github/workflows/e2e-nightly-main.yml
+[e2e]: https://github.com/cometbft/cometbft/blob/main/.github/workflows/e2e-nightly-main.yml
 
 ## Pre-releases
 
@@ -148,7 +148,7 @@ backport branch (see above). Otherwise:
 1. Start from the backport branch (e.g. `v0.38.x`).
 2. Run the integration tests and the E2E nightlies
    (which can be triggered from the GitHub UI;
-   e.g., <https://github.com/tendermint/tendermint/actions/workflows/e2e-nightly-37x.yml>).
+   e.g., <https://github.com/cometbft/cometbft/actions/workflows/e2e-nightly-37x.yml>).
 3. Prepare the pre-release documentation:
    * Ensure that all relevant changes are in the `CHANGELOG_PENDING.md` file.
      This file's contents must only be included in the `CHANGELOG.md` when we
@@ -243,13 +243,13 @@ To create a patch release:
 ## Minor Release Checklist
 
 The following set of steps are performed on all releases that increment the
-_minor_ version, e.g. v0.25 to v0.26. These steps ensure that Tendermint is well
+_minor_ version, e.g. v0.25 to v0.26. These steps ensure that CometBFT is well
 tested, stable, and suitable for adoption by the various diverse projects that
-rely on Tendermint.
+rely on CometBFT.
 
 ### Feature Freeze
 
-Ahead of any minor version release of Tendermint, the software enters 'Feature
+Ahead of any minor version release of CometBFT, the software enters 'Feature
 Freeze' for at least two weeks. A feature freeze means that _no_ new features
 are added to the code being prepared for release. No code changes should be made
 to the code being released that do not directly improve pressing issues of code
@@ -263,42 +263,39 @@ quality. The following must not be merged during a feature freeze:
   code.
 
 This period directly follows the creation of the [backport
-branch](#creating-a-backport-branch). The Tendermint team instead directs all
+branch](#creating-a-backport-branch). The CometBFT team instead directs all
 attention to ensuring that the existing code is stable and reliable. Broken
 tests are fixed, flakey-tests are remedied, end-to-end test failures are
 thoroughly diagnosed and all efforts of the team are aimed at improving the
 quality of the code. During this period, the upgrade harness tests are run
-repeatedly and a variety of in-house testnets are run to ensure Tendermint
+repeatedly and a variety of in-house testnets are run to ensure CometBFT
 functions at the scale it will be used by application developers and node
 operators.
 
 ### Nightly End-To-End Tests
 
-The Tendermint team maintains [a set of end-to-end
-tests](https://github.com/tendermint/tendermint/blob/main/test/e2e/README.md#L1)
+The CometBFT team maintains [a set of end-to-end
+tests](https://github.com/cometbft/cometbft/blob/main/test/e2e/README.md#L1)
 that run each night on the latest commit of the project and on the code in the
 tip of each supported backport branch. These tests start a network of
-containerized Tendermint processes and run automated checks that the network
+containerized CometBFT processes and run automated checks that the network
 functions as expected in both stable and unstable conditions. During the feature
 freeze, these tests are run nightly and must pass consistently for a release of
-Tendermint to be considered stable.
+CometBFT to be considered stable.
 
 ### Upgrade Harness
 
-> TODO(williambanfield): Change to past tense and clarify this section once
-> upgrade harness is complete.
-
-The Tendermint team is creating an upgrade test harness to exercise the workflow
-of stopping an instance of Tendermint running one version of the software and
+The CometBFT team is creating an upgrade test harness to exercise the workflow
+of stopping an instance of CometBFT running one version of the software and
 starting up the same application running the next version. To support upgrade
-testing, we will add the ability to terminate the Tendermint process at specific
+testing, we will add the ability to terminate the CometBFT process at specific
 pre-defined points in its execution so that we can verify upgrades work in a
 representative sample of stop conditions.
 
 ### Large Scale Testnets
 
-The Tendermint end-to-end tests run a small network (~10s of nodes) to exercise
-basic consensus interactions. Real world deployments of Tendermint often have
+The CometBFT end-to-end tests run a small network (~10s of nodes) to exercise
+basic consensus interactions. Real world deployments of CometBFT often have
 over a hundred nodes just in the validator set, with many others acting as full
 nodes and sentry nodes. To gain more assurance before a release, we will also
 run larger-scale test networks to shake out emergent behaviors at scale.
@@ -325,11 +322,11 @@ node:
 
 For these tests we intentionally target low-powered host machines (with low core
 counts and limited memory) to ensure we observe similar kinds of resource contention
-and limitation that real-world  deployments of Tendermint experience in production.
+and limitation that real-world  deployments of CometBFT experience in production.
 
 #### 200 Node Testnet
 
-To test the stability and performance of Tendermint in a real world scenario,
+To test the stability and performance of CometBFT in a real world scenario,
 a 200 node test network is run. The network comprises 5 seed nodes, 100
 validators and 95 non-validating full nodes. All nodes begin by dialing
 a subset of the seed nodes to discover peers. The network is run for several
@@ -338,22 +335,22 @@ critical systems, testnets of larger sizes should be considered.
 
 #### Rotating Node Testnet
 
-Real-world deployments of Tendermint frequently see new nodes arrive and old
-nodes exit the network. The rotating node testnet ensures that Tendermint is
+Real-world deployments of CometBFT frequently see new nodes arrive and old
+nodes exit the network. The rotating node testnet ensures that CometBFT is
 able to handle this reliably. In this test, a network with 10 validators and
 3 seed nodes is started. A rolling set of 25 full nodes are started and each
 connects to the network by dialing one of the seed nodes. Once the node is able
 to blocksync to the head of the chain and begins producing blocks using
-Tendermint consensus it is stopped. Once stopped, a new node is started and
+consensus it is stopped. Once stopped, a new node is started and
 takes its place. This network is run for several days.
 
 #### Network Partition Testnet
 
-Tendermint is expected to recover from network partitions. A partition where no
+CometBFT is expected to recover from network partitions. A partition where no
 subset of the nodes is left with the super-majority of the stake is expected to
 stop making blocks. Upon alleviation of the partition, the network is expected
 to once again become fully connected and capable of producing blocks. The
-network partition testnet ensures that Tendermint is able to handle this
+network partition testnet ensures that CometBFT is able to handle this
 reliably at scale. In this test, a network with 100 validators and 95 full
 nodes is started. All validators have equal stake. Once the network is
 producing blocks, a set of firewall rules is deployed to create a partitioned
@@ -364,7 +361,7 @@ producing blocks.
 
 #### Absent Stake Testnet
 
-Tendermint networks often run with _some_ portion of the voting power offline.
+CometBFT networks often run with _some_ portion of the voting power offline.
 The absent stake testnet ensures that large networks are able to handle this
 reliably. A set of 150 validator nodes and three seed nodes is started. The set
 of 150 validators is configured to only possess a cumulative stake of 67% of

RELEASES.md

@@ -1,8 +1,12 @@
 # Security
 
+**NOTE** The security process outlined in this document is outdated and is currently
+being defined (see https://github.com/cometbft/cometbft/issues/191).
+
+---------------------------
 ## Reporting a Bug
 
-As part of our [Coordinated Vulnerability Disclosure Policy](https://tendermint.com/security),
+As part of our [Coordinated Vulnerability Disclosure Policy](https://cometbft.com/security),
 we operate a [bug bounty][hackerone]. See the policy for more
 details on submissions and rewards, and see "Example Vulnerabilities" (below)
 for examples of the kinds of bugs we're most interested in.
@@ -18,7 +22,7 @@ We require that all researchers:
   disruption to production systems (including but not limited to the Cosmos
   Hub), and destruction of data
 * Keep any information about vulnerabilities that you’ve discovered confidential
-  between yourself and the Tendermint Core engineering team until the issue has
+  between yourself and the CometBFT engineering team until the issue has
   been resolved and disclosed
 * Avoid posting personally identifiable information, privately or publicly
 
@@ -31,40 +35,40 @@ If you follow these guidelines when reporting an issue to us, we commit to:
 
 ## Disclosure Process
 
-Tendermint Core uses the following disclosure process:
+CometBFT uses the following disclosure process:
 
-1. Once a security report is received, the Tendermint Core team works to verify
+1. Once a security report is received, the CometBFT team works to verify
    the issue and confirm its severity level using CVSS.
-2. The Tendermint Core team collaborates with the Gaia team to determine the
+2. The CometBFT team collaborates with the Gaia team to determine the
    vulnerability’s potential impact on the Cosmos Hub.
-3. Patches are prepared for eligible releases of Tendermint in private
+3. Patches are prepared for eligible releases of CometBFT in private
    repositories. See “Supported Releases” below for more information on which
    releases are considered eligible.
 4. If it is determined that a CVE-ID is required, we request a CVE through a CVE
    Numbering Authority.
-5. We notify the community that a security release is coming, to give users time
+<!-- 5. We notify the community that a security release is coming, to give users time
    to prepare their systems for the update. Notifications can include forum
    posts, tweets, and emails to partners and validators, including emails sent
-   to the [Tendermint Security Mailing List][tmsec-mailing].
-6. 24 hours following this notification, the fixes are applied publicly and new
+   to the [CometBFT Security Mailing List][tmsec-mailing]. -->
+1. 24 hours following this notification, the fixes are applied publicly and new
    releases are issued.
-7. Cosmos SDK and Gaia update their Tendermint Core dependencies to use these
+2. Cosmos SDK and Gaia update their CometBFT dependencies to use these
    releases, and then themselves issue new releases.
-8. Once releases are available for Tendermint Core, Cosmos SDK and Gaia, we
+3. Once releases are available for CometBFT, Cosmos SDK and Gaia, we
    notify the community, again, through the same channels as above. We also
    publish a Security Advisory on Github and publish the CVE, as long as neither
    the Security Advisory nor the CVE include any information on how to exploit
    these vulnerabilities beyond what information is already available in the
    patch itself.
-9. Once the community is notified, we will pay out any relevant bug bounties to
+4. Once the community is notified, we will pay out any relevant bug bounties to
    submitters.
-10. One week after the releases go out, we will publish a post with further
+5. One week after the releases go out, we will publish a post with further
     details on the vulnerability as well as our response to it.
 
 This process can take some time. Every effort will be made to handle the bug in
 as timely a manner as possible, however it's important that we follow the
 process described above to ensure that disclosures are handled consistently and
-to keep Tendermint Core and its downstream dependent projects--including but not
+to keep CometBFT and its downstream dependent projects--including but not
 limited to Gaia and the Cosmos Hub--as secure as possible.
 
 ### Example Timeline
@@ -78,25 +82,25 @@ multiple people can play each role and each person may play multiple roles.
 1. Request CVE number (ADMIN)
 2. Gather emails and other contact info for validators (COMMS LEAD)
 3. Create patches in a private security repo, and ensure that PRs are open
-   targeting all relevant release branches (TENDERMINT ENG, TENDERMINT LEAD)
-4. Test fixes on a testnet  (TENDERMINT ENG, COSMOS SDK ENG)
-5. Write “Security Advisory” for forum (TENDERMINT LEAD)
+   targeting all relevant release branches (CometBFT ENG, CometBFT LEAD)
+4. Test fixes on a testnet  (CometBFT ENG, COSMOS SDK ENG)
+5. Write “Security Advisory” for forum (CometBFT LEAD)
 
 #### 24 Hours Before Release Time
 
-1. Post “Security Advisory” pre-notification on forum (TENDERMINT LEAD)
+1. Post “Security Advisory” pre-notification on forum (CometBFT LEAD)
 2. Post Tweet linking to forum post (COMMS LEAD)
 3. Announce security advisory/link to post in various other social channels
    (Telegram, Discord) (COMMS LEAD)
 4. Send emails to validators or other users (PARTNERSHIPS LEAD)
 
 #### Release Time
 
-1. Cut Tendermint releases for eligible versions (TENDERMINT ENG, TENDERMINT
+1. Cut CometBFT releases for eligible versions (CometBFT ENG, CometBFT
    LEAD)
 2. Cut Cosmos SDK release for eligible versions (COSMOS ENG)
 3. Cut Gaia release for eligible versions (GAIA ENG)
-4. Post “Security releases” on forum (TENDERMINT LEAD)
+4. Post “Security releases” on forum (CometBFT LEAD)
 5. Post new Tweet linking to forum post (COMMS LEAD)
 6. Remind everyone via social channels (Telegram, Discord)  that the release is
    out (COMMS LEAD)
@@ -106,23 +110,23 @@ multiple people can play each role and each person may play multiple roles.
 
 #### After Release Time
 
-1. Write forum post with exploit details (TENDERMINT LEAD)
+1. Write forum post with exploit details (CometBFT LEAD)
 2. Approve pay-out on HackerOne for submitter (ADMIN)
 
 #### 7 Days After Release Time
 
 1. Publish CVE if it has not yet been published (ADMIN)
-2. Publish forum post with exploit details (TENDERMINT ENG, TENDERMINT LEAD)
+2. Publish forum post with exploit details (CometBFT ENG, CometBFT LEAD)
 
 ## Supported Releases
 
-The Tendermint Core team commits to releasing security patch releases for both
+The CometBFT team commits to releasing security patch releases for both
 the latest minor release as well for the major/minor release that the Cosmos Hub
 is running.
 
-If you are running older versions of Tendermint Core, we encourage you to
+If you are running older versions of CometBFT, we encourage you to
 upgrade at your earliest opportunity so that you can receive security patches
-directly from the Tendermint repo. While you are welcome to backport security
+directly from the CometBFT repo. While you are welcome to backport security
 patches to older versions for your own use, we will not publish or promote these
 backports.
 
@@ -206,4 +210,4 @@ Attacks may come through the P2P network or the RPC layer:
 * Bisection/sequential algorithms
 
 [hackerone]: https://hackerone.com/cosmos
-[tmsec-mailing]: https://berlin.us4.list-manage.com/subscribe?u=431b35421ff7edcc77df5df10&id=3fe93307bc
+<!-- [tmsec-mailing]: https://berlin.us4.list-manage.com/subscribe?u=431b35421ff7edcc77df5df10&id=3fe93307bc -->

SECURITY.md

@@ -65,7 +65,7 @@ type middleware struct {
 ```
 
 * In comments, use "iff" to mean, "if and only if".
-* Product names are capitalized, like "Tendermint", "Basecoin", "Protobuf", etc except in command lines: `tendermint --help`
+* Product names are capitalized, like "CometBFT", "Basecoin", "Protobuf", etc except in command lines: `cometbft --help`
 * Acronyms are all capitalized, like "RPC", "gRPC", "API".  "MyID", rather than "MyId".
 * Prefer errors.New() instead of fmt.Errorf() unless you're actually using the format feature with arguments.
 
@@ -77,12 +77,12 @@ Sometimes it's necessary to rename libraries to avoid naming collisions or ambig
 * Separate imports into blocks - one for the standard lib, one for external libs and one for application libs.
 * Here are some common library labels for consistency:
     * dbm "github.com/cometbft/cometbft-db"
-    * cmtcmd "github.com/tendermint/tendermint/cmd/tendermint/commands"
-    * cmtcfg "github.com/tendermint/tendermint/config/tendermint"
-    * cmttypes "github.com/tendermint/tendermint/types"
-* Never use anonymous imports (the `.`), for example, `tmlibs/common` or anything else.
-* When importing a pkg from the `tendermint/libs` directory, prefix the pkg alias with cmt.
-    * cmtbits "github.com/tendermint/tendermint/libs/bits"
+    * cmtcmd "github.com/cometbft/cometbft/cmd/cometbft/commands"
+    * cmtcfg "github.com/cometbft/cometbft/config"
+    * cmttypes "github.com/cometbft/cometbft/types"
+* Never use anonymous imports (the `.`), for example, `cmtlibs/common` or anything else.
+* When importing a pkg from the `cmt/libs` directory, prefix the pkg alias with cmt.
+    * cmtbits "github.com/cometbft/cometbft/libs/bits"
 * tip: Use the `_` library import to import a library for initialization effects (side effects)
 
 ## Dependencies
@@ -126,7 +126,7 @@ Sometimes it's necessary to rename libraries to avoid naming collisions or ambig
 
 ## Version
 
-* Every repo should have a version/version.go file that mimics the Tendermint Core repo
+* Every repo should have a version/version.go file that mimics the CometBFT repo
 * We read the value of the constant version in our build scripts and hence it has to be a string
 
 ## Non-Go Code