docs: fix typos

docs/core/configuration.md

@@ -7,11 +7,11 @@ order: 3
 CometBFT can be configured via a TOML file in
 `$CMTHOME/config/config.toml`. Some of these parameters can be overridden by
 command-line flags. For most users, the options in the `##### main base configuration options #####` are intended to be modified while config options
-further below are intended for advance power users.
+further below are intended for advanced power users.
 
 ## Options
 
-The default configuration file create by `cometbft init` has all
+The default configuration file created by `cometbft init` has all
 the parameters set with their default values. It will look something
 like the file below, however, double check by inspecting the
 `config.toml` created with your version of `cometbft` installed:

docs/core/running-in-production.md

@@ -166,7 +166,7 @@ Each CometBFT instance has a standard `/health` RPC endpoint, which responds
 with 200 (OK) if everything is fine and 500 (or no response) - if something is
 wrong.
 
-Other useful endpoints include mentioned earlier `/status`, `/net_info` and
+Other useful endpoints include those mentioned earlier `/status`, `/net_info` and
 `/validators`.
 
 CometBFT also can report and serve Prometheus metrics. See
@@ -358,7 +358,7 @@ applications, setting it to true is not a problem.
 - `consensus.peer_gossip_sleep_duration`
 
 You can try to reduce the time your node sleeps before checking if
-theres something to send its peers.
+there is something to send its peers.
 
 - `consensus.timeout_commit`
 

docs/core/state-sync.md

@@ -30,7 +30,7 @@ The next information you will need to acquire it through publicly exposed RPC's
 - `trust_period`: Trust period is the period in which headers can be verified. 
   > :warning: This value should be significantly smaller than the unbonding period.
 
-If you are relying on publicly exposed RPC's to get the need information, you can use `curl`.
+If you are relying on publicly exposed RPC's to get the needed information, you can use `curl`.
 
 Example: 
 

docs/introduction/README.md

@@ -19,7 +19,7 @@ to elections, to infrastructure orchestration, and beyond.
 The ability to tolerate machines failing in arbitrary ways, including
 becoming malicious, is known as Byzantine fault tolerance (BFT). The
 theory of BFT is decades old, but software implementations have only
-became popular recently, due largely to the success of "blockchain
+become popular recently, due largely to the success of "blockchain
 technology" like Bitcoin and Ethereum. Blockchain technology is just a
 reformalization of BFT in a more modern setting, with emphasis on
 peer-to-peer networking and cryptographic authentication. The name