rootulp · Jan 23, 2023
diff --git a/‎spec/README.md
+10-10 b/‎spec/README.md
+10-10
diff --git a/‎spec/abci/README.md
+9-9 b/‎spec/abci/README.md
+9-9
@@ -6,15 +6,15 @@ parent:
   order: 7
 ---
 
-# Tendermint Spec
+# CometBFT Spec
 
-This is a markdown specification of the Tendermint blockchain.
+This is a markdown specification of CometBFT.
 It defines the base data structures, how they are validated,
 and how they are communicated over the network.
 
 If you find discrepancies between the spec and the code that
 do not have an associated issue or pull request on github,
-please submit them to our [bug bounty](https://tendermint.com/security)!
+please submit them to our [bug bounty](https://cometbft.com/security)!
 
 ## Contents
 
@@ -44,7 +44,7 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ### RPC
 
-- [RPC SPEC](./rpc/README.md): Specification of the Tendermint remote procedure call interface.
+- [RPC SPEC](./rpc/README.md): Specification of the CometBFT remote procedure call interface.
 
 ### Software
 
@@ -55,19 +55,19 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ## Overview
 
-Tendermint provides Byzantine Fault Tolerant State Machine Replication using
+CometBFT provides Byzantine Fault Tolerant State Machine Replication using
 hash-linked batches of transactions. Such transaction batches are called "blocks".
-Hence, Tendermint defines a "blockchain".
+Hence, CometBFT defines a "blockchain".
 
-Each block in Tendermint has a unique index - its Height.
+Each block in CometBFT has a unique index - its Height.
 Height's in the blockchain are monotonic.
 Each block is committed by a known set of weighted Validators.
 Membership and weighting within this validator set may change over time.
-Tendermint guarantees the safety and liveness of the blockchain
+CometBFT guarantees the safety and liveness of the blockchain
 so long as less than 1/3 of the total weight of the Validator set
 is malicious or faulty.
 
-A commit in Tendermint is a set of signed messages from more than 2/3 of
+A commit in CometBFT is a set of signed messages from more than 2/3 of
 the total weight of the current Validator set. Validators take turns proposing
 blocks and voting on them. Once enough votes are received, the block is considered
 committed. These votes are included in the _next_ block as proof that the previous block
@@ -79,7 +79,7 @@ The application returns results for each of the transactions in the block.
 The application can also return changes to be made to the validator set,
 as well as a cryptographic digest of its latest state.
 
-Tendermint is designed to enable efficient verification and authentication
+CometBFT is designed to enable efficient verification and authentication
 of the latest state of the blockchain. To achieve this, it embeds
 cryptographic commitments to certain information in the block "header".
 This information includes the contents of the block (eg. the transactions),
 
@@ -10,18 +10,18 @@ parent:
 ## Introduction
 
 ABCI++ is a major evolution of ABCI (**A**pplication **B**lock**c**hain **I**nterface).
-Like its predecessor, ABCI++ is the interface between Tendermint (a state-machine
+Like its predecessor, ABCI++ is the interface between CometBFT (a state-machine
 replication engine) and the actual state machine being replicated (i.e., the Application).
 The API consists of a set of _methods_, each with a corresponding `Request` and `Response`
 message type.
 
-The methods are always initiated by Tendermint. The Application implements its logic
+The methods are always initiated by CometBFT. The Application implements its logic
 for handling all ABCI++ methods.
-Thus, Tendermint always sends the `Request*` messages and receives the `Response*` messages
+Thus, CometBFT always sends the `Request*` messages and receives the `Response*` messages
 in return.
 
 All ABCI++ messages and methods are defined in [protocol buffers](../../proto/tendermint/abci/types.proto).
-This allows Tendermint to run with applications written in many programming languages.
+This allows CometBFT to run with applications written in many programming languages.
 
 This specification is split as follows:
 
@@ -30,10 +30,10 @@ This specification is split as follows:
 - [Methods](./abci++_methods.md) - complete details on all ABCI++ methods
   and message types.
 - [Requirements for the Application](./abci++_app_requirements.md) - formal requirements
-  on the Application's logic to ensure Tendermint properties such as liveness. These requirements define what
-  Tendermint expects from the Application; second part on managing ABCI application state and related topics.
-- [Tendermint's expected behavior](./abci++_tmint_expected_behavior.md) - specification of
-  how the different ABCI++ methods may be called by Tendermint. This explains what the Application
-  is to expect from Tendermint.
+  on the Application's logic to ensure CometBFT properties such as liveness. These requirements define what
+  CometBFT expects from the Application; second part on managing ABCI application state and related topics.
+- [CometBFT's expected behavior](./abci++_tmint_expected_behavior.md) - specification of
+  how the different ABCI++ methods may be called by CometBFT. This explains what the Application
+  is to expect from CometBFT.
 - [Client and Server](abci++_client_server.md) - for those looking to implement their
   own ABCI application servers