diff --git a/bbn-1/babylon-node/README.md b/bbn-1/babylon-node/README.md
index 34242492..781f69af 100644
--- a/bbn-1/babylon-node/README.md
+++ b/bbn-1/babylon-node/README.md
@@ -145,8 +145,7 @@ Parameters:
 - `minimum-gas-prices`: The minimum gas price your node will accept for
   transactions. The Babylon protocol enforces a minimum of `0.002ubbn` and
   any transactions with gas prices below your node's minimum will be rejected.
-- `mempool.max-txs`: Set this to `0` in order to utilise the application side
-  mempool.
+- `mempool.max-txs`: Set this to `0` in order to utilise the application side mempool.
 - `btc-config.network`: Specifies which Bitcoin network to connect to for
   checkpointing. For the Babylon Genesis mainnet,
   we use "mainnet" which is Bitcoin's mainnet network.
@@ -155,7 +154,7 @@ Note: If you're running a validator or RPC node that needs to handle queries,
 it's recommended to keep these default values for optimal performance. Only
 adjust these if you're running a node with limited memory resources.
 
-2. On `config.toml`, update the the following settings:
+2. On `config.toml`, update the following settings:
 
 ```shell
 [p2p]
diff --git a/bbn-1/babylon-validators/README.md b/bbn-1/babylon-validators/README.md
index 03ac1bfa..1fb62e44 100644
--- a/bbn-1/babylon-validators/README.md
+++ b/bbn-1/babylon-validators/README.md
@@ -42,7 +42,7 @@ two types of keys are generated automatically. One is a CometBFT consensus key
 pair, which is stored in `priv_validator_key.json`. This key is used by your
 validator to participate in block creation and signing during the
 consensus process at the CometBFT layer.
-The other is BLS key pair, which is stored in `bls_key.json` along with
+The other is a BLS key pair, which is stored in `bls_key.json` along with
 `bls_password.txt` following [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335).
 The key file location for both types of keys
 is specified in your node's `config.toml` file.
@@ -72,7 +72,7 @@ this key is one of the most important steps in setting up your validator.
 
 > **⚡ Note**: This key represents your validator's application layer account 
 > and is different from the CometBFT Key for consensus. While the CometBFT key 
-> is used for consensus-level operations, this key will be for the application-level
+> is used for consensus-level operations, this key is used for the application-level
 > operations such as managing your validator and withdrawing rewards.
 
 We will be using [Cosmos SDK](https://docs.cosmos.network/v0.50/user/run-node/keyring) 
@@ -248,7 +248,7 @@ First, get your validator's operator address using your Babylon address:
 babylond keys show <your-key-name> --address --bech val --home <path> --keyring-backend <keyring-backend>
 ```
 
-For example, for the address we used above is `bbn1qh8444k43spt6m8ernm8phxr332k85teavxmuq`, 
+For example, the address we used above is `bbn1qh8444k43spt6m8ernm8phxr332k85teavxmuq`, 
 the operator address is `bbnvaloper1qh8444k43spt6m8ernm8phxr332k85teavxmuq`. 
 
 For the next step, we will query your validator's details; however, results 
@@ -332,7 +332,7 @@ documentation.
 
 ## 6. Advanced Security Architecture
 
-Each validator's needs are significantly varied based on their operational needs 
+Each validator's needs vary significantly based on their operational needs 
 and the environment they are running in. Before setting up your validator 
 infrastructure, take time to research different security architectures, including 
 the [Sentry Node Architecture](https://hub.cosmos.network/main/validators/security#sentry-nodes-ddos-protection).