Corrected typos

docs/cli/babylond/Babylond_tx/Babylond_tx_sign.md

@@ -14,7 +14,7 @@ babylond tx sign [file] [flags]
 ## Options
 ```
   -a, --account-number uint      The account number of the signing account (offline mode only)
-      --amino                    Generate Amino encoded JSON suitable for submiting to the txs REST endpoint
+      --amino                    Generate Amino encoded JSON suitable for submitting to the txs REST endpoint
       --aux                      Generate aux signer data instead of sending a tx
   -b, --broadcast-mode string    Transaction broadcasting mode (sync|async|block) (default "sync")
       --chain-id string          The network chain ID

docs/introduction/architecture.md

@@ -38,7 +38,7 @@ A standalone program that monitors:
 - Whether all Babylon’s BTC checkpoints have been included in Babylon the ledger on time so that all Babylon nodes can see them.
 
 ## IBC relayer <a id="layer"></a>
-A standard Cosmos program that enables interchain communicaton. Its default client update function sends a Cosmos zone (CZ)'s headers to Babylon as Babylon transactions, making it a natural checkpointing mechanism.
+A standard Cosmos program that enables interchain communication. Its default client update function sends a Cosmos zone (CZ)'s headers to Babylon as Babylon transactions, making it a natural checkpointing mechanism.
 
 ## IBC light client <a id="client"></a>
 A standard Cosmos app module residing in Babylon. It verifies the CZ headers shared by the IBC relayer and uses the verified CZ headers to further verify CZ transactions.

docs/modules/czconcierge.md

@@ -68,7 +68,7 @@ The light client allows a Cosmos zone to maintain a subset of headers from the c
 - **Liveness:** The IBC light client keeps growing
 when the counterparty zone has > 2/3 honest voting power and there exists > 1 honest relayer.
 
-Verifying a header is done by a special [quorum intersection mechanism](https://arxiv.org/abs/2010.07031): upon a header from the relayer, the light client checks whether the intersected voting power bewteen the quorum certificates of the current tip and the header is more than 1/3 of the voting power in the current tip.
+Verifying a header is done by a special [quorum intersection mechanism](https://arxiv.org/abs/2010.07031): upon a header from the relayer, the light client checks whether the intersected voting power between the quorum certificates of the current tip and the header is more than 1/3 of the voting power in the current tip.
 If yes, then this ensures that there exists at least one honest validator in the header's quorum certificate, and this header is agreed by all honest validators.
 Each header of a Cosmos zone carries `AppHash`, which is the root of the Merkle IAVL tree for the Cosmos zone's database.
 The `AppHash` allows a light client to verify whether an IBC packet is included in the Cosmos zone's blockchain.

docs/rpc-gateway/epoching/params.md

@@ -1,6 +1,6 @@
 ---
 id: params
-sidebar_label: Paramaters
+sidebar_label: Parameters
 hide_table_of_contents: true
 
 ---

docs/testnet/become-validator.md

@@ -75,7 +75,7 @@ key-name = "val-key" # replace with your key name
 
 Finally, it is strongly recommended to modify the `timeout_commit` value
 under `~/.babylond/config/config.toml`. This value specifies
-how long a validator will wait before commiting a block before starting
+how long a validator will wait before committing a block before starting
 on a new height. More information can be found [here](https://docs.tendermint.com/v0.33/tendermint-core/configuration.html#consensus-timeouts-explained).
 Given that Babylon aims to have a 10 second time between blocks, set this value
 to:

docs/testnet/integrate.md

@@ -83,7 +83,7 @@ chains:
     babylon:
         type: cosmos
         value:
-            key: babylon-key      # REPLACEME: Nane of the key in the keyring (same as the one added on the bootrapping script by `keys add`.
+            key: babylon-key      # REPLACEME: Name of the key in the keyring (same as the one added on the bootstrapping script by `keys add`.
             chain-id: bbn-demo1   # REPLACEME: Chain ID for the network you're connecting to. NOTE: this chain-id should be the same as the directory that contains the test keyring, i.e. if bbn-demo1, then `relayer-home/keys/bbn-demo1` should contain the `keyring-test` directory with a key with the same name as the above attribute.
             rpc-addr: http://rpc0.demo.babylonchain.io:26657 # REPLACEME: Address to which an RPC connection can be made
             account-prefix: bbn